{"dataType": "CVE_RECORD", "dataVersion": "5.2", "cveMetadata": {"cveId": "CVE-2026-86472", "assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "state": "PUBLISHED", "assignerShortName": "openjs", "dateReserved": "2026-09-07T15:02:14.920Z", "datePublished": "2026-09-15T10:29:50.594Z", "dateUpdated": "2026-09-15T12:35:44.789Z"}, "containers": {"cna": {"providerMetadata": {"orgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "shortName": "openjs", "dateUpdated": "2026-09-15T10:29:50.594Z"}, "descriptions": [{"lang": "en", "value": "fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision.", "supportingMedia": [{"type": "text/html", "base64": false, "value": "fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision."}]}], "affected": [{"vendor": "fast-uri", "product": "fast-uri", "defaultStatus": "unaffected", "versions": [{"versionType": "semver", "status": "affected", "version": "0", "lessThan": "2.4.7"}, {"versionType": "semver", "status": "unaffected", "version": "2.4.7"}, {"versionType": "semver", "status": "affected", "version": "3.0.0", "lessThan": "3.1.8"}, {"versionType": "semver", "status": "unaffected", "version": "3.1.8"}, {"versionType": "semver", "status": "affected", "version": "4.0.0", "lessThan": "4.1.5"}, {"versionType": "semver", "status": "unaffected", "version": "4.1.5"}], "packageURL": "pkg:npm/fast-uri"}], "references": [{"url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-hrr3-gc8f-f4qj"}, {"url": "https://cna.openjsf.org/security-advisories.html"}], "credits": [{"lang": "en", "type": "reporter", "value": "fg0x0"}, {"lang": "en", "type": "remediation developer", "value": "mcollina"}, {"lang": "en", "type": "remediation reviewer", "value": "UlisesGascon"}], "title": "fast-uri vulnerable to inconsistent host case normalization via percent-encoded octets", "metrics": [{"format": "CVSS", "cvssV3_1": {"version": "3.1", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N", "baseScore": 4.8, "baseSeverity": "MEDIUM"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "problemTypes": [{"descriptions": [{"cweId": "CWE-178", "lang": "en", "description": "CWE-178: Improper Handling of Case Sensitivity", "type": "CWE"}]}], "x_generator": {"engine": "cve-kit 1.0.0"}}, "adp": [{"metrics": [{"other": {"type": "ssvc", "content": {"timestamp": "2026-09-15T12:35:19.770627Z", "id": "CVE-2026-86472", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "role": "CISA Coordinator", "version": "2.0.3"}}}], "title": "CISA ADP Vulnrichment", "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-09-15T12:35:44.789Z"}}]}}

{"dataType": "CVE_RECORD", "containers": {"adp": [{"title": "CISA ADP Vulnrichment", "metrics": [{"other": {"type": "ssvc", "content": {"id": "CVE-2026-86472", "role": "CISA Coordinator", "options": [{"Exploitation": "none"}, {"Automatable": "no"}, {"Technical Impact": "partial"}], "version": "2.0.3", "timestamp": "2026-09-15T12:35:19.770627Z"}}}], "providerMetadata": {"orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "shortName": "CISA-ADP", "dateUpdated": "2026-09-15T12:35:33.623Z"}}], "cna": {"title": "fast-uri vulnerable to inconsistent host case normalization via percent-encoded octets", "credits": [{"lang": "en", "type": "reporter", "value": "fg0x0"}, {"lang": "en", "type": "remediation developer", "value": "mcollina"}, {"lang": "en", "type": "remediation reviewer", "value": "UlisesGascon"}], "metrics": [{"format": "CVSS", "cvssV3_1": {"version": "3.1", "baseScore": 4.8, "baseSeverity": "MEDIUM", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N"}, "scenarios": [{"lang": "en", "value": "GENERAL"}]}], "affected": [{"vendor": "fast-uri", "product": "fast-uri", "versions": [{"status": "affected", "version": "0", "lessThan": "2.4.7", "versionType": "semver"}, {"status": "unaffected", "version": "2.4.7", "versionType": "semver"}, {"status": "affected", "version": "3.0.0", "lessThan": "3.1.8", "versionType": "semver"}, {"status": "unaffected", "version": "3.1.8", "versionType": "semver"}, {"status": "affected", "version": "4.0.0", "lessThan": "4.1.5", "versionType": "semver"}, {"status": "unaffected", "version": "4.1.5", "versionType": "semver"}], "packageURL": "pkg:npm/fast-uri", "defaultStatus": "unaffected"}], "references": [{"url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-hrr3-gc8f-f4qj"}, {"url": "https://cna.openjsf.org/security-advisories.html"}], "x_generator": {"engine": "cve-kit 1.0.0"}, "descriptions": [{"lang": "en", "value": "fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision.", "supportingMedia": [{"type": "text/html", "value": "fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision.", "base64": false}]}], "problemTypes": [{"descriptions": [{"lang": "en", "type": "CWE", "cweId": "CWE-178", "description": "CWE-178: Improper Handling of Case Sensitivity"}]}], "providerMetadata": {"orgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "shortName": "openjs", "dateUpdated": "2026-09-15T10:29:50.594Z"}}}, "cveMetadata": {"cveId": "CVE-2026-86472", "state": "PUBLISHED", "dateUpdated": "2026-09-15T12:35:44.789Z", "dateReserved": "2026-09-07T15:02:14.920Z", "assignerOrgId": "ce714d77-add3-4f53-aff5-83d477b104bb", "datePublished": "2026-09-15T10:29:50.594Z", "assignerShortName": "openjs"}, "dataVersion": "5.2"}

{"affected": [{"affectedData": [{"defaultStatus": "unaffected", "packageURL": "pkg:npm/fast-uri", "product": "fast-uri", "vendor": "fast-uri", "versions": [{"lessThan": "2.4.7", "status": "affected", "version": "0", "versionType": "semver"}, {"status": "unaffected", "version": "2.4.7", "versionType": "semver"}, {"lessThan": "3.1.8", "status": "affected", "version": "3.0.0", "versionType": "semver"}, {"status": "unaffected", "version": "3.1.8", "versionType": "semver"}, {"lessThan": "4.1.5", "status": "affected", "version": "4.0.0", "versionType": "semver"}, {"status": "unaffected", "version": "4.1.5", "versionType": "semver"}]}], "source": "ce714d77-add3-4f53-aff5-83d477b104bb"}], "cveTags": [], "descriptions": [{"lang": "en", "value": "fast-uri is a dependency-free RFC 3986 URI parser for Node.js, used by Fastify and ajv. In versions before 2.4.7, from 3.0.0 through 3.1.7, and from 4.0.0 through 4.1.4, fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference such as //host there is no scheme, so the host canonicalization that would normally repair this does not run, and parse, normalize, and equal then disagree on the same host. An application that makes a case-sensitive host decision on fast-uri output, for example a host allowlist or denylist that compares the parsed host or uses equal, can be steered past the check with a percent-encoded uppercase octet, and because hostnames are case-insensitive in DNS and HTTP the evading spelling still reaches the host the check meant to gate. The issue is fixed in fast-uri 2.4.7, 3.1.8, and 4.1.5, and users should upgrade to one of those versions or later. As a workaround, compare hosts case-insensitively by lowercasing the parsed host before any allowlist or denylist decision."}], "id": "CVE-2026-86472", "lastModified": "2026-09-15T13:16:43.810", "metrics": {"cvssMetricV31": [{"cvssData": {"attackComplexity": "HIGH", "attackVector": "NETWORK", "availabilityImpact": "NONE", "baseScore": 4.8, "baseSeverity": "MEDIUM", "confidentialityImpact": "LOW", "integrityImpact": "LOW", "privilegesRequired": "NONE", "scope": "UNCHANGED", "userInteraction": "NONE", "vectorString": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N", "version": "3.1"}, "exploitabilityScore": 2.2, "impactScore": 2.5, "source": "ce714d77-add3-4f53-aff5-83d477b104bb", "type": "Secondary"}], "ssvcV203": [{"source": "134c704f-9b21-4f2e-91b3-4a467353bcc0", "ssvcData": {"id": "CVE-2026-86472", "options": [{"exploitation": "none"}, {"automatable": "no"}, {"technicalImpact": "partial"}], "role": "CISA Coordinator", "timestamp": "2026-09-15T12:35:19.770627Z", "version": "2.0.3"}}]}, "published": "2026-09-15T11:17:12.327", "references": [{"source": "ce714d77-add3-4f53-aff5-83d477b104bb", "url": "https://cna.openjsf.org/security-advisories.html"}, {"source": "ce714d77-add3-4f53-aff5-83d477b104bb", "url": "https://github.com/fastify/fast-uri/security/advisories/GHSA-hrr3-gc8f-f4qj"}], "sourceIdentifier": "ce714d77-add3-4f53-aff5-83d477b104bb", "vulnStatus": "Received", "weaknesses": [{"description": [{"lang": "en", "value": "CWE-178"}], "source": "ce714d77-add3-4f53-aff5-83d477b104bb", "type": "Secondary"}]}

{}

{"affected": [{"configurations": [{"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[0,2.4.7)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "2.4.7"}}, {"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[3.0.0,3.1.8)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "3.1.8"}}, {"platform": null, "status": "affected", "versions": {"scheme": "semver", "value": "[4.0.0,4.1.5)"}}, {"platform": null, "status": "unaffected", "versions": {"scheme": "semver", "value": "4.1.5"}}], "enrichment": {"confidence": 100.0, "confidence_source": "matching", "scores": [{"score": 100.0, "source": "matching"}]}, "original": {"product": "fast-uri", "source": "cna", "vendor": "fast-uri"}, "product": "fast-uri", "vendor": "fast-uri"}], "created": "2026-09-15T11:30:11.772322+00:00", "updated": "2026-09-15T11:30:11.772345+00:00", "vendors": ["fast-uri", "fast-uri$PRODUCT$fast-uri"]}