CWE-295
AllowedImproper Certificate Validation
Abstraction: Base · Status: Draft
The product does not validate, or incorrectly validates, a certificate.
2268 vulnerabilities reference this CWE, most recent first.
GHSA-6FW5-9HQ8-W87G
Vulnerability from github – Published: 2026-10-05 22:56 – Updated: 2026-10-05 22:56Impact
buildWSLegacyExecutor() in @graphql-tools/executor-legacy-ws previously hardcoded rejectUnauthorized: false when creating WebSocket connections over WSS. This disabled TLS certificate validation, allowing a network-positioned attacker to perform a Man-in-the-Middle (MITM) attack against applications that use this executor with a wss:// endpoint. Credentials passed via connectionParams or headers could be intercepted, and subscription data could be tampered with.
Who is impacted: Applications using @graphql-tools/executor-legacy-ws (directly or via @graphql-tools/url-loader with SubscriptionProtocol.LEGACY_WS) to connect to a wss:// endpoint from Node.js while sending authentication material over the connection.
Browser WebSocket clients are unaffected by this option (browsers always validate certificates).
Patches
Upgrade to @graphql-tools/executor-legacy-ws@1.1.35 or later (and @graphql-tools/url-loader@9.1.9 or later if you use the loader). TLS certificate validation is enabled by default. Callers that intentionally use self-signed certificates in trusted environments can opt out with rejectUnauthorized: false.
Workarounds
- Prefer the modern
graphql-ws/SubscriptionProtocol.WSpath where possible. - Until upgraded, avoid sending secrets over legacy WSS connections, or terminate TLS at a trusted proxy and use
ws://only on trusted networks. - Supply a custom
webSocketImplthat enforces certificate validation.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 1.1.34"
},
"package": {
"ecosystem": "npm",
"name": "@graphql-tools/executor-legacy-ws"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.1.35"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-103921"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-05T22:56:56Z",
"nvd_published_at": "2026-10-01T17:17:19Z",
"severity": "HIGH"
},
"details": "## Impact\n\n`buildWSLegacyExecutor()` in `@graphql-tools/executor-legacy-ws` previously hardcoded `rejectUnauthorized: false` when creating WebSocket connections over WSS. This disabled TLS certificate validation, allowing a network-positioned attacker to perform a Man-in-the-Middle (MITM) attack against applications that use this executor with a `wss://` endpoint. Credentials passed via `connectionParams` or `headers` could be intercepted, and subscription data could be tampered with.\n\n**Who is impacted:** Applications using `@graphql-tools/executor-legacy-ws` (directly or via `@graphql-tools/url-loader` with `SubscriptionProtocol.LEGACY_WS`) to connect to a `wss://` endpoint from Node.js while sending authentication material over the connection.\n\nBrowser WebSocket clients are unaffected by this option (browsers always validate certificates).\n\n## Patches\n\nUpgrade to `@graphql-tools/executor-legacy-ws@1.1.35` or later (and `@graphql-tools/url-loader@9.1.9` or later if you use the loader). TLS certificate validation is enabled by default. Callers that intentionally use self-signed certificates in trusted environments can opt out with `rejectUnauthorized: false`.\n\n## Workarounds\n\n- Prefer the modern `graphql-ws` / `SubscriptionProtocol.WS` path where possible.\n- Until upgraded, avoid sending secrets over legacy WSS connections, or terminate TLS at a trusted proxy and use `ws://` only on trusted networks.\n- Supply a custom `webSocketImpl` that enforces certificate validation.",
"id": "GHSA-6fw5-9hq8-w87g",
"modified": "2026-10-05T22:56:56Z",
"published": "2026-10-05T22:56:56Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/ardatan/graphql-tools/security/advisories/GHSA-6fw5-9hq8-w87g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-103921"
},
{
"type": "WEB",
"url": "https://github.com/ardatan/graphql-tools/pull/8426"
},
{
"type": "WEB",
"url": "https://github.com/ardatan/graphql-tools/commit/3831a0661514c91d99971052f983552556880402"
},
{
"type": "PACKAGE",
"url": "https://github.com/ardatan/graphql-tools"
},
{
"type": "WEB",
"url": "https://github.com/ardatan/graphql-tools/releases/tag/@graphql-tools/executor-legacy-ws@1.1.35"
}
],
"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"
}
],
"summary": "GraphQL Tools: TLS Certificate Validation Disabled in Legacy GraphQL WebSocket Executor"
}
GHSA-6G4J-7728-PQQC
Vulnerability from github – Published: 2026-09-09 12:32 – Updated: 2026-09-09 12:32Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.
{
"affected": [],
"aliases": [
"CVE-2026-78492"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-09T12:17:13Z",
"severity": "HIGH"
},
"details": "Dell SCG 5.0 Appliance versions prior to 5.36.00.16 and Dell SCG 5.0 Application versions prior to 5.36.00.00, contains an Improper Certificate Validation vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to unauthorized access.",
"id": "GHSA-6g4j-7728-pqqc",
"modified": "2026-09-09T12:32:14Z",
"published": "2026-09-09T12:32:14Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-78492"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-in/000503426/dsa-2026-382-security-update-for-dell-secure-connect-gateway-virtual-edition-multiple-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"
}
]
}
GHSA-6G5P-C2F9-9435
Vulnerability from github – Published: 2025-08-21 06:30 – Updated: 2025-08-21 06:30A malicious client can bypass the client certificate trust check of an opc.https server when the server endpoint is configured to allow only secure communication.
{
"affected": [],
"aliases": [
"CVE-2025-7390"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-21T06:15:35Z",
"severity": "CRITICAL"
},
"details": "A malicious client can bypass the client certificate trust check of an opc.https server when the server endpoint is configured to allow only secure communication.",
"id": "GHSA-6g5p-c2f9-9435",
"modified": "2025-08-21T06:30:20Z",
"published": "2025-08-21T06:30:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-7390"
},
{
"type": "WEB",
"url": "https://industrial.softing.com/fileadmin/psirt/downloads/2025/CVE-2025-7390.html"
},
{
"type": "WEB",
"url": "https://industrial.softing.com/fileadmin/psirt/downloads/2025/CVE-2025-7390.json"
}
],
"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-6GGQ-GV3V-V28C
Vulnerability from github – Published: 2022-05-24 22:28 – Updated: 2024-09-16 18:31Dell EMC Unisphere for PowerMax versions prior to 9.1.0.17, Dell EMC Unisphere for PowerMax Virtual Appliance versions prior to 9.1.0.17, and PowerMax OS Release 5978 contain an improper certificate validation vulnerability. An unauthenticated remote attacker may potentially exploit this vulnerability to carry out a man-in-the-middle attack by supplying a crafted certificate and intercepting the victim's traffic to view or modify a victim’s data in transit.
{
"affected": [],
"aliases": [
"CVE-2020-5367"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-06-23T20:15:00Z",
"severity": "MODERATE"
},
"details": "Dell EMC Unisphere for PowerMax versions prior to 9.1.0.17, Dell EMC Unisphere for PowerMax Virtual Appliance versions prior to 9.1.0.17, and PowerMax OS Release 5978 contain an improper certificate validation vulnerability. An unauthenticated remote attacker may potentially exploit this vulnerability to carry out a man-in-the-middle attack by supplying a crafted certificate and intercepting the victim\u0027s traffic to view or modify a victim\u2019s data in transit.",
"id": "GHSA-6ggq-gv3v-v28c",
"modified": "2024-09-16T18:31:17Z",
"published": "2022-05-24T22:28:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-5367"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-uk/000153935/dsa-2020-065-dell-emc-unisphere-for-powermax-dell-emc-unisphere-for-powermax-virtual-appliance-and-dell-emc-powermax-embedded-management-update-for-multiple-vulnerabilities"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/security/en-us/details/544585/DSA-2020-065-Dell-EMC-Unisphere-for-PowerMax-Dell-EMC-Unisphere-for-PowerMax-Virtual-Appliance"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-6GMH-W7RJ-PRJM
Vulnerability from github – Published: 2026-09-03 21:31 – Updated: 2026-09-03 21:31IBM Netezza Software 11.3.0.3 through Interim Fix 002 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques.
{
"affected": [],
"aliases": [
"CVE-2026-9036"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-03T21:17:24Z",
"severity": "MODERATE"
},
"details": "IBM Netezza Software 11.3.0.3 through Interim Fix 002 does not validate or improperly validates TLS certificate validation, which could allow an attacker to obtain sensitive information using man in the middle techniques.",
"id": "GHSA-6gmh-w7rj-prjm",
"modified": "2026-09-03T21:31:17Z",
"published": "2026-09-03T21:31:17Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-9036"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7284359"
}
],
"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"
}
]
}
GHSA-6H99-8764-6J4P
Vulnerability from github – Published: 2024-03-13 06:30 – Updated: 2024-08-05 15:30The Toyoko Inn official App for iOS versions prior to 1.13.0 and Toyoko Inn official App for Android versions prior 1.3.14 don't properly verify server certificates, which allows a man-in-the-middle attacker to spoof servers and obtain sensitive information via a crafted certificate.
{
"affected": [],
"aliases": [
"CVE-2024-27440"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-03-13T06:15:52Z",
"severity": "MODERATE"
},
"details": "The Toyoko Inn official App for iOS versions prior to 1.13.0 and Toyoko Inn official App for Android versions prior 1.3.14 don\u0027t properly verify server certificates, which allows a man-in-the-middle attacker to spoof servers and obtain sensitive information via a crafted certificate.",
"id": "GHSA-6h99-8764-6j4p",
"modified": "2024-08-05T15:30:50Z",
"published": "2024-03-13T06:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-27440"
},
{
"type": "WEB",
"url": "https://apps.apple.com/jp/app/%E3%83%9B%E3%83%86%E3%83%AB%E6%9D%B1%E6%A8%AAinn-%E6%9D%B1%E6%A8%AA%E3%82%A4%E3%83%B3-%E5%85%AC%E5%BC%8F%E3%82%A2%E3%83%97%E3%83%AA/id1439388270"
},
{
"type": "WEB",
"url": "https://jvn.jp/en/jp/JVN52919306"
},
{
"type": "WEB",
"url": "https://play.google.com/store/apps/details?id=com.toyoko_inn.toyokoandroid"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-6HRM-JQP3-64CV
Vulnerability from github – Published: 2021-04-13 15:42 – Updated: 2023-01-26 22:35TweetStream 2.6.1 uses the library eventmachine in an insecure way that does not have TLS hostname validation. This allows an attacker to perform a man-in-the-middle attack.
{
"affected": [
{
"package": {
"ecosystem": "RubyGems",
"name": "tweetstream"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "2.6.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2020-24393"
],
"database_specific": {
"cwe_ids": [
"CWE-295"
],
"github_reviewed": true,
"github_reviewed_at": "2021-03-29T22:54:38Z",
"nvd_published_at": "2021-02-19T23:15:00Z",
"severity": "MODERATE"
},
"details": "TweetStream 2.6.1 uses the library eventmachine in an insecure way that does not have TLS hostname validation. This allows an attacker to perform a man-in-the-middle attack.",
"id": "GHSA-6hrm-jqp3-64cv",
"modified": "2023-01-26T22:35:31Z",
"published": "2021-04-13T15:42:36Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-24393"
},
{
"type": "PACKAGE",
"url": "https://github.com/tweetstream/tweetstream"
},
{
"type": "ADVISORY",
"url": "https://securitylab.github.com/advisories/GHSL-2020-096-tweetstream-tweetstream"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "Improper Certificate Validation in TweetStream"
}
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"
}
]
}
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.