CVE-2026-6321

What it actually does

fast-uri versions 3.1.0 and earlier incorrectly decode percent-encoded path separators and dot-segment sequences before applying URI dot-segment removal in normalize() and equal(). As a result, encoded path components such as encoded slashes or parent-directory references can be interpreted as real path structure during normalization. Software that relies on fast-uri normalization or URI equality checks for allowlists, deny lists, routing constraints, cache keys, authorization decisions, redirect validation, or path-prefix enforcement may incorrectly treat two distinct URIs as equivalent or may believe a URI remains under an allowed path when it actually resolves elsewhere. The primary technical impact is integrity loss through policy bypass; the vulnerability does not directly provide code execution or data disclosure by itself, but downstream application logic can make the impact more severe.

Why it matters to the business

Applications using vulnerable fast-uri versions for security-relevant URL or path decisions may allow users to bypass access controls, routing restrictions, URL allowlists, or content isolation boundaries. This can lead to unauthorized operations, incorrect resource access, cache poisoning or routing confusion depending on how the application uses normalized URIs. The EPSS score is currently low and there is no known KEV listing or confirmed exploit maturity in the provided data, but the package may be widely embedded through JavaScript dependency trees, so organizations should treat exposure as a supply-chain hygiene and application logic risk rather than only checking direct dependencies.

How an attack unfolds

An attacker first identifies an application endpoint that accepts a URL or path and uses fast-uri normalize() or equal() to enforce a path-based policy, such as requiring a URL to remain under an allowed prefix. The attacker then crafts a URI containing percent-encoded path separators and/or percent-encoded dot segments. Because affected versions decode those sequences too early, the library may collapse the supplied URI into a normalized value that differs from how other components, proxies, routers, storage layers, or application authorization logic interpret it. If the application trusts the vulnerable normalized result, the attacker can make a malicious path appear equivalent to an allowed path, or make a path appear confined beneath an approved prefix while causing the application to act on a different location. Successful exploitation depends on vulnerable application integration; the library flaw is a normalization primitive that becomes exploitable when its output is used for security decisions.

How to fix it

Upgrade openjsf fast-uri to version 3.1.1 or later wherever it is present, including transitive dependency instances in lockfiles and bundled artifacts. Rebuild and redeploy applications after dependency updates so the fixed library is actually included in runtime packages. If immediate upgrade is not possible, avoid using fast-uri normalize() or equal() from affected versions for security decisions on attacker-controlled input. As a compensating control, reject ambiguous encoded path input before policy evaluation, especially encoded slashes, encoded backslashes, and encoded dot segments; perform URL parsing and authorization using a single canonical representation; and ensure the same component that validates a path is also the component that consumes it. Review application code for path-prefix checks, allowlist checks, redirect validation, reverse-proxy URL handling, cache key derivation, and request routing logic that depends on URI normalization.

How to confirm the fix worked

Confirm dependency resolution shows fast-uri version 3.1.1 or later in package manifests, lockfiles, SBOMs, and deployed artifacts. For npm-based projects, check package-lock.json, yarn.lock, pnpm-lock.yaml, and generated SBOMs for fast-uri versions less than or equal to 3.1.0. Run application regression tests using encoded path separator and dot-segment payloads to verify that authorization, allowlist, and routing decisions are not bypassed. Validate that the runtime container, serverless bundle, or deployed package contains the upgraded dependency rather than only the source repository. Where the library is transitive, use dependency tree tooling to identify the parent package and update or override dependency versions as needed.

Typical attack path

1. Discover an application feature that accepts attacker-controlled URLs or paths, such as redirect targets, API resource paths, import URLs, proxy fetch URLs, cache keys, or file-like route paths.
2. Determine whether the application performs path-prefix checks, allowlist comparisons, or URI equality checks before taking an action.
3. Submit test payloads containing encoded path separators and encoded dot segments, such as encoded slashes combined with encoded parent-directory references.
4. Compare application behavior across raw, decoded, and normalized variants to identify discrepancies between policy checks and final resource handling.
5. Craft a final URI that passes the application’s normalization-based policy check while resolving to a disallowed route, resource, or action.
6. Use the bypass to perform the unauthorized operation permitted by the affected application logic.

How to detect it

Detection should focus on evidence of attempted path normalization bypass in application, reverse proxy, CDN, WAF, API gateway, and web server logs. Look for requests containing percent-encoded slashes, backslashes, and dot segments, especially repeated attempts with variations in encoding case or double encoding. High-signal events include encoded traversal sequences submitted to endpoints that accept redirect URLs, proxy URLs, import/fetch URLs, file paths, object keys, route paths, or API resource identifiers. Compare the raw request URI captured at the edge with the route, resource, or authorization decision recorded by the application; exploitation may appear as a request that was allowed under one path prefix but resulted in access to a different resource or action. Because this is a library-level canonicalization issue, there may be no unique product log message. Investigate abnormal 2xx/3xx responses following earlier 403/404 probing attempts that differ only by encoded separators or dot segments. If available, review application audit logs for authorization decisions involving normalized URLs and compare them to the original unmodified input.

• %2e%2e
• %2E%2E
• %2f
• %2F
• %5c
• %5C
• %2e%2e%2f
• %2E%2E%2F
• %2e%2e%5c
• %2E%2E%5C
• %2f..%2f
• %2F..%2F
• %252e%252e
• %252f
• %255c
• /%2e/
• /%2E/
• /%2e%2e/
• /%2E%2E/

What your security team should do

• Inventory all applications and services that include openjsf fast-uri directly or transitively, prioritizing externally reachable services that process user-supplied URLs or paths.
• Upgrade fast-uri to 3.1.1 or later and regenerate lockfiles and deployment artifacts.
• Search code for security decisions based on normalize() or equal() results, especially prefix checks, URI allowlists, redirect checks, proxy routing, and cache key generation.
• Add negative security tests using encoded slashes, encoded backslashes, and encoded dot segments to prevent regression.
• Monitor web and API logs for probing patterns involving percent-encoded traversal and encoded path separators, especially where requests target sensitive or policy-controlled paths.
• If vulnerable usage is found in externally exposed authorization or routing logic, treat suspicious historical requests as potential policy-bypass attempts and perform targeted log review.
• Use dependency scanning and SBOM policy checks to block fast-uri versions 3.1.0 and earlier from future releases.