fix(deps): clear all 358 open Dependabot alerts - #20
Conversation
The GHSA advisories page was clean after #18/#19, but the Dependabot alerts tab still had 358 open alerts (5 critical, 182 high, 153 medium, 18 low) across the root project and every module manifest. Root (66 alerts) `pnpm update` within existing ranges: hono 4.7.9 -> 4.13.2 (39 alerts on its own), @hono/node-server 1.14.1 -> 1.19.17, form-data 4.0.2 -> 4.0.6, plus refreshed transitives. pnpm audit is now clean. Modules (~290 alerts) Every module lockfile was stale. mocha 10 pins serialize-javascript ^6, which is vulnerable; the root project already carried a `serialize-javascript: ^7.0.0` pnpm override but no module did, so each module got the same override and a regenerated lockfile. Direct bumps where the range could not reach a fixed version: - backlinks: nodemailer ^6 -> ^9.0.5, uuid ^9 -> ^14.0.1, puppeteer ^21 -> ^25.7.0 (both call sites are version-stable) - lighthouse: lighthouse ^11 -> ^13.4.1. lighthouse 11/12 pull @puppeteer/browsers 2.x -> extract-zip, and extract-zip has no patched release, so the only fix is leaving the tree. Raises this module's floor to Node 22.19; Node 18 and 20 are both past end-of-life. - linkchecker: uuid override ^11.1.1 rather than linkinator 7/8, which would have narrowed the module to Node >=20/22. - wcag: dropped the `child_process` dependency — the module imports the Node builtin, while the npm package of that name is an npm security-holder placeholder with no code. Marked the pa11y peer optional and disabled auto-install-peers: pa11y is installed out-of-band by bin/install.sh, and auto-installing it dragged its whole puppeteer tree in. Lockfile hygiene Removed five stale package-lock.json files. This is a pnpm repo (packageManager: pnpm@10.6.5); backlinks, linkchecker and news-aggregator carried both lockfiles, and lighthouse and wcag were npm-only. Those five npm lockfiles alone accounted for 157 alerts. lighthouse and wcag now have pnpm lockfiles like the other twelve. logger.js is a formatting-only change from the prettier bump (3.1 -> 3.9). Verified: root and all 14 module lockfiles report "No known vulnerabilities"; 90 core tests and 196 module tests pass. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ThreatCrush Security Scan19 finding(s) HIGH/CRITICAL: 13 | MEDIUM: 6
Snippets are redacted; ThreatCrush never prints matched credential material. |
|
Review the following changes in direct dependencies. Learn more about Socket for GitHub.
|
|
Warning Review the following alerts detected in dependencies. According to your organization's Security Policy, it is recommended to resolve "Warn" alerts. Learn more about Socket for GitHub.
|
Ships the dependency fixes from #20. The published 1.5.0 still declares the old ranges (hono ^4.7.9, @hono/node-server ^1.14.1, form-data ^4.0.0), so anyone installing it can still resolve vulnerable versions. This republishes with the patched floors. No API or behaviour change. Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
1 participant
The GHSA advisories page was fully closed out by #18 and #19, but the Dependabot alerts tab still had 358 open alerts — 5 critical, 182 high, 153 medium, 18 low — across the root project and nearly every module manifest. This clears all of them.
Root (66 alerts)
pnpm updatewithin the existing semver ranges was enough: hono4.7.9→4.13.2(39 alerts by itself),@hono/node-server1.14.1→1.19.17, form-data4.0.2→4.0.6, plus refreshed transitives.Modules (~290 alerts)
Every module lockfile was stale. The common cause: mocha 10 pins
serialize-javascript ^6, which is vulnerable. The root project already carried aserialize-javascript: ^7.0.0pnpm override but no module did — so each module now gets the same override plus a regenerated lockfile.Direct bumps where the range couldn't reach a fixed version:
^6→^9.0.5, uuid^9→^14.0.1, puppeteer^21→^25.7.0uuidv4 import, one nodemailer call) are stable across these majors^11→^13.4.1@puppeteer/browsers2.x →extract-zip, which has no patched release — the only fix is leaving the tree^11.1.1child_processdep; pa11y peer made optionalTwo findings worth calling out in wcag:
child_process, which is an npm security-holder placeholder with no code — npm is squatting the name to prevent malicious use. The module actually imports the Node builtin (import { spawn } from 'child_process'), so the dependency did nothing except stand ready to auto-install whoever npm eventually hands the name to. Removed.pa11yis installed out-of-band bybin/install.sh(the module shells out to the Pa11y CLI), but pnpm'sauto-install-peerswas dragging pa11y's entire puppeteer tree — and itsextract-zipandunderscoreadvisories — into the lockfile. Marked the peer optional and disabledauto-install-peersfor that module.Lockfile hygiene
Removed five stale
package-lock.jsonfiles. This is a pnpm repo (packageManager: pnpm@10.6.5); backlinks, linkchecker and news-aggregator carried both lockfiles, and lighthouse and wcag were npm-only. Those five npm lockfiles alone accounted for 157 of the 358 alerts. lighthouse and wcag now have pnpm lockfiles like the other twelve.Worth a follow-up decision (not changed here):
.gitignorealready listsmcp_modules/*/pnpm-lock.yamlandmcp_modules/*/package-lock.json, anddocs/node_modules_fix.mddocuments that intent — but 17 module lockfiles are tracked anyway because they predate the rule. I kept them tracked (now clean, and reproducible) rather than quietly changing repo policy.One thing I did not change
mcp_modules/backlinks/src/service.js:709callsnodemailer.createTransporter(...). The real API iscreateTransport— that line throws today and will keep throwing. It's unrelated to dependencies, so I left it rather than smuggle a behavior change into a deps PR. Worth its own fix.Node floor
lighthouse now requires Node ≥22.19 for that module only (root stays ≥18). Node 18 and 20 are both past end-of-life, and it was the only way off
extract-zip.Verification
pnpm auditreports No known vulnerabilitieslogger.jsis a formatting-only change from the prettier 3.1 → 3.9 bump)🤖 Generated with Claude Code