fix(deps): clear the minor/patch CVE backlog across 7 manifests

[github-actions]

Clears the minor/patch-fixable half of the #747 CVE triage backlog. Seven manifests, no major-version bumps, no test or gate weakening.

Part of the sequencing in #747: axios (#754, merged) → tar (#813) → these minors → react-router v7 + uuid 9→11 (deferred, own PRs).

What changes

Direct bumps

Manifest	Package	From → To
backend/security	undici	^7.28.0 → ^7.29.0
fuzefront-website/backend	morgan	^1.10.0 → ^1.11.0
fuzefront-website/frontend	react-router-dom	^6.28.0 → ^6.30.6

Overrides added (resolved version in parens)

Manifest	Override	Resolves to
root	ip-address >=10.2.2	10.5.0
fuzefront-website/backend	lodash >=4.17.23	4.18.1
	qs >=6.15.2	6.15.3
	validator >=13.15.22	13.15.35
	body-parser ">=1.20.6 <2"	1.20.6
sdk	ws >=8.20.1	8.21.3
	(transitive) socket.io-parser	4.2.7
services/billing-service	body-parser ">=1.20.6 <2" / brace-expansion >=5.0.9	1.20.6 / 5.0.9
services/email-service	same	same
services/sms-service	same	same

Authoritative post-change finding counts come from gate-dependency-scan's SARIF artifact on this PR — I could not re-measure locally (Trivy's DB host is blocked from this environment), so I'm not quoting numbers I can't stand behind.

Four things worth a reviewer's attention

1. The body-parser upper bound is load-bearing, not stylistic.

The obvious override is "body-parser": ">=1.20.6". I wrote that first, and npm resolved 2.3.0 — under express@4, which requires the 1.x API. The bound is ">=1.20.6 <2" for exactly that reason. Anyone widening it later re-breaks express@4. Nothing in CI would have caught it.

2. The lockfiles were rebuilt per-package, after a first attempt that floated the whole tree.

My first pass used npm update --package-lock-only with no package arguments, which re-resolves everything. On the root lockfile that meant 207 packages changed, 687 entries removed, 174 added — including esbuild downgraded 0.27.7 → 0.24.2 and typescript floated to 6.0.3, which broke gate-frontend-build (packages/chat-client DTS build, TS5101: Option 'baseUrl' is deprecated). All seven lockfiles had the same churn.

Redone as npm update <specific packages> --package-lock-only. The root lockfile is now +1 entry, −0, ~1 version-changed vs master. Every entry that changes anywhere in this PR traces to a targeted package or its direct transitive.

Worth knowing for next time: plain npm install --package-lock-only reports "up to date" and silently does not apply a newly-added overrides entry. Only the package-scoped npm update form does both jobs correctly.

3. fuzefront-website/backend/package-lock.json is a CRLF file.

npm on Linux rewrites it as LF, which turns a 9-entry change into a 7,124-line whitespace diff — the "reordered file makes an eyeballed diff unreliable" trap CLAUDE.md warns about. Endings are preserved in this PR so the diff shows only the real changes. .gitattributes already forces LF for CSS, Helm values, and the vendored contract after this same problem bit three times; adding lockfiles to it is the right follow-up but belongs in its own PR, not a deps change.

4. A duplicate engines key was dropped from four manifests — disclosed, not intended.

sdk, services/billing-service, services/email-service, and services/sms-service each declared "engines" twice (issue #755). The JSON round-trip that added overrides collapsed the duplicate. Both copies were byte-identical (node >=24.0.0, npm >=10.0.0) and the first is retained, so the Node 24 floor is unchanged — verified on all four. It's strictly correct and re-adding a duplicate key would not be, so I kept it rather than reverting; flagging it because it wasn't part of the stated scope.

Correcting my own triage in #747 on react-router

I previously wrote that all four react-router findings clear on 6.30.6. That was wrong. It came from taking max() over Trivy's FixedVersion list, which enumerates fixes across multiple release branches — so a 6.x backport and a 7.x fix appear side by side and max() reads as "you must go to 7".

Actual state: 6.30.6 clears 2 of the 4; CVE-2026-53666 and CVE-2026-53669 list 7.18.0 only, with no 6.x backport. So 2 genuinely require v7 and remain deferred to their own PR — which needs a real-Chromium check under the ui-runtime-validation mandate, since FuzeFront is the Module-Federation host.

Not in scope

• react-router v7, uuid 9→11, tar-fs 2→3 — deferred majors, own PRs per Triage: 54 LOW/MEDIUM dependency findings restored to code scanning by full-severity Trivy #747.
• Root body-parser@1.20.2 still present in workspace-nested services/*/node_modules paths: npm overrides do not reach those copies, and npm ci installs exactly what the lockfile says. Tracked in Triage: 54 LOW/MEDIUM dependency findings restored to code scanning by full-severity Trivy #747.
• check-dockerfile-lockfile is red on master already (pre-existing — services/selection-list-service / packages/auth / jose, FFRNT-254). Not caused by and not fixed by this PR.

[izzywdev]

Both failing checks are pre-existing on master and not caused by this PR. Fixes are open for each.

Dockerfiles install from the lockfile — the FFRNT-254 violation in services/selection-list-service/Dockerfile, a file this PR does not touch. Fixed by #817 (verified: that gate reports success on #817's head).

Trivy — reports "1 configuration present on refs/heads/master was not found: .github/workflows/ci.yml:security-scan", then lists pre-existing findings as new because there is no baseline to diff against. Fixed by #818 (verified: Trivy reports success on #818's head, and does so while Container Security Scan is still running — which is the decoupling that fix is for).

Not porting either fix here — both are green on their own gates with auto-merge armed, and porting would put four concurrently-open PRs on the same Dockerfile and workflow files. Once they land I'll update this branch onto the fixed base.

---

Separately, and more relevant to reviewing this PR: the lockfiles were rebuilt since the description was first written. The original pass used npm update --package-lock-only with no package arguments, which re-resolves the entire tree rather than the targeted packages. On the root lockfile that meant 207 packages changed, 687 entries removed, 174 added — including esbuild downgraded 0.27.7 → 0.24.2 and typescript floated to 6.0.3, which is what broke gate-frontend-build (TS5101 in the chat-client DTS build). All seven lockfiles had the same churn.

Redone with the package-scoped form (npm update <pkgs> --package-lock-only). The root lockfile is now +1 entry, −0, ~1 version-changed against master, and every changed entry anywhere in this PR traces to a targeted package or its direct transitive. gate-frontend-build passes.

Worth knowing for the next dependency PR: plain npm install --package-lock-only reports "up to date" and silently does not apply a newly-added overrides entry. Only the package-scoped npm update form does both jobs.

---

Generated by Claude Code

[izzywdev]

The Trivy failure on this PR was real, not the phantom-baseline one — and it's now fixed in 904911a7.

Worth noting the difference from the earlier failures, because it shows the gate started working:

	earlier runs	this run
Title	1 configuration not found	1 new alert including 1 high severity security vulnerability
Baseline warning	present	gone
Verdict	phantom — pre-existing findings with no baseline to diff against	a genuine new finding

With #818 on master the baseline is complete, so the check could finally do a real diff. What it found:

fuzefront-website/backend/package-lock.json:6541
tar-fs 2.1.3 — tar-fs symlink validation bypass — CVE-2025-59343  (HIGH)

It surfaces as "new" because regenerating this lockfile put the line into the diff. The exposure is real either way, so it's fixed rather than annotated.

Correcting my own #747 triage again

I listed tar-fs there as a deferred 2 → 3 major. That was wrong — the fix is backported to the 2.x line and 2.1.5 exists. Same mistake as the react-router one I corrected earlier in this PR: taking max() over Trivy's FixedVersion, which enumerates fixes across multiple release branches, so a 3.x entry sitting beside a 2.x one reads as "you must go to 3".

Fix is "tar-fs": ">=2.1.5 <3" — bounded for the same reason as body-parser in this PR, since prebuild-install requires tar-fs ^2.0.0 and an unbounded floor would cross the major.

Scoped by measurement

Every lockfile in the repo was checked rather than assuming this was the only one:

package-lock.json                             2.1.5   (already fixed)
fuzefront-website/backend/package-lock.json   2.1.3 → 2.1.5

The root already resolving 2.1.5 independently confirms it's valid for this dependency shape. Diff is three lines, tar-fs only.

---

Separately: the remaining Trivy red on #816 is still the baseline/race issue, which #818 did not fully fix. Measured on #816 afterwards the check ran 04:27:07 → 04:27:09 — two seconds — and still reported a missing configuration. Two configurations under one SARIF tool race regardless of how far apart they finish. #820 fixes that properly with one configuration per tool.

---

Generated by Claude Code