Came across something in pnpm-lock.yaml around line 1 that looked worth flagging.
This HIGH severity vulnerability results from double-decoding percent-encoded hostnames during URI normalization in fast-uri v3.1.5. An attacker can craft doubly encoded URIs to bypass host-policy checks or redirect validation, leading to Server-Side Request Forgery (SSRF) and unauthorized access to internal or loopback network destinations.
Something like this might fix it:
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@ -line_x,7 +line_x,7 @@ packages:
fast-uri:
- resolved: https://registry.npmjs.org/fast-uri/-/fast-uri-3.1.5.tgz
+ resolved: https://registry.npmjs.org/fast-uri/-/fast-uri-3.1.6.tgz
integrity: sha512-...
Recommended Action: Run `pnpm update fast-uri@3.1.6` to safely resolve the dependency, regenerate the lockfile with correct checksums, and verify no unexpected transitive changes occur before committing.For reference: rule CVE-2026-75899. Rated high.
I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.
Came across something in
pnpm-lock.yamlaround line 1 that looked worth flagging.This HIGH severity vulnerability results from double-decoding percent-encoded hostnames during URI normalization in fast-uri v3.1.5. An attacker can craft doubly encoded URIs to bypass host-policy checks or redirect validation, leading to Server-Side Request Forgery (SSRF) and unauthorized access to internal or loopback network destinations.
Something like this might fix it:
For reference: rule
CVE-2026-75899. Rated high.I do not maintain this project, so I may well be missing context — if this is intentional or already handled elsewhere, please just close it.
Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.