Possible fix(deps): 3 vulnerable dependencies in package-lock.json

[begininvoke]

This might be a false positive, but frontend/src/angular/package-lock.json around line 656 looked worth a second pair of eyes.

RISK: HIGH — Dependency vulnerability in @angular/common 22.0.1 (frontend/src/angular/package-lock.json, lines 656-671). CVE-2026-68945: Angular's HttpTransferCache (used with server-side rendering via provideClientHydration()/transferCache) constructs transfer-cache keys by comma-joining repeated query parameters. This makes semantically distinct requests such as /api/items?tag=a&tag=b and /api/items?tag=a,b collide on the same cache key, so the SSR transfer cache can replay the WRONG backend response to the client. Impact: incorrect or cross-request data can be rendered/hydrated into user pages — a cache-key collision / response mix-up that breaks data integrity and can expose another request's response content. There is no direct RCE or auth bypass, but any SSR endpoint that uses transfer caching with repeated/variadic query parameters is affected. Remediation: upgrade @angular/common to 22.0.2 (or 21.2.19 / 20.3.27 on the 21.x/20.x lines). Note all @angular/* framework packages must stay on the same version due to strict peer dependencies, so update the framework set together.

Something like this might fix it:

1) Bump the vulnerable package (and keep Angular peers in lockstep) in frontend/src/angular/package.json:

diff
--- a/frontend/src/angular/package.json
+++ b/frontend/src/angular/package.json
@@ "dependencies" @@
-    "@angular/common": "^22.0.1",
+    "@angular/common": "^22.0.2",
-    "@angular/core":   "^22.0.1",
+    "@angular/core":   "^22.0.2",

(If package.json already declares "^22.0.1" and only the lock file pins 22.0.1, `npm update @angular/common` is sufficient; alternatively run `ng update @angular/common@22.0.2`.)

2) Regenerate the lock file so lines 656-671 resolve the patched version:

bash
cd frontend/src/angular
npm install
npm ls @angular/common   # must report 22.0.2

diff
--- a/frontend/src/angular/package-lock.json
+++ b/frontend/src/angular/package-lock.json
@@
       "node_modules/@angular/common": {
-        "version": "22.0.1",
+        "version": "22.0.2",

3) Temporary mitigation ONLY if the upgrade must be deferred — exclude requests with repeated query parameters from transfer caching (app.config.ts):

ts
provideClientHydration(
  withHttpTransferCacheOptions({
    // filter: return true => request is NOT cached
    filter: (req) => {
      const params = new URL(req.urlWithParams, 'http://localhost').searchParams;
      return [...new Set(params.keys())].some((k) => params.getAll(k).length > 1);
    },
  })
)

The canonical and recommended fix is the upgrade to 22.0.2; the filter only sidesteps the cache-key collision.

For reference: rule CVE-2026-68945. 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.