fast-uri vulnerable to host confusion via unchecked WHATWG host canonicalizationGHSA-wjr9-j795-jxcr
MEDIUMFix: fastify/fast-uri@58c183dGHSA-wjr9-j795-jxcr is a medium-severity (CVSS 4.8) Improper Input Validation vulnerability in fast-uri. A fix is available for fast-uri — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-wjr9-j795-jxcr.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-wjr9-j795-jxcr by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.
fast-urinpmDescription
Impact
fast-uri versions >= 2.4.2, <= 2.4.7, >= 3.1.3, <= 3.1.8, and >= 4.0.1, <= 4.2.2 can silently rewrite the host of an HTTP-family URL (http, https, ws, wss, or any scheme with domainHost: true). For those schemes canonicalizeHost() passes the parsed host to the WHATWG URL parser and adopts its .hostname without checking that the parser read the whole input as a host. RFC 3986 permits @ inside the host group and the WHATWG parser strips TAB, LF, and CR, so the authority fast-uri reports is rewritten by that second parser with no error set: data before an @ is dropped and whitespace is removed.
For example, fast-uri parses http://a@[email protected]/ to host evil.example (dropping the b segment), and a host containing a raw TAB, CR, or LF has those characters stripped. equal() then treats a whitespace-smuggled host as the same as the clean one, and resolve() rewrites the authority the same way.
Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) on one representation, such as the raw input, see a policy/use desync: the canonical host fast-uri returns differs from what was checked, and traffic can be steered to an unintended destination.
Patches
Upgrade to fast-uri 2.4.8, 3.1.9, or 4.2.3.
Workarounds
Reject URIs whose authority contains more than one @, or contains TAB, CR, or LF, before calling fast-uri. Alternatively, treat any non-empty parse(x).error as fatal, and compare hosts only from the same parse() result.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | fast-uri | ≥ 2.4.2&&< 2.4.8 | 2.4.8npm install fast-uri@2.4.8 |
| 📦npm | fast-uri | ≥ 3.1.3&&< 3.1.9 | 3.1.9npm install fast-uri@3.1.9 |
| 📦npm | fast-uri | ≥ 4.0.1&&< 4.2.3 | 4.2.3npm install fast-uri@4.2.3 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for fast-uri, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update fast-uri to 2.4.8 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-wjr9-j795-jxcr is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-wjr9-j795-jxcr in your dependencies?
Find it across npm, including transitive dependencies.