Two fast-uri Host Parsing Flaws: Attack Conditions and Response

Two parser differences, one policy failure

CVE-2026-75899 and CVE-2026-75931 can make the host checked by an application differ from the host reached after another component parses the URI. Both matter when untrusted URLs are normalized or resolved before SSRF checks, redirect validation, host allowlists, or proxy routing.

Double decoding

CVE-2026-75899 affects fast-uri 2.4.1 through 2.4.4, 3.1.2 through 3.1.5, and 4.0.0 through 4.1.2. A nested percent-encoded hostname can be decoded during parsing and again during authority recomposition. The final destination can therefore differ from the encoded host that a policy expected to evaluate.

Scheme-relative IDN handling

CVE-2026-75931 affects 2.4.2 through 2.4.4, 3.1.3 through 3.1.5, and 4.0.1 through 4.1.2. When resolve() combines a scheme-relative reference with a scheme-bearing base, host canonicalization can be skipped. Re-parsing the resolved URI may then produce a different effective host.

Response

1. Inventory fast-uri in every lockfile and deployed image.
2. Find normalize() and resolve() calls that process webhooks, redirects, proxies, or fetch targets.
3. Trace the host value at policy time and at the final HTTP client.
4. Upgrade to 2.4.5, 3.1.6, or 4.1.3 as appropriate.
5. Regression-test nested percent encoding, scheme-relative references, IDNs, and redirect chains.

Before patching, reject encoded percent signs in untrusted host components for the double-decoding path. Resolve scheme-relative references against a scheme-bearing base before host-policy checks. Keep final-destination and resolved-address validation as defense in depth.

Verification time

The two fast-uri GitHub security advisories were rechecked for the August 25, 2026 14:00 KST cycle.