CVE-2026-110095: fast-uri vulnerable to improper path equivalence in relative reference normalization
Impact
fast-uri's normalize() and serialize() apply RFC 3986 dot-segment removal (removedotsegments) to the path of a relative-path reference. RFC 3986 section 5.2.4 defines that algorithm only for the merged target path during resolution, not for the reference itself, so applied to the reference it drops leading .. segments and can turn a document-relative reference into a root-relative one.
For example, normalize('a/../b') returns /b and normalize('../x') returns x, so resolve(base, normalize(ref)) points at a different resource than resolve(base, ref), and equal() treats distinct references as the same.
Applications that normalize attacker-supplied or user-supplied relative references and then resolve them, or use them as cache, deduplication, or authorization keys, can have a reference escape its intended directory and point at a different resource.
Patches
Upgrade to fast-uri 2.4.8, 3.1.9, or 4.2.3.
Workarounds
Do not normalize a relative reference before resolving it. Resolve it against the absolute base first, then normalize the absolute result.
Other sources
fast-uri is a dependency-free RFC 3986 URI parser and serializer for Node.js. In versions before 2.4.8, from 3.0.0 through 3.1.8, and from 4.0.0 through 4.2.2, the normalize() and serialize() functions apply RFC 3986 dot-segment removal to the path of a relative-path reference, even though that algorithm is defined only for the merged target path during resolution, so a leading parent-directory segment can be dropped and a document-relative reference can become root-relative. An application that normalizes an attacker-supplied or user-supplied relative reference and then resolves it, or uses it as a cache, deduplication, or authorization key, can have the reference escape its intended directory and point at a different resource. The issue is fixed in fast-uri 2.4.8, 3.1.9, and 4.2.3, and users should upgrade to one of these versions or later. As a workaround, resolve a relative reference against its absolute base first and normalize the absolute result instead of normalizing the reference beforehand.
— Ubuntu
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/fast-urito a version that resolves this vulnerability.Fixed in 4.2.3 - Upgrade
Upgrade
npm/fast-urito a version that resolves this vulnerability.Fixed in 3.1.9 - Upgrade
Upgrade
npm/fast-urito a version that resolves this vulnerability.Fixed in 2.4.8 - Upgrade
Upgrade
debian/node-ajvto a version that resolves this vulnerability.Fixed in 8.20.0~ds+~cs7.2.4-1 - Upgrade
Upgrade
fast-urito a version that resolves this vulnerability.Fixed in 2.4.8 - Upgrade
Upgrade
fast-urito a version that resolves this vulnerability.Fixed in 3.1.9 - Upgrade
Upgrade
fast-urito a version that resolves this vulnerability.Fixed in 4.2.3 - Compensating control
Resolve a relative reference against its absolute base first, then normalize the absolute result; do not normalize a relative reference before resolving it.
Event History
Frequently Asked Questions
Which applications are exposed to this issue?
Applications are exposed if they normalize an attacker-supplied or user-supplied relative URI reference before resolving it, or if they use that normalized reference as a cache, deduplication, or authorization key. The impact is that a document-relative reference may escape its intended directory and refer to a different resource.
Is an attacker required to authenticate or interact with a user to exploit this?
No authentication or user interaction is required according to the provided vector. Exploitation requires an attacker-controlled or user-controlled relative reference to reach the affected normalization or serialization flow, and the attack complexity is high.
What should be done if an immediate upgrade is not possible?
Resolve the relative reference against its absolute base first, then normalize the resulting absolute URI. Do not normalize the relative reference before resolution.
How can I determine whether a deployed version is affected?
Affected versions are versions before 2.4.8, versions from 3.0.0 through 3.1.8, and versions from 4.0.0 through 4.2.2. Fixed versions are 2.4.8, 3.1.9, and 4.2.3 or later.