CVE-2026-86472.

Disclosure summary

### Impact `fast-uri` folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase unreserved octet such as `%41` decodes to a literal `A` that is never folded. For a scheme-relative reference (`//host`) there is no scheme, so the host canonicalization that repairs this on a scheme-bearing URL does not run. As a result `parse`, `normalize`, and `equal` disagree on the same host: `parse("//%41.com").host` returns `"A.com"` while `parse("//a.com").host` and `parse("//A.com").host` return `"a.com"`, and `equal("//%41.com", "//a.com")` is `false` even though `equal("//A.com", "//a.com")` is `true`. An application that makes a case-sensitive host decision on `fast-uri` output for a scheme-relative reference, for example a host allowlist or denylist that compares `parse(url).host` or uses `fast-uri.equal`, can be steered past the check with a percent-encoded uppercase octet. Because a hostname is case-insensitive in DNS and HTTP routing, the evading spelling reaches the same host the check meant to gate, so the effect is check evasion rather than reaching a different registrable host. ### Patches Upgrade to `fast-uri` 4.1.5, 3.1.8, or 2.4.7. ### Workarou

Source-specific records & product guidance

Sources retain their own attribution and scoring. Follow the original record to confirm affected versions, fixed releases, and configuration conditions.

Original records & references

• NIST NVD record
• CVE Program record
• github.com — Reviewed advisory

PUBLISHED 2026-09-29T19:54:25-04:00
MODIFIED 2026-09-29T19:54:26-04:00
INGESTED 2026-10-06T11:43:09-04:00