You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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().
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 allowlist of addresses rather than trusting the normalized host.
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.
Patches
Upgrade to fast-uri >= 4.1.3, or >= 3.1.6 in the v3.x release line, or >= 2.4.5 in the v2.x release line.
Overview Pins fast-uri to v4.1.4 across the monorepo via pnpm overrides in package.json and pnpm-workspace.yaml, with the lockfile updated from 3.1.5 to 4.1.4.
This is a major-line security bump (v3 → v4) to address high-severity URI parsing issues (host confusion, SSRF via percent-decoding/IPv6 normalization, scheme normalization, and related advisories). fast-uri@4.1.4 is also added to minimumReleaseAgeExclude so Renovate can merge the security release without waiting on the 7-day minimum release age policy.
Reviewed by Cursor Bugbot for commit 692e26c. Bugbot is set up for automated code reviews on this repo. Configure here.
Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.
This PR includes no changesets
When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR contains the following updates:
^3.1.5→^4.1.4^3.1.2→^4.1.4Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
fast-uri vulnerable to host confusion via skipped IDN canonicalization on scheme-relative references
CVE-2026-75931 / GHSA-5jgf-p345-68v8
More information
Details
Impact
fast-uricanonicalizes a host to its ASCII form only when the input carries an explicit scheme. Whenresolve()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 oneresolve()returned. An application that resolves an untrusted reference withfast-uriand 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-uri2.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.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fast-uri vulnerable to server-side request forgery via repeated hostname percent-decoding
CVE-2026-75899 / GHSA-fph4-wmhf-6fwf
More information
Details
Impact
fast-uridecodes a hostname's percent escapes twice in a singlenormalize()orresolve()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, sonormalize('http://%256c%256f%2563%2561%256c%2568%256f%2573%2574/')returnshttp://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-uri2.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 tonormalize()orresolve().Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fast-uri vulnerable to server-side request forgery via malformed IPv6 normalization
CVE-2026-75975 / GHSA-f65p-4m7j-42xc
More information
Details
Impact
fast-uridoes 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')returnshttp://[::]/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. Becauseparse().erroris unset for these inputs, checking it does not protect the consumer.Patches
Upgrade to
fast-uri2.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 allowlist of addresses rather than trusting the normalized host.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
fast-uri vulnerable to host confusion via percent-encoded scheme normalization
CVE-2026-76172 / GHSA-jqff-g426-hqxp
More information
Details
Impact
fast-uridecodes percent-encoded characters in the scheme component with the legacy globalunescape()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:/pwnparses with no authority (parse().hostisundefined), butresolve()andnormalize()return//evil.example:/pwn, which reparses with hostevil.example. The%uXXXXform (%u002f%u002fevil.example:/pwn) produces the same result, and a scheme containing%0d%0areaches 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.
Patches
Upgrade to
fast-uri>= 4.1.3, or >= 3.1.6 in the v3.x release line, or >= 2.4.5 in the v2.x release line.Workarounds
None. Upgrade to the patched version.
Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:NReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
fastify/fast-uri (fast-uri)
v4.1.4Compare Source
This is a security release that fixes the following high-severity security advisories:
serialize()Users of the v4 release line should upgrade to v4.1.4.
Full Changelog: fastify/fast-uri@v4.1.3...v4.1.4
v4.1.3Compare Source
This release addresses the following high-severity security advisories:
Users of the v4 release line should upgrade to v4.1.3.
Full Changelog: fastify/fast-uri@v4.1.2...v4.1.3
v4.1.2Compare Source
Fix for GHSA-7p8r-x3mc-p8w7
What's Changed
Full Changelog: fastify/fast-uri@v4.1.1...v4.1.2
v4.1.1Compare Source
Fix for GHSA-v2hh-gcrm-f6hx
Full Changelog: fastify/fast-uri@v4.1.0...v4.1.1
v4.1.0Compare Source
v4.0.1Compare Source
What's Changed
New Contributors
Full Changelog: fastify/fast-uri@v4.0.0...v4.0.1
v4.0.0Compare Source
What's Changed
Full Changelog: fastify/fast-uri@v3.1.2...v4.0.0
v3.1.7Compare Source
v3.1.6Compare Source
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about these updates again.
This PR was generated by Mend Renovate. View the repository job log.
Note
Overview
Pins
fast-urito v4.1.4 across the monorepo via pnpm overrides inpackage.jsonandpnpm-workspace.yaml, with the lockfile updated from3.1.5to4.1.4.This is a major-line security bump (v3 → v4) to address high-severity URI parsing issues (host confusion, SSRF via percent-decoding/IPv6 normalization, scheme normalization, and related advisories).
fast-uri@4.1.4is also added tominimumReleaseAgeExcludeso Renovate can merge the security release without waiting on the 7-day minimum release age policy.Reviewed by Cursor Bugbot for commit 692e26c. Bugbot is set up for automated code reviews on this repo. Configure here.