Skip to content

← Public intelligence

npm package

fast-uri

Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.

Open advisories

17 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 6.1npmAmendedPublished

    fast-uri vulnerable to URI scheme spoofing via percent-encoded scheme decoding

    CVE-2026-110306 · GHSA-w74x-v6f9-j3xg

    Affected
    • npm fast-uri < 2.4.8; >= 3.0.0, < 3.1.9; >= 4.0.0, < 4.2.3
    Fixed in
    2.4.84.2.33.1.9· Vendor fix available
    Issue
    Impact fast-uri percent-decodes the scheme component with the legacy global unescape() before validating it, so an input whose decoded scheme is a valid but dangerous token is emitted as a live scheme. RFC 3986 section 3.1 does not allow percent-encoding in a scheme, so no RFC or WHATWG parser treats such input as having that scheme, but fast-uri does. For example, normalize('%6Aavascript:alert(1)') returns javascript:alert(1), resolve('https://a.example/', '%6Aavascript:alert(1)') returns javascript:alert(1), and parse('%6Aavascript:alert(1)').scheme returns javascript. The %uXXXX form (%u006Aavascript:) produces the same result, and equal('%68ttp://a/', 'http://a/') returns true. An application that screens dangerous schemes on the raw input and then stores or renders normalize(input) or resolve(base, input) turns an inert string into an executable javascript:, data:, or vbscript: URL, a stored or reflected cross-site scripting vector in the consuming application. equal() also…

    Recommended action: Upgrade to 4.2.3, 3.1.9 or 2.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  2. Low, CVSS 3.7npmAmendedPublished

    fast-uri vulnerable to improper path equivalence in relative reference normalization

    CVE-2026-110095 · GHSA-xhq7-xmqj-769h

    Affected
    • npm fast-uri < 2.4.8; >= 3.0.0, < 3.1.9; >= 4.0.0, < 4.2.3
    Fixed in
    2.4.84.2.33.1.9· Vendor fix available
    Issue
    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…

    Recommended action: Upgrade to 4.2.3, 3.1.9 or 2.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  3. Medium, CVSS 4.8npmAmendedPublished

    fast-uri vulnerable to host confusion via unchecked WHATWG host canonicalization

    CVE-2026-110180 · GHSA-wjr9-j795-jxcr

    Affected
    • npm fast-uri >= 2.4.2, < 2.4.8; >= 3.1.3, < 3.1.9; >= 4.0.1, < 4.2.3
    Fixed in
    2.4.84.2.33.1.9· Vendor fix available
    Issue
    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@b@evil.example/ 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,…

    Recommended action: Upgrade to 4.2.3, 3.1.9 or 2.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  4. Low, CVSS 3.7npmAmendedPublished

    fast-uri vulnerable to scheme injection via an unescaped first-segment colon in suffix references

    CVE-2026-110725 · GHSA-333x-w4r6-6crp

    Affected
    • npm fast-uri < 2.4.8; >= 3.0.0, < 3.1.9; >= 4.0.0, < 4.2.3
    Fixed in
    2.4.84.2.33.1.9· Vendor fix available
    Issue
    Impact fast-uri's serialize(), normalize(), and resolve(), when called with the non-default option reference: 'suffix' on a reference that has no authority, emit a relative reference whose first path segment contains a bare colon without escaping it. RFC 3986 section 3.3 requires the first segment of a path-noscheme reference not to contain a colon, precisely because a bare colon makes the string reparse as an absolute URI with a scheme. fast-uri's default serialization escapes that colon, but the suffix path does not. For example, normalize('javascript:alert(1)', { reference: 'suffix' }) returns javascript:alert(1), which reparses as a live javascript: scheme; data: and vbscript: behave the same. Applications that serialize or normalize a relative reference with reference: 'suffix' and then treat the result as a URI can turn inert input into a live javascript:, data:, or vbscript: URL (a cross-site scripting vector), and equal() can conflate a scheme-bearing reference with a…

    Recommended action: Upgrade to 4.2.3, 3.1.9 or 2.4.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  5. Medium, CVSS 4.8npmAmendedPublished

    fast-uri vulnerable to inconsistent host case normalization via percent-encoded octets

    CVE-2026-86472 · GHSA-hrr3-gc8f-f4qj

    Affected
    • npm fast-uri < 2.4.7; >= 3.0.0, < 3.1.8; >= 4.0.0, < 4.1.5
    Fixed in
    4.1.52.4.73.1.8· Vendor fix available
    Issue
    Impact fast-uri folds the host to lowercase before it percent-decodes the host, so a percent-encoded uppercase unreserved octet such as %41 decodes to a literal A that is never folded. For a scheme-relative reference (//host) there is no scheme, so the host canonicalization that repairs this on a scheme-bearing URL does not run. As a result parse, normalize, and equal disagree on the same host: parse("//%41.com").host returns "A.com" while parse("//a.com").host and parse("//A.com").host return "a.com", and equal("//%41.com", "//a.com") is false even though equal("//A.com", "//a.com") is true. An application that makes a case-sensitive host decision on fast-uri output for a scheme-relative reference, for example a host allowlist or denylist that compares parse(url).host or uses fast-uri.equal, can be steered past the check with a percent-encoded uppercase octet. Because a hostname is case-insensitive in DNS and HTTP routing, the evading spelling reaches the same host the check meant…

    Recommended action: Upgrade to 4.1.5, 3.1.8 or 2.4.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  6. Medium, CVSS 4.8npmAmendedPublished

    fast-uri vulnerable to mailto header injection via percent-encoded field-name desynchronization

    CVE-2026-86818 · GHSA-jvvf-x445-j334

    Affected
    • npm fast-uri >= 4.1.3, < 4.1.5
    Fixed in
    4.1.5· Vendor fix available
    Issue
    Impact fast-uri's mailto scheme parser compares each query field name to the reserved names (to, subject, body) while the name is still percent-encoded, and only percent-decodes it when storing it as a generic header. On serialize, the decoded name is re-emitted, so a field name such as %74o (percent-encoded to) is not recognized as a recipient at parse time (parse().to shows only the legitimate recipient) but materializes as a literal to= field after serialize(), and reparsing then treats it as a recipient. The same technique smuggles subject and body through %73ubject and %62ody. An application that parses an untrusted mailto URI, makes a display, allowlist, or logging decision on parse().to, then re-serializes the result and passes the serialized string to a mail client or an outbound send path can gain an attacker-chosen recipient, subject, or body that was not visible when the recipient list was checked. A scanner inspecting the raw input for an extra to= sees nothing, because…

    Recommended action: Upgrade to 4.1.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  7. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to authority injection via an unvalidated port in serialize

    CVE-2026-84292 · GHSA-qw65-cvwx-89v3

    Affected
    • npm fast-uri < 2.4.6; >= 3.0.0, < 3.1.7; >= 4.0.0, < 4.1.4
    Fixed in
    3.1.74.1.42.4.6· Vendor fix available
    Issue
    Impact fast-uri serializes the port component of a URI without validating it. When recomposing the authority, fast-uri escapes the userinfo and host components but concatenates the port verbatim, so a port value that is not a sequence of digits can inject authority delimiters. For example, serializing a component whose port is @127.0.0.1:8124 produces http://trusted.example:@127.0.0.1:8124/app, demoting the intended host to userinfo and pointing the authority at an attacker-controlled host. Both fast-uri and Node's URL read the result back as the attacker's host with no error, so re-validating the built URI does not catch it. This affects applications that build URIs from parts and assign untrusted data to the port component (for example a fixed host from configuration and a port taken from user input or a service record). The same path is reachable through serialize(), normalize(), and equal() in their object forms. A port obtained from parse() is always digits and is not affected.…

    Recommended action: Upgrade to 4.1.4, 3.1.7 or 2.4.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  8. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to host confusion via an unclosed bracket in the URI authority

    CVE-2026-84394 · GHSA-58mr-gqgx-xq4g

    Affected
    • npm fast-uri >= 2.4.5, <= 2.4.5; >= 3.1.6, <= 3.1.6; >= 4.1.3, <= 4.1.3
    Fixed in
    3.1.74.1.42.4.6· Vendor fix available
    Issue
    Impact fast-uri accepts a host that contains an unbalanced or misplaced authority bracket ([ or ]) without reporting an error. A host that starts with [ but does not end with ], such as [@127.0.0.1, is neither validated as an IP literal nor canonicalized as a domain name, so parse() returns it as the host with error undefined, while Node's URL (and http.get, axios, got, and other clients built on it) resolve the same string to 127.0.0.1. An application that reads parse().host to make a host decision (an SSRF denylist, a redirect allowlist, or proxy routing) and then passes the original URL to an HTTP client evaluates its policy against a string that is not the host the request reaches. The same host is carried through normalize(), equal(), and resolve(). Patches This vulnerability has been patched in fast-uri 4.1.4, 3.1.7, and 2.4.6. parse() now reports URI host is malformed. for any host that contains a bracket but is not a valid [IPv6] literal. All users should upgrade. Workarounds…

    Recommended action: Upgrade to 4.1.4, 3.1.7 or 2.4.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.com (1)osv.dev (2)Source checked Evidence →
  9. High, CVSS 7.5npmPublished

    fast-uri vulnerable to host confusion via skipped IDN canonicalization on scheme-relative references

    CVE-2026-75931 · GHSA-5jgf-p345-68v8

    Affected
    • npm fast-uri >= 2.4.2, < 2.4.5; >= 3.1.3, < 3.1.6; >= 4.0.1, < 4.1.3
    Fixed in
    2.4.54.1.33.1.6· Vendor fix available
    Issue
    Impact fast-uri canonicalizes a host to its ASCII form only when the input carries an explicit scheme. When resolve() resolves a scheme-relative reference (//host/) against a scheme-bearing base, it still emits the host verbatim even though the effective scheme is known, so re-parsing the resolved URI yields a different host than the one resolve() returned. An application that resolves an untrusted reference with fast-uri and then checks or routes on the resulting host can make a policy decision on one host and reach another. This is an incomplete-fix variant of CVE-2026-13676, whose IDN canonicalization was applied only to the scheme-bearing form. Patches Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. resolve() now canonicalizes the host once the effective scheme is known, and fails closed if a raw non-ASCII host cannot be converted. Workarounds Resolve scheme-relative references against a base that carries a scheme before performing any host-policy or origin check.

    Recommended action: Upgrade to 4.1.3, 3.1.6 or 2.4.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  10. High, CVSS 7.5npmPublished

    fast-uri vulnerable to server-side request forgery via malformed IPv6 normalization

    CVE-2026-75975 · GHSA-f65p-4m7j-42xc

    Affected
    • npm fast-uri >= 2.3.1, < 2.4.5; >= 3.0.0, < 3.1.6; >= 4.0.0, < 4.1.3
    Fixed in
    2.4.54.1.33.1.6· Vendor fix available
    Issue
    Impact fast-uri does not validate the complete RFC 3986 grammar for bracketed IPv6 literals, so a malformed literal with invalid trailing text is silently truncated to a different valid IPv6 address with no error reported. For example, normalize('http://[::not-valid]/private') returns http://[::]/private, and [fc00::not-hex] and [fe80::not-hex] collapse to [fc00::] and [fe80::]. An application that normalizes an untrusted URL before an outbound request, redirect, or host-policy check can be routed to a local or private address such as loopback (::1), unique-local, or link-local. Because parse().error is unset for these inputs, checking it does not protect the consumer. Patches Upgrade to fast-uri 2.4.5, 3.1.6, or 4.1.3. Malformed IPv6 literals are now rejected with a host error instead of being normalized to a valid address. Workarounds Reject untrusted URLs whose host is a bracketed IPv6 literal before passing them to fast-uri, or route outbound requests against an explicit…

    Recommended action: Upgrade to 4.1.3, 3.1.6 or 2.4.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  11. High, CVSS 7.5npmPublished

    fast-uri vulnerable to server-side request forgery via repeated hostname percent-decoding

    CVE-2026-75899 · GHSA-fph4-wmhf-6fwf

    Affected
    • npm fast-uri >= 2.4.1, < 2.4.5; >= 3.1.2, < 3.1.6; >= 4.0.0, < 4.1.3
    Fixed in
    2.4.54.1.33.1.6· Vendor fix available
    Issue
    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().

    Recommended action: Upgrade to 4.1.3, 3.1.6 or 2.4.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  12. High, CVSS 7.5npmPublished

    fast-uri vulnerable to host confusion via percent-encoded scheme normalization

    CVE-2026-76172 · GHSA-jqff-g426-hqxp

    Affected
    • npm fast-uri >= 2.3.1, < 2.4.5; >= 3.0.0, < 3.1.6; >= 4.0.0, < 4.1.3
    Fixed in
    2.4.54.1.33.1.6· Vendor fix available
    Issue
    Impact fast-uri decodes percent-encoded characters in the scheme component with the legacy global unescape() and serializes the result back as raw characters, without re-escaping it or validating it as a scheme. A scheme that decodes to characters outside the RFC 3986 scheme grammar can therefore introduce structure the original input did not contain. For example, %2f%2fevil.example:/pwn parses with no authority (parse().host is undefined), but resolve() and normalize() return //evil.example:/pwn, which reparses with host evil.example. The %uXXXX form (%u002f%u002fevil.example:/pwn) produces the same result, and a scheme containing %0d%0a reaches the output as a raw CR LF. Applications that normalize or resolve untrusted URLs before a redirect check, host allowlist, or outbound request decision, especially ones that treat a missing authority as same-origin, can be steered to an attacker-chosen authority, and a normalized URI placed in a response header can carry an injected CR LF.…

    Recommended action: Upgrade to 4.1.3, 3.1.6 or 2.4.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  13. High, CVSS 7.5npmPublished

    fast-uri vulnerable to host confusion via backslash authority introducer

    CVE-2026-18446 · GHSA-7p8r-x3mc-p8w7

    Affected
    • npm fast-uri < 2.4.4; >= 3.0.0, < 3.1.5; >= 4.0.0, < 4.1.2
    Fixed in
    3.1.54.1.22.4.4· Vendor fix available
    Issue
    Impact fast-uri v4.1.1 and earlier require a literal // to recognize a URI authority, so a reference that uses \\, /\, or \/ as the authority introducer (in place of //, after an optional scheme) is parsed with no authority: the sequence and everything after it fold into the path. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) instead treats \ as interchangeable with / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input. For example, fast-uri resolves \\evil.com/path against base https://allowed.com/ to https://allowed.com/%5C%5Cevil.com/path (confined to the trusted host), while Node's WHATWG URL resolves the same reference to https://evil.com/path. Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use…

    Recommended action: Upgrade to 4.1.2, 3.1.5 or 2.4.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:github.comSource checked Evidence →
  14. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to host confusion via literal backslash authority delimiter

    CVE-2026-16221 · GHSA-v2hh-gcrm-f6hx

    Affected
    • npm fast-uri >= 2.3.1, <= 2.4.2; >= 3.0.0, <= 3.1.3; >= 4.0.0, <= 4.1.0
    Fixed in
    2.4.34.1.13.1.4· Vendor fix available
    Issue
    Impact fast-uri v4.1.0 and earlier do not treat a literal backslash (U+005C) as an authority delimiter. Node's native WHATWG URL (used by fetch(), undici, and Node's http/https clients) normalizes \ to / for special schemes (http, https, ws, wss, ftp, file), so the two parsers extract different hosts from the same input string. For example, http://evil.com\@allowed.com is treated by fast-uri as host allowed.com with userinfo evil.com\, while Node's WHATWG URL parser and fetch() see host evil.com with path /@allowed.com. Applications that use fast-uri to enforce host-based policy (allowlists, denylists, loopback/SSRF filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination, including cloud metadata endpoints, loopback, or internal hosts. Patches Upgrade to fast-uri v4.1.1, v3.1.4, or v2.4.3. Workarounds None. Upgrade to the patched version.

    Recommended action: Upgrade to 4.1.1, 3.1.4 or 2.4.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  15. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to host confusion via failed IDN canonicalization

    CVE-2026-13676 · GHSA-4c8g-83qw-93j6

    Affected
    • npm fast-uri >= 4.0.0, < 4.0.1; >= 3.0.0, < 3.1.3; >= 2.3.1, < 2.4.2
    Fixed in
    2.4.23.1.34.0.1· Vendor fix available
    Issue
    Impact fast-uri versions = 2.3.1, <= 4.0.0 fail to canonicalize Unicode/IDN hostnames for HTTP-family URLs. The IDN conversion path calls URL.domainToASCII(...) on the global WHATWG URL constructor, where that helper does not exist. The resulting TypeError is silently routed into parsed.error, but parse(), normalize(), and equal() all return with the host left in its original Unicode form. For example, http://127。0。0。1/ is treated by fast-uri as host 127。0。0。1, while Node's WHATWG URL parser and fetch() canonicalize the same input to 127.0.0.1. Applications that use fast-uri to enforce host-based policy (denylists, loopback filtering, redirect validation, outbound proxy routing) before passing the same URL into Node's URL or fetch() consumers see a policy/use desync and can be steered to an unintended destination. Patches Upgrade to fast-uri v4.0.1, v3.1.3, or v2.4.2 Workarounds None. Upgrade to the patched version.

    Recommended action: Upgrade to 4.0.1, 3.1.3 or 2.4.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  16. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to host confusion via percent-encoded authority delimiters

    CVE-2026-6322 · GHSA-v39h-62p7-jpjc

    Affected
    • npm fast-uri >= 3.0.0, <= 3.1.1; <= 2.4.0
    Fixed in
    2.4.13.1.2· Vendor fix available
    Issue
    Impact fast-uri v3.1.1 and earlier decodes percent-encoded authority delimiters (%40 as @, %3A as :) inside the host component and serializes them back as raw characters. This changes the URI structure, turning a hostname into userinfo plus a different host. For example, http://trusted.com%40evil.com/ normalizes to http://trusted.com@evil.com/, which reparses as host evil.com with userinfo trusted.com. Applications that normalize untrusted URLs before host allowlist checks, redirect validation, or outbound request routing can be steered to a different authority than the original URL appeared to contain. Patches Upgrade to fast-uri = 3.1.2, or if you are in the v2.x release line, v2.4.1 Workarounds None. Upgrade to the patched version.

    Recommended action: Upgrade to 3.1.2 or 2.4.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →
  17. High, CVSS 7.5npmAmendedPublished

    fast-uri vulnerable to path traversal via percent-encoded dot segments

    CVE-2026-6321 · GHSA-q3j6-qgpj-74h6

    Affected
    • npm fast-uri >= 3.0.0, <= 3.1.0; <= 2.4.0
    Fixed in
    2.4.13.1.1· Vendor fix available
    Issue
    Impact fast-uri v3.1.0 and earlier decodes percent-encoded path separators (%2F) and dot segments (%2E) before applying dot-segment removal in normalize() and equal(). This makes encoded path data behave like real / and .., so distinct URIs collapse onto the same normalized path. For example, http://example.com/public/%2e%2e/admin normalizes to http://example.com/admin, and equal() considers them the same URI. Applications that normalize or compare attacker-controlled URLs to enforce path-based policy can be bypassed. A path that looks confined under an allowed prefix can normalize to a different location. Patches Upgrade to fast-uri = 3.1.1, or if you are in the v2.x release line, v2.4.1 Workarounds None. Upgrade to the patched version.

    Recommended action: Upgrade to 3.1.1 or 2.4.1 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.

    Sources:osv.dev (1)github.com (2)Source checked Evidence →