GHSA-fph4-wmhf-6fwf: SSRF

Q: Which applications are exposed in practice?

Applications are exposed when they pass an untrusted URI through fast-uri's normalize() or resolve() before enforcing an SSRF control, redirect destination validation, or host allowlist. The issue can make an encoded hostname normalize to a different destination, including loopback or cloud metadata endpoints.

Q: What does an attacker need to exploit this?

An attacker needs to supply a URI with a hostname containing nested percent encoding, such as encoded percent signs that survive the first decode and become active during authority recomposition. No authentication or user interaction is required according to the supplied severity vector.

Q: Are fixed versions available?

Yes. The issue is fixed in fast-uri 2.4.5, 3.1.6, and 4.1.3.

Published Sep 2, 2026

Updated

Impact

fast-uri decodes a hostname's percent escapes twice in a single normalize() or resolve() call: once during parsing and again during authority recomposition. A nested percent-encoded host therefore survives the first decode and is turned into a live destination by the second, so normalize('http://%256c%256f%2563%2561%256c%2568%256f%2573%2574/') returns http://localhost/. Applications that normalize or resolve an untrusted URI before an SSRF check, redirect validation, or host allowlist can be steered to a different destination, including internal addresses such as loopback or a cloud metadata endpoint, than the encoded input appeared to contain. This is an incomplete-fix variant of CVE-2026-6322, whose encoded-authority-delimiter fix introduced the second decode.

Patches

Fixed in fast-uri 2.4.5, 3.1.6, and 4.1.3.

Workarounds

Reject untrusted URIs whose host component contains an encoded percent sign (%25) before passing them to normalize() or resolve().

Affected Software

3 affected componentsFixes available

npm/fast-uri>=4.0.0<4.1.3

4.1.3

npm/fast-uri>=3.1.2<3.1.6

3.1.6

npm/fast-uri>=2.4.1<2.4.5

2.4.5

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade npm/fast-uri to a version that resolves this vulnerability.
Fixed in 4.1.3
Upgrade
Upgrade npm/fast-uri to a version that resolves this vulnerability.
Fixed in 3.1.6
Upgrade
Upgrade npm/fast-uri to a version that resolves this vulnerability.
Fixed in 2.4.5
Upgrade
Upgrade fast-uri to a version that resolves this vulnerability.
Fixed in 2.4.5
Upgrade
Upgrade fast-uri to a version that resolves this vulnerability.
Fixed in 3.1.6
Upgrade
Upgrade fast-uri to a version that resolves this vulnerability.
Fixed in 4.1.3
Configuration
Before passing an untrusted URI to fast-uri normalize() or resolve(), reject it if the host component contains an encoded percent sign (%25); do not run normalize()/resolve() on such inputs.
fast-uri URI host percent-encoding validation = Reject any untrusted URI whose host contains encoded percent sign (%25) before calling normalize() or resolve()

Event History

Sep 2, 2026

Advisory Published

via GitHub·03:42 PM

Data Sourced

via GitHub·03:42 PM

DescriptionSeverityWeaknessAffected Software

Frequently Asked Questions

Which applications are exposed in practice?

Applications are exposed when they pass an untrusted URI through fast-uri's normalize() or resolve() before enforcing an SSRF control, redirect destination validation, or host allowlist. The issue can make an encoded hostname normalize to a different destination, including loopback or cloud metadata endpoints.

What does an attacker need to exploit this?

An attacker needs to supply a URI with a hostname containing nested percent encoding, such as encoded percent signs that survive the first decode and become active during authority recomposition. No authentication or user interaction is required according to the supplied severity vector.

Are fixed versions available?

Yes. The issue is fixed in fast-uri 2.4.5, 3.1.6, and 4.1.3.

What can be done if upgrading is not immediately possible?

Reject untrusted URIs whose host component contains an encoded percent sign (%25) before passing the URI to normalize() or resolve(). This specifically prevents the nested percent-encoded hostname from being decoded twice.