CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2057 vulnerabilities reference this CWE, most recent first.
GHSA-6HXQ-P678-4HR2
Vulnerability from github – Published: 2026-09-04 17:33 – Updated: 2026-09-04 17:33Summary
validateCertificatePath() does not verify that an attestation's certificate chain actually terminates at a configured trust anchor. When walking the chain it stops at the first self-signed certificate it finds (which could be user-supplied), and exits early.
This happens before the configured Apple/Google/etc trust anchor (which is concatenated to the end of the chain) is reached.
A user can therefore register a credential and have the server accept it as if it were backed by a genuine Apple / Android SafetyNet / Yubikey / etc.
Details
packages/server/src/helpers/validateCertificatePath.ts:
The configured trust anchor is appended to the end of the untrusted chain (line 83):
const x5cWithTrustAnchor = x5cCertsParsed.concat([anchor]);
The walk then verifies each cert was signed by the next, but breaks on the first self-signed cert (lines 104–116):
if (issuer.subject === issuer.issuer) {
// Root cert detected, make sure it signed itself
const issuerSignedIssuer = await issuer.verify(
{ publicKey: issuer.publicKey, signatureOnly: true },
WebCrypto,
);
if (!issuerSignedIssuer) {
throw new InvalidSubjectAndIssuer();
}
break; // <-- exits before the appended trust anchor is ever checked if user supplied self-signed cert comes first
}
The success condition is therefore "the certs form an internally-consistent chain ending in some self-signed cert" Rather than "the chain terminates at one of the configured trust anchors."
Exploit shape
attacker sends: x5c = [ forgedLeaf (signed by attacker root),
attackerSelfSignedRoot ]
library builds: [ forgedLeaf, attackerSelfSignedRoot, <configured Apple/Google/etc root> ]
walk: forgedLeaf -> attackerSelfSignedRoot (verifies, attacker controls both)
attackerSelfSignedRoot is self-signed -> break
attackerSelfSignedRoot -> configured root (NEVER CHECKED)
return true. The configured anchor never gets checked.
As far as observed, all attestation enforcement uses validateCertificatePath when using MDS etc.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 13.3.1"
},
"package": {
"ecosystem": "npm",
"name": "@simplewebauthn/server"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "13.3.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-295",
"CWE-296"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-04T17:33:20Z",
"nvd_published_at": null,
"severity": "LOW"
},
"details": "## Summary\n`validateCertificatePath()` does not verify that an attestation\u0027s certificate chain actually terminates at a configured trust anchor. When walking the chain it stops at the first self-signed certificate it finds (which could be user-supplied), and exits early.\n\nThis happens before the configured Apple/Google/etc trust anchor (which is concatenated to the end of the chain) is reached.\n\nA user can therefore register a credential and have the server accept it as if it were backed by a genuine Apple / Android SafetyNet / Yubikey / etc.\n\n## Details\n`packages/server/src/helpers/validateCertificatePath.ts`:\n\nThe configured trust anchor is appended to the end of the untrusted chain (line **83**):\n\n```ts\nconst x5cWithTrustAnchor = x5cCertsParsed.concat([anchor]);\n```\n\nThe walk then verifies each cert was signed by the next, but breaks on the first self-signed cert (lines **104\u2013116**):\n\n```ts\nif (issuer.subject === issuer.issuer) {\n // Root cert detected, make sure it signed itself\n const issuerSignedIssuer = await issuer.verify(\n { publicKey: issuer.publicKey, signatureOnly: true },\n WebCrypto,\n );\n if (!issuerSignedIssuer) {\n throw new InvalidSubjectAndIssuer();\n }\n break; // \u003c-- exits before the appended trust anchor is ever checked if user supplied self-signed cert comes first\n}\n```\n\nThe success condition is therefore \"the certs form an internally-consistent chain ending in some self-signed cert\" Rather than \"the chain terminates at one of the configured trust anchors.\"\n\n## Exploit shape\n\n```\nattacker sends: x5c = [ forgedLeaf (signed by attacker root),\n attackerSelfSignedRoot ]\n\nlibrary builds: [ forgedLeaf, attackerSelfSignedRoot, \u003cconfigured Apple/Google/etc root\u003e ]\n\nwalk: forgedLeaf -\u003e attackerSelfSignedRoot (verifies, attacker controls both)\n attackerSelfSignedRoot is self-signed -\u003e break\n attackerSelfSignedRoot -\u003e configured root (NEVER CHECKED)\n```\n\n`return true`. The configured anchor never gets checked.\n\n\nAs far as observed, all attestation enforcement uses validateCertificatePath when using MDS etc.",
"id": "GHSA-6hxq-p678-4hr2",
"modified": "2026-09-04T17:33:20Z",
"published": "2026-09-04T17:33:20Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/MasterKale/SimpleWebAuthn/security/advisories/GHSA-6hxq-p678-4hr2"
},
{
"type": "WEB",
"url": "https://github.com/MasterKale/SimpleWebAuthn/commit/67a41fed3dfd96cab1dcf414f6d1792a72e06e35"
},
{
"type": "WEB",
"url": "https://github.com/MasterKale/SimpleWebAuthn/commit/8a53d70f42bcbb7c744ef1b90e6db35bc4b26d06"
},
{
"type": "WEB",
"url": "https://github.com/MasterKale/SimpleWebAuthn/commit/dd0d73c716a528e6645efafbd43a972b64df71f9"
},
{
"type": "PACKAGE",
"url": "https://github.com/MasterKale/SimpleWebAuthn"
},
{
"type": "WEB",
"url": "https://github.com/MasterKale/SimpleWebAuthn/releases/tag/v13.3.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:A/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "SimpleWebAuthn: Registration verification does not sufficiently ensure that attestation certificates chain to a trust anchor"
}
GHSA-6J39-893G-Q8CF
Vulnerability from github – Published: 2025-02-05 03:32 – Updated: 2025-02-05 03:32A vulnerability in Veeam Updater component allows Man-in-the-Middle attackers to execute arbitrary code on the affected server. This issue occurs due to a failure to properly validate TLS certificate.
{
"affected": [],
"aliases": [
"CVE-2025-23114"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-05T02:15:28Z",
"severity": "CRITICAL"
},
"details": "A vulnerability in Veeam Updater component allows Man-in-the-Middle attackers to execute arbitrary code on the affected server. This issue occurs due to a failure to properly validate TLS certificate.",
"id": "GHSA-6j39-893g-q8cf",
"modified": "2025-02-05T03:32:13Z",
"published": "2025-02-05T03:32:13Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-23114"
},
{
"type": "WEB",
"url": "https://www.veeam.com/kb4712"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-6JMW-P67P-7Q5C
Vulnerability from github – Published: 2022-05-17 00:51 – Updated: 2022-05-17 00:51The D-Link NPAPI extension, as used on D-Link DIR-850L REV. A (with firmware through FW114WWb07_h2ab_beta1) and REV. B (with firmware through FW208WWb02) devices, participates in mydlink Cloud Services by establishing a TCP relay service for HTTP, even though a TCP relay service for HTTPS is also established.
{
"affected": [],
"aliases": [
"CVE-2017-14419"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-09-13T17:29:00Z",
"severity": "MODERATE"
},
"details": "The D-Link NPAPI extension, as used on D-Link DIR-850L REV. A (with firmware through FW114WWb07_h2ab_beta1) and REV. B (with firmware through FW208WWb02) devices, participates in mydlink Cloud Services by establishing a TCP relay service for HTTP, even though a TCP relay service for HTTPS is also established.",
"id": "GHSA-6jmw-p67p-7q5c",
"modified": "2022-05-17T00:51:52Z",
"published": "2022-05-17T00:51:52Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14419"
},
{
"type": "WEB",
"url": "https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0days-vulnerabilities.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-6JVH-7FRH-6572
Vulnerability from github – Published: 2022-05-24 16:49 – Updated: 2024-04-04 01:12The Android App 'Tootdon for Mastodon' version 3.4.1 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.
{
"affected": [],
"aliases": [
"CVE-2019-5961"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-07-05T14:15:00Z",
"severity": "HIGH"
},
"details": "The Android App \u0027Tootdon for Mastodon\u0027 version 3.4.1 and earlier does not verify X.509 certificates from SSL servers, which allows man-in-the-middle attackers to spoof servers and obtain sensitive information via a crafted certificate.",
"id": "GHSA-6jvh-7frh-6572",
"modified": "2024-04-04T01:12:03Z",
"published": "2022-05-24T16:49:37Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5961"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN57806517/index.html"
},
{
"type": "WEB",
"url": "http://blog.mastodon-tootdon.com/entry/2019/05/20/204019"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-6MV5-CH6P-7G97
Vulnerability from github – Published: 2025-11-05 18:31 – Updated: 2025-11-05 21:31Tonec Internet Download Manager 6.42.41.1 and earlier suffers from Missing SSL Certificate Validation, which allows attackers to bypass update protections.
{
"affected": [],
"aliases": [
"CVE-2025-56231"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-11-05T18:15:33Z",
"severity": "CRITICAL"
},
"details": "Tonec Internet Download Manager 6.42.41.1 and earlier suffers from Missing SSL Certificate Validation, which allows attackers to bypass update protections.",
"id": "GHSA-6mv5-ch6p-7g97",
"modified": "2025-11-05T21:31:01Z",
"published": "2025-11-05T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-56231"
},
{
"type": "WEB",
"url": "https://www.notion.so/CVE-2025-56231-2a04e9f2a40d80b184f4d02be58d3600"
},
{
"type": "WEB",
"url": "http://tonec.com"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-6P29-JHC3-FMFM
Vulnerability from github – Published: 2022-05-14 03:44 – Updated: 2022-05-14 03:44MatrixSSL version 3.7.2 adopts a collision-prone OID comparison logic resulting in possible spoofing of OIDs (e.g. in ExtKeyUsage extension) on X.509 certificates.
{
"affected": [],
"aliases": [
"CVE-2017-1000417"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2018-01-22T23:29:00Z",
"severity": "MODERATE"
},
"details": "MatrixSSL version 3.7.2 adopts a collision-prone OID comparison logic resulting in possible spoofing of OIDs (e.g. in ExtKeyUsage extension) on X.509 certificates.",
"id": "GHSA-6p29-jhc3-fmfm",
"modified": "2022-05-14T03:44:57Z",
"published": "2022-05-14T03:44:57Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-1000417"
},
{
"type": "WEB",
"url": "https://github.com/matrixssl/matrixssl/blob/master/doc/CHANGES.md"
},
{
"type": "WEB",
"url": "https://www.ieee-security.org/TC/SP2017/papers/231.pdf"
},
{
"type": "WEB",
"url": "https://www.youtube.com/watch?v=FW--c_F_cY8"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6P5V-6RVF-WF2M
Vulnerability from github – Published: 2022-05-17 02:48 – Updated: 2022-05-17 02:48Photopt for Android before 2.0.1 does not verify SSL certificates.
{
"affected": [],
"aliases": [
"CVE-2016-1198"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-04-21T20:59:00Z",
"severity": "MODERATE"
},
"details": "Photopt for Android before 2.0.1 does not verify SSL certificates.",
"id": "GHSA-6p5v-6rvf-wf2m",
"modified": "2022-05-17T02:48:18Z",
"published": "2022-05-17T02:48:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2016-1198"
},
{
"type": "WEB",
"url": "https://mypocket.ntt.com/photopt/info/info_001.html"
},
{
"type": "WEB",
"url": "http://jvn.jp/en/jp/JVN11815655/index.html"
},
{
"type": "WEB",
"url": "http://jvndb.jvn.jp/en/contents/2016/JVNDB-2016-000050.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-6P94-89QP-5G52
Vulnerability from github – Published: 2022-05-17 00:23 – Updated: 2022-05-17 00:23In F5 BIG-IP PEM 12.1.0 through 12.1.2 when downloading the Type Allocation Code (TAC) database file via HTTPS, the server's certificate is not verified. Attackers in a privileged network position may be able to launch a man-in-the-middle attack against these connections. TAC databases are used in BIG-IP PEM for Device Type and OS (DTOS) and Tethering detection. Customers not using BIG-IP PEM, not configuring downloads of TAC database files, or not using HTTP for that download are not affected.
{
"affected": [],
"aliases": [
"CVE-2017-6144"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-10-20T15:29:00Z",
"severity": "HIGH"
},
"details": "In F5 BIG-IP PEM 12.1.0 through 12.1.2 when downloading the Type Allocation Code (TAC) database file via HTTPS, the server\u0027s certificate is not verified. Attackers in a privileged network position may be able to launch a man-in-the-middle attack against these connections. TAC databases are used in BIG-IP PEM for Device Type and OS (DTOS) and Tethering detection. Customers not using BIG-IP PEM, not configuring downloads of TAC database files, or not using HTTP for that download are not affected.",
"id": "GHSA-6p94-89qp-5g52",
"modified": "2022-05-17T00:23:46Z",
"published": "2022-05-17T00:23:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-6144"
},
{
"type": "WEB",
"url": "https://support.f5.com/csp/article/K81601350"
}
],
"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:N",
"type": "CVSS_V3"
}
]
}
GHSA-6PC8-5263-HVGQ
Vulnerability from github – Published: 2025-02-27 00:30 – Updated: 2025-03-10 21:31When AdaCore Ada Web Server 25.0.0 is linked with GnuTLS, the default behaviour of AWS.Client is vulnerable to a man-in-the-middle attack because of lack of verification of an HTTPS server's certificate (unless the using program specifies a TLS configuration).
{
"affected": [],
"aliases": [
"CVE-2024-55581"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-02-26T22:15:14Z",
"severity": "HIGH"
},
"details": "When AdaCore Ada Web Server 25.0.0 is linked with GnuTLS, the default behaviour of AWS.Client is vulnerable to a man-in-the-middle attack because of lack of verification of an HTTPS server\u0027s certificate (unless the using program specifies a TLS configuration).",
"id": "GHSA-6pc8-5263-hvgq",
"modified": "2025-03-10T21:31:11Z",
"published": "2025-02-27T00:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55581"
},
{
"type": "WEB",
"url": "https://docs.adacore.com/corp/security-advisories/SEC.AWS-0056-v1.pdf"
},
{
"type": "WEB",
"url": "https://lists.debian.org/debian-lts-announce/2025/03/msg00007.html"
}
],
"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"
}
]
}
GHSA-6PXX-R88F-H676
Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-05-24 17:01An exploitable information leak vulnerability exists in the ustream-ssl library of OpenWrt, versions 18.06.4 and 15.05.1. When connecting to a remote server, the server's SSL certificate is checked but no action is taken when the certificate is invalid. An attacker could exploit this behavior by performing a man-in-the-middle attack, providing any certificate, leading to the theft of all the data sent by the client during the first request. After an SSL connection is initialized via _ustream_ssl_init, and after any data (e.g. the client's HTTP request) is written to the stream using ustream_printf, the code eventually enters the function __ustream_ssl_poll, which is used to dispatch the read/write events
{
"affected": [],
"aliases": [
"CVE-2019-5101"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2019-11-18T18:15:00Z",
"severity": "MODERATE"
},
"details": "An exploitable information leak vulnerability exists in the ustream-ssl library of OpenWrt, versions 18.06.4 and 15.05.1. When connecting to a remote server, the server\u0027s SSL certificate is checked but no action is taken when the certificate is invalid. An attacker could exploit this behavior by performing a man-in-the-middle attack, providing any certificate, leading to the theft of all the data sent by the client during the first request. After an SSL connection is initialized via _ustream_ssl_init, and after any data (e.g. the client\u0027s HTTP request) is written to the stream using ustream_printf, the code eventually enters the function __ustream_ssl_poll, which is used to dispatch the read/write events",
"id": "GHSA-6pxx-r88f-h676",
"modified": "2022-05-24T17:01:34Z",
"published": "2022-05-24T17:01:34Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-5101"
},
{
"type": "WEB",
"url": "https://talosintelligence.com/vulnerability_reports/TALOS-2019-0893"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Certificates should be carefully managed and checked to assure that data are encrypted with the intended owner's public key.
Mitigation
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.