Possible fix(deps): 29 vulnerable dependencies in pnpm-lock.yaml

[begininvoke]

Came across something in pnpm-lock.yaml around line 1 that looked worth flagging.

Vulnerability: fast-uri 3.1.2 (CVE-2026-13676, HIGH) fails 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, so the host silently remains in its raw Unicode form while normalize() and equal() return values that diverge from a WHATWG-compatible parser (Node's URL / fetch).

Impact: This creates a URL-parser differential. Applications that use fast-uri to enforce host-based policy — SSRF denylists, loopback/internal-host filtering, redirect validation, outbound proxy routing — and then perform the actual request with Node's URL or fetch can be bypassed: an attacker crafts a Unicode hostname that fast-uri evaluates to one host while fetch resolves it to another (e.g., an IDN-equivalent of localhost or an internal/allowlisted domain), defeating the pre-flight check.

Risk: HIGH — attacker-controllable SSRF and host-based access-control bypass wherever fast-uri and WHATWG URL/fetch process the same user-supplied URL.

Remediation: Upgrade fast-uri to 3.1.3 (3.x line; 2.4.2 for 2.x, 4.0.1 for 4.x). Interim workarounds: enforce host policy with the same URL parser used for the actual request, or reject non-ASCII hosts before policy checks.

Something like this might fix it:

fast-uri appears as a (likely transitive) resolution in pnpm-lock.yaml — do not hand-edit the lockfile. Fix it via a pnpm override in package.json and regenerate the lockfile:

```diff
--- a/package.json
+++ b/package.json
@@
   "name": "my-app",
+  "pnpm": {
+    "overrides": {
+      "fast-uri": "^3.1.3"
+    }
+  },
   "scripts": {
     "build": "..."
   }
```

Then apply and verify:

```bash
pnpm install            # regenerates pnpm-lock.yaml with fast-uri 3.1.3
pnpm audit              # confirm CVE-2026-13676 is resolved
pnpm why fast-uri       # see which parent pulls it in
```

Expected lockfile change after regeneration:

```diff
--- a/pnpm-lock.yaml
+++ b/pnpm-lock.yaml
@@
-  fast-uri@3.1.2:
-    resolution: {integrity: sha512-...}
+  fast-uri@3.1.3:
+    resolution: {integrity: sha512-...}
```

If fast-uri is a direct dependency instead, simply bump it:

```diff
--- a/package.json
+++ b/package.json
@@
-  "fast-uri": "^3.1.2"
+  "fast-uri": "^3.1.3"
```

Note: `^3.1.3` is the minimal patch on the current 3.x line. If you are prepared for a major-version upgrade, `^4.0.1` also fixes this CVE but may introduce breaking API changes — review the 4.x changelog and run your test suite after upgrading. Additionally, consider hardening host checks by validating policy with the same URL parser used for outbound requests (e.g., `new URL(input).hostname`) and rejecting non-ASCII hostnames as defense-in-depth.

For reference: rule CVE-2026-13676. Rated high.

I may be wrong about this one — closing it costs you nothing if so.

---

Found with automated scanning (RedGem) and reviewed before opening. If it is not useful, closing it is completely fine.