Common Weakness Enumeration

CWE-295

Allowed

Improper Certificate Validation

Abstraction: Base · Status: Draft

The product does not validate, or incorrectly validates, a certificate.

1911 vulnerabilities reference this CWE, most recent first.

GHSA-FJQ5-842V-W552

Vulnerability from github – Published: 2022-05-14 03:39 – Updated: 2022-05-14 03:39
VLAI
Details

VOBOT CLOCK before 0.99.30 devices do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information, and consequently execute arbitrary code, via a crafted certificate, as demonstrated by leveraging a hardcoded --no-check-certificate Wget option.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-6827"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2018-02-09T15:29:00Z",
    "severity": "HIGH"
  },
  "details": "VOBOT CLOCK before 0.99.30 devices do not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information, and consequently execute arbitrary code, via a crafted certificate, as demonstrated by leveraging a hardcoded --no-check-certificate Wget option.",
  "id": "GHSA-fjq5-842v-w552",
  "modified": "2022-05-14T03:39:40Z",
  "published": "2022-05-14T03:39:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-6827"
    },
    {
      "type": "WEB",
      "url": "http://stacksmashing.net/CVE-2018-6827.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FJWP-5XR6-HVH5

Vulnerability from github – Published: 2025-08-01 18:31 – Updated: 2025-08-01 18:31
VLAI
Details

Alpine iLX-507 TIDAL Improper Certificate Validation Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-507 devices. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the TIDAL music streaming application. The issue results from improper certificate validation. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-26322.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-8476"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-08-01T18:15:58Z",
    "severity": "HIGH"
  },
  "details": "Alpine iLX-507 TIDAL Improper Certificate Validation Vulnerability. This vulnerability allows network-adjacent attackers to execute arbitrary code on affected installations of Alpine iLX-507 devices. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the TIDAL music streaming application. The issue results from improper certificate validation. An attacker can leverage this in conjunction with other vulnerabilities to execute arbitrary code in the context of root. Was ZDI-CAN-26322.",
  "id": "GHSA-fjwp-5xr6-hvh5",
  "modified": "2025-08-01T18:31:20Z",
  "published": "2025-08-01T18:31:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-8476"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-25-765"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM24-8VCM-JW5M

Vulnerability from github – Published: 2022-05-17 02:49 – Updated: 2022-05-17 02:49
VLAI
Details

Google Chrome caches TLS sessions before certificate validation occurs.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2013-6662"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2017-04-13T17:59:00Z",
    "severity": "MODERATE"
  },
  "details": "Google Chrome caches TLS sessions before certificate validation occurs.",
  "id": "GHSA-fm24-8vcm-jw5m",
  "modified": "2022-05-17T02:49:20Z",
  "published": "2022-05-17T02:49:20Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-6662"
    },
    {
      "type": "WEB",
      "url": "https://bugs.chromium.org/p/chromium/issues/detail?id=305220"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM2V-2V2P-J5MR

Vulnerability from github – Published: 2022-05-02 03:41 – Updated: 2025-04-09 04:13
VLAI
Details

Opera before 10.00 does not check all intermediate X.509 certificates for revocation, which makes it easier for remote SSL servers to bypass validation of the certificate chain via a revoked certificate.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2009-3046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2009-09-02T17:30:00Z",
    "severity": "MODERATE"
  },
  "details": "Opera before 10.00 does not check all intermediate X.509 certificates for revocation, which makes it easier for remote SSL servers to bypass validation of the certificate chain via a revoked certificate.",
  "id": "GHSA-fm2v-2v2p-j5mr",
  "modified": "2025-04-09T04:13:49Z",
  "published": "2022-05-02T03:41:21Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2009-3046"
    },
    {
      "type": "WEB",
      "url": "https://oval.cisecurity.org/repository/search/definition/oval%3Aorg.mitre.oval%3Adef%3A6357"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/docs/changelogs/freebsd/1000"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/docs/changelogs/linux/1000"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/docs/changelogs/mac/1000"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/docs/changelogs/solaris/1000"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/docs/changelogs/windows/1000"
    },
    {
      "type": "WEB",
      "url": "http://www.opera.com/support/kb/view/929"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM7R-P7X2-H4J8

Vulnerability from github – Published: 2026-03-09 06:31 – Updated: 2026-03-09 06:31
VLAI
Details

Taipower APP developed by Taipower has an Improper Certificate Validation vulnerability. When establishing an HTTPS connection with the server, the application fails to verify the server-side TLS/SSL certificate. This flaw allows an unauthenticated remote attackers to exploit the vulnerability to perform a Man-in-the-Middle (MITM) attack to read and tamper with network packets.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-3822"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-03-09T04:16:10Z",
    "severity": "HIGH"
  },
  "details": "Taipower APP developed by Taipower has an Improper Certificate Validation vulnerability. When establishing an HTTPS connection with the server, the application fails to verify the server-side TLS/SSL certificate. This flaw allows an unauthenticated remote attackers to exploit the vulnerability to perform a Man-in-the-Middle (MITM) attack to read and tamper with network packets.",
  "id": "GHSA-fm7r-p7x2-h4j8",
  "modified": "2026-03-09T06:31:14Z",
  "published": "2026-03-09T06:31:14Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-3822"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/en/cp-139-10751-23871-2.html"
    },
    {
      "type": "WEB",
      "url": "https://www.twcert.org.tw/tw/cp-132-10750-3735f-1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-FM88-G6XW-MPJG

Vulnerability from github – Published: 2022-05-27 00:00 – Updated: 2022-06-09 00:00
VLAI
Details

Dell EMC NetWorker versions 19.1.x, 19.1.0.x, 19.1.1.x, 19.2.x, 19.2.0.x, 19.2.1.x 19.3.x, 19.3.0.x, 19.4.x, 19.4.0.x, 19.5.x,19.5.0.x, 19.6 and 19.6.0.1 and 19.6.0.2 contain an Improper Validation of Certificate with Host Mismatch vulnerability in Rabbitmq port 5671 which could allow remote attackers to spoof certificates.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-29082"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-05-26T16:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell EMC NetWorker versions 19.1.x, 19.1.0.x, 19.1.1.x, 19.2.x, 19.2.0.x, 19.2.1.x 19.3.x, 19.3.0.x, 19.4.x, 19.4.0.x, 19.5.x,19.5.0.x, 19.6 and 19.6.0.1 and 19.6.0.2 contain an Improper Validation of Certificate with Host Mismatch vulnerability in Rabbitmq port 5671 which could allow remote attackers to spoof certificates.",
  "id": "GHSA-fm88-g6xw-mpjg",
  "modified": "2022-06-09T00:00:22Z",
  "published": "2022-05-27T00:00:47Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-29082"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000198987"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FM9C-XCJ2-2J5G

Vulnerability from github – Published: 2022-07-26 00:01 – Updated: 2022-08-03 00:00
VLAI
Details

An Improper Certificate Validation vulnerability in LibreOffice existed where determining if a macro was signed by a trusted author was done by only matching the serial number and issuer string of the used certificate with that of a trusted certificate. This is not sufficient to verify that the macro was actually signed with the certificate. An adversary could therefore create an arbitrary certificate with a serial number and an issuer string identical to a trusted certificate which LibreOffice would present as belonging to the trusted author, potentially leading to the user to execute arbitrary code contained in macros improperly trusted. This issue affects: The Document Foundation LibreOffice 7.2 versions prior to 7.2.7; 7.3 versions prior to 7.3.1.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2022-26305"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-25T15:15:00Z",
    "severity": "CRITICAL"
  },
  "details": "An Improper Certificate Validation vulnerability in LibreOffice existed where determining if a macro was signed by a trusted author was done by only matching the serial number and issuer string of the used certificate with that of a trusted certificate. This is not sufficient to verify that the macro was actually signed with the certificate. An adversary could therefore create an arbitrary certificate with a serial number and an issuer string identical to a trusted certificate which LibreOffice would present as belonging to the trusted author, potentially leading to the user to execute arbitrary code contained in macros improperly trusted. This issue affects: The Document Foundation LibreOffice 7.2 versions prior to 7.2.7; 7.3 versions prior to 7.3.1.",
  "id": "GHSA-fm9c-xcj2-2j5g",
  "modified": "2022-08-03T00:00:58Z",
  "published": "2022-07-26T00:01:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-26305"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2023/03/msg00022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.libreoffice.org/about-us/security/advisories/cve-2022-26305"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMJ7-7GFW-64PG

Vulnerability from github – Published: 2024-10-15 17:33 – Updated: 2024-10-15 23:36
VLAI
Summary
Agent Dart is missing certificate verification checks
Details

Certificate verification (in lib/agent/certificate.dart) has been found to contain two issues: - During the delegation verification (in _checkDelegation function) the canister_ranges aren't verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification here. Also for reference you can check how is this implemented in the agent-rs. - The certificate’s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expiration time. The IC spec doesn’t specify an expiry times, it gives some suggestions, quoting: "A reasonable expiry time for timestamps in R.signatures and the certificate Cert is 5 minutes (analogously to the maximum allowed ingress expiry enforced by the IC mainnet). Delegations require expiry times of at least a week since the IC mainnet refreshes the delegations only after replica upgrades which typically happen once a week". For reference you can check how is this implemented in the agent-rs (here and here).

Additionally, seems replica signed queries aren’t implemented

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.0.0-dev.28"
      },
      "package": {
        "ecosystem": "Pub",
        "name": "agent_dart"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.0.0-dev.29"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-48915"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295",
      "CWE-347"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-10-15T17:33:50Z",
    "nvd_published_at": "2024-10-15T17:15:11Z",
    "severity": "HIGH"
  },
  "details": "Certificate verification (in [lib/agent/certificate.dart](https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart)) has been found to contain two issues:\n   - During the delegation verification (in [_checkDelegation](https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162) function) the canister_ranges aren\u0027t verified. The impact of not checking the canister_ranges is that a subnet can sign canister responses in behalf of another subnet. You have more details in the IC specification [here](https://internetcomputer.org/docs/current/references/ic-interface-spec#certification-delegation). Also for reference you can check how is this implemented in [the agent-rs](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L903-L914).\n    - The certificate\u2019s timestamp, i.e /time path, is not verified, meaning that the certificate effectively has no expiration time. The [IC spec](https://internetcomputer.org/docs/current/references/ic-interface-spec#http-query) doesn\u2019t specify an expiry times, it gives some suggestions, quoting: \"A reasonable expiry time for timestamps in R.signatures and the certificate Cert is 5 minutes (analogously to the maximum allowed ingress expiry enforced by the IC mainnet). Delegations require expiry times of at least a week since the IC mainnet refreshes the delegations only after replica upgrades which typically happen once a week\". For reference you can check how is this implemented in the agent-rs ([here](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L820) and [here](https://github.com/dfinity/agent-rs/blob/608a3f4cfdcdfc5ca1ca74a1b9d33f2137a2d324/ic-agent/src/agent/mod.rs#L876-L887)).\n\n**Additionally**, seems [replica signed queries](https://internetcomputer.org/blog/features/replica-signed-queries) aren\u2019t implemented",
  "id": "GHSA-fmj7-7gfw-64pg",
  "modified": "2024-10-15T23:36:57Z",
  "published": "2024-10-15T17:33:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/security/advisories/GHSA-fmj7-7gfw-64pg"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-48915"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/commit/0d200686aabcd9313c7bc3e675cbdc82f6b775cf"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/AstroxNetwork/agent_dart"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/blob/f50971dfae3f536c1720f0084f28afbcf5d99cb5/lib/agent/certificate.dart#L162"
    },
    {
      "type": "WEB",
      "url": "https://github.com/AstroxNetwork/agent_dart/blob/main/lib/agent/certificate.dart"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Agent Dart is missing certificate verification checks"
}

GHSA-FMJQ-WHMF-HGC4

Vulnerability from github – Published: 2022-05-14 01:35 – Updated: 2022-05-14 01:35
VLAI
Details

The RICOH Interactive Whiteboard D2200 V1.3 to V2.2, D5500 V1.3 to V2.2, D5510 V1.3 to V2.2, the display versions with RICOH Interactive Whiteboard Controller Type1 V1.3 to V2.2 attached (D5520, D6500, D6510, D7500, D8400), and the display versions with RICOH Interactive Whiteboard Controller Type2 V3.0 to V3.1.10137.0 attached (D5520, D6510, D7500, D8400) does not verify its server certificates, which allows man-in-the-middle attackers to eversdrop on encrypted communication.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2018-16187"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-01-09T23:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The RICOH Interactive Whiteboard D2200 V1.3 to V2.2, D5500 V1.3 to V2.2, D5510 V1.3 to V2.2, the display versions with RICOH Interactive Whiteboard Controller Type1 V1.3 to V2.2 attached (D5520, D6500, D6510, D7500, D8400), and the display versions with RICOH Interactive Whiteboard Controller Type2 V3.0 to V3.1.10137.0 attached (D5520, D6510, D7500, D8400) does not verify its server certificates, which allows man-in-the-middle attackers to eversdrop on encrypted communication.",
  "id": "GHSA-fmjq-whmf-hgc4",
  "modified": "2022-05-14T01:35:42Z",
  "published": "2022-05-14T01:35:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2018-16187"
    },
    {
      "type": "WEB",
      "url": "https://jvn.jp/en/jp/JVN55263945/index.html"
    },
    {
      "type": "WEB",
      "url": "https://www.ricoh.com/info/2018/1127_1.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-FMM6-Q36G-MF2H

Vulnerability from github – Published: 2024-02-02 18:30 – Updated: 2024-02-08 18:30
VLAI
Details

Dell BSAFE Crypto-C Micro Edition, versions before 4.1.5, and Dell BSAFE Micro Edition Suite, versions before 4.5.2, contain a Missing Required Cryptographic Step Vulnerability.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2020-29504"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-295"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-02T16:15:44Z",
    "severity": "HIGH"
  },
  "details": "\nDell BSAFE Crypto-C Micro Edition, versions before 4.1.5, and Dell BSAFE Micro Edition Suite,\u00a0versions before 4.5.2, contain a Missing Required Cryptographic Step Vulnerability.\n\n",
  "id": "GHSA-fmm6-q36g-mf2h",
  "modified": "2024-02-08T18:30:39Z",
  "published": "2024-02-02T18:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-29504"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/en-us/000181115/dsa-2020-286-dell-bsafe-crypto-c-micro-edition-4-1-5-and-dell-bsafe-micro-edition-suite-4-6-multiple-security-vulnerabilities"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

Mitigation
Architecture and Design Implementation

Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.

Mitigation
Implementation

If certificate pinning is being used, ensure that all relevant properties of the certificate are fully validated before the certificate is pinned, including the hostname.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-475: Signature Spoofing by Improper Validation

An adversary exploits a cryptographic weakness in the signature verification algorithm implementation to generate a valid signature without knowing the key.