This might be a false positive, but yarn.lock around line 4838 looked worth a second pair of eyes.
Vulnerability: fast-uri@3.1.0 resolved in yarn.lock (lines 4838-4843) is affected by CVE-2026-13676, rated HIGH severity. Versions 2.3.1-3.1.2 and 4.0.0 fail to canonicalize Unicode (IDN) hostnames for HTTP-family URLs: the IDN conversion path calls a helper that does not exist on the global URL constructor, silently leaving the host in its original Unicode form. Consequently, fast-uri's normalize() and equal() can return values that differ from Node's WHATWG-compliant URL parser for the same input string. Impact: Applications that use fast-uri to enforce host-based security policy — denylists, SSRF/loopback filtering, redirect validation, outbound proxy routing — before passing the same URL to Node's URL or fetch are vulnerable to parser-differential bypass. An attacker can craft an IDN/Unicode hostname that fast-uri classifies as an allowed host while Node/fetch resolves it to a blocked or internal host, enabling SSRF or security-policy evasion. Risk level: HIGH. Remediation: Upgrade fast-uri to >= 3.1.3 (3.x line) or 4.0.1 (4.x line). As defense-in-depth, enforce host policy using the same URL parser that performs the actual request, or reject non-ASCII hosts before policy checks.
Something like this might fix it:
Upgrade fast-uri to the patched release and regenerate yarn.lock (do not hand-edit integrity hashes):
--- a/package.json
+++ b/package.json
@@
"dependencies": {
- "fast-uri": "^3.1.0"
+ "fast-uri": "^3.1.3"
},
+ "resolutions": {
+ "**/fast-uri": "^3.1.3"
+ }
# If fast-uri is only a transitive dependency, the resolutions block alone is sufficient.
# Regenerate the lockfile:
$ yarn install
# (or: $ yarn upgrade fast-uri@^3.1.3)
--- a/yarn.lock
+++ b/yarn.lock
@@ fast-uri@^3.0.1, fast-uri@^3.0.3, fast-uri@^3.1.0:
- version "3.1.0"
- resolved "https://registry.yarnpkg.com/fast-uri/-/fast-uri-3.1.0.tgz#..."
- integrity sha512-<old-integrity>
+ version "3.1.3"
+ resolved "https://registry.yarnpkg.com/fast-uri/-/fast-uri-3.1.3.tgz#..."
+ integrity sha512-<regenerated-by-yarn-install>
Defense-in-depth code fix — enforce host policy with the same parser used for the actual request and reject IDN hosts:
--- a/src/urlPolicy.js
+++ b/src/urlPolicy.js
@@
-function isAllowed(urlString) {
- const parsed = fastUri.parse(urlString);
- return !DENYLIST.has(parsed.host);
-}
+function isAllowed(urlString) {
+ // Parse with the SAME parser that will perform the request (Node WHATWG URL)
+ const parsed = new URL(urlString);
+ // Reject non-ASCII (IDN) hosts, which fast-uri < 3.1.3 failed to canonicalize
+ if (/[^\u0000-\u007F]/.test(parsed.hostname)) {
+ return false;
+ }
+ return !DENYLIST.has(parsed.hostname);
+}
After patching, verify no vulnerable version remains: yarn why fast-uri && yarn list --pattern fast-uriFor reference: rule CVE-2026-13676. Rated high.
The suggested change is untested against this project, so please read it before applying it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
This might be a false positive, but
yarn.lockaround line 4838 looked worth a second pair of eyes.Vulnerability: fast-uri@3.1.0 resolved in yarn.lock (lines 4838-4843) is affected by CVE-2026-13676, rated HIGH severity. Versions 2.3.1-3.1.2 and 4.0.0 fail to canonicalize Unicode (IDN) hostnames for HTTP-family URLs: the IDN conversion path calls a helper that does not exist on the global URL constructor, silently leaving the host in its original Unicode form. Consequently, fast-uri's normalize() and equal() can return values that differ from Node's WHATWG-compliant URL parser for the same input string. Impact: Applications that use fast-uri to enforce host-based security policy — denylists, SSRF/loopback filtering, redirect validation, outbound proxy routing — before passing the same URL to Node's URL or fetch are vulnerable to parser-differential bypass. An attacker can craft an IDN/Unicode hostname that fast-uri classifies as an allowed host while Node/fetch resolves it to a blocked or internal host, enabling SSRF or security-policy evasion. Risk level: HIGH. Remediation: Upgrade fast-uri to >= 3.1.3 (3.x line) or 4.0.1 (4.x line). As defense-in-depth, enforce host policy using the same URL parser that performs the actual request, or reject non-ASCII hosts before policy checks.
Something like this might fix it:
For reference: rule
CVE-2026-13676. Rated high.The suggested change is untested against this project, so please read it before applying it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.