chore(deps): clear npm audit advisories in website + whatsapp-bridge lockfiles

[EvilHumphrey]

Refreshes two standalone lockfiles to clear all current npm audit advisories on those surfaces. Lockfile-only — no package.json changes, no major bumps.

website/ — 9 → 0 (3 high, 6 moderate)

• undici 7.23.0 → 7.27.1 (6 advisories incl. request smuggling, CRLF injection, memory DoS)
• path-to-regexp 0.1.12 → 0.1.13 (ReDoS), picomatch 2.3.1 → 2.3.2
• qs, ws, brace-expansion, postcss, nanoid, body-parser, express → latest patch

scripts/whatsapp-bridge/ — 4 → 0 (moderate)

• protobufjs 7.5.6 → 7.6.2, qs 6.14.2 → 6.15.2, ws 8.20.0 → 8.21.0, express 4.22.1 → 4.22.2

Verified npm audit --package-lock-only → 0 on both. These locks are standalone (not Nix-built), so no nix/lib.nix change is required. Supersedes the website/bridge portion of #39304 (which bundled these with the Nix-coupled root lock and became conflicted); the remaining root react-router advisory is Nix-coupled and tracked separately.

[EvilHumphrey]

The failing osv-scan check here isn't caused by this PR's lockfile changes.

The scan also covers uv.lock, and the only Critical it flags is aiohttp GHSA-63hf-3vf5-4wqf (9.1), present because uv.lock still pins aiohttp 3.13.3. This PR only touches npm lockfiles, so it can't clear it.

That Critical is fixed by #39467 (bumps aiohttp → 3.14.0), whose own osv-scan is green (0 Critical).

Suggested order:

1. Merge chore(deps): bump aiohttp to clear security advisories #39467 first.
2. Rebase this PR onto the updated main — the osv-scan red then clears. The remaining High/Medium uv.lock advisories are report-only; the gate fails on Critical, as chore(deps): bump aiohttp to clear security advisories #39467's green run demonstrates.

The npm audit changes in this PR are unrelated to the uv.lock Critical.

[austinpickett]

Good, well-scoped security work — but it needs a refresh before merge, and there's a coordination point with the Baileys PRs. Verdict: Comment (not blocking on quality, but it no longer achieves "0 advisories" and is stale).

Verified the bumps are real and correctly scoped

Confirmed in the diff: undici 7.23.0→7.27.1, protobufjs 7.5.6→7.6.2, qs→6.15.2, ws→8.21.0, path-to-regexp 0.1.12→0.1.13 — all patch/minor security bumps. Both files are standalone lockfiles (website/, scripts/whatsapp-bridge/), disjoint from the root package-lock.json, so no conflict with the root-lockfile PRs (#44024 / #44197). 👍

But npm audit is no longer 0 on either surface

I checked out the branch and ran npm audit against both:

website — 1 critical remains: shell-quote (GHSA-w7jw-789q-3m8p, quote() newline-escape). This PR doesn't touch shell-quote — it's an advisory that appears to have published after you authored this. It's npm audit fix-able. The 9 you targeted are cleared; this is new.

whatsapp-bridge — 1 critical remains: baileys (GHSA-qvv5-jq5g-4cgg, message-upsert/histsync spoofing, affects 7.0.0-rc.1 - rc11). This is out of scope for your moderate transitive bumps and is handled by #43840 (the canonical Baileys rc13 pin, already approved). The 4 moderates you targeted are cleared.

Coordination

Your scripts/whatsapp-bridge/package-lock.json edit overlaps with #43840's lockfile change. They're complementary (you do the moderate transitive bumps, #43840 does the Baileys commit pin), but they can't both merge clean — whoever lands second needs a rebase. Suggest sequencing after #43840.

Ask

Please rebase onto current main and regenerate both lockfiles (it's CONFLICTING/DIRTY now) so the diff reflects current advisories — ideally folding in the shell-quote fix so website is genuinely 0, and rebasing the whatsapp-bridge side on top of #43840. The approach is right; it just needs to be current.

[EvilHumphrey]

Thanks for the thorough re-review! I agree on all points and good catch on the new advisory
Refresh plan:

Rebase onto current main and regenerate both lockfiles so the diff reflects today's advisory set.
website: fold in the shell-quote fix (GHSA-w7jw-789q-3m8p) via npm audit fix so npm audit is genuinely 0 there again. Confirmed it published after this PR was authored — separate from the 9 already cleared.
whatsapp-bridge: agreed it sequences after #43840. I'll rebase this side on top of the rc13 pin once it lands, so the moderate transitive bumps stack cleanly on the Baileys commit pin instead of conflicting with it. Baileys' own GHSA-qvv5-jq5g-4cgg is #43840's to close, not this PR's.
To avoid a double force-push I'll hold the refresh until #43840 merges and land it as one clean pass — unless you'd prefer I push the website side now and do whatsapp-bridge as a follow-up. Happy either way.

(The red osv-scan here is the separate aiohttp-in-uv.lock critical tracked in #42334, not these lockfiles — it'll clear when that lands.)

[EvilHumphrey]

Closing this out — re-checked against current main (9688c1a9), and both halves are already covered upstream:

website: main picked up the website npm audit fix in 4cecb1a1 (2026-06-10), which includes the shell-quote bump to 1.8.4 (GHSA-w7jw-789q-3m8p) you flagged, and is actually ahead of this branch elsewhere (e.g. undici 7.27.2 vs 7.27.1 here). The only advisory left on main's website/package-lock.json today is joi GHSA-q7cg-457f-vx79 (published 2026-06-11, after your review) — a one-line transitive bump to 17.13.4. Sending that as its own minimal PR rather than reviving this stale branch.

whatsapp-bridge: ceding this lockfile to #43840 (Baileys rc13 → clears the GHSA-qvv5 critical) + #44358 (same transitive bumps as here, protobufjs slightly newer at 7.6.3), which together take it to 0 — rather than force-pushing a duplicate. (#44980 looks like another copy of #44358, FYI.)

For the record, the red osv-scan here was a SARIF-upload rate-limit hiccup, not a lockfile finding — the scanner step passed and the job is fail-on-vuln: false. Thanks for the thorough review; the nine advisories this originally targeted are all cleared on main now, just via fresher vehicles.