Skip to content

fix(deps): pin the nested resolutions two advisories were hiding in - #327

Merged
groeimetai merged 2 commits into
mainfrom
work/issue-deps
Aug 20, 2026
Merged

fix(deps): pin the nested resolutions two advisories were hiding in#327
groeimetai merged 2 commits into
mainfrom
work/issue-deps

Conversation

@groeimetai

Copy link
Copy Markdown
Collaborator

Refs #287 — this is the actionable part of the dependency dashboard. Independent of #322/#323/#324; branches off main.

What bun audit was actually reporting

23 advisories, two of them high, against a tree whose direct dependencies were all patched. Both roots were a nested resolution the lockfile had pinned and never revisited:

"form-data":       ["form-data@4.0.6", ...]   <- what package.json asks for
"axios/form-data": ["form-data@4.0.5", ...]   <- what axios actually got

axios declares form-data: ^4.0.5, which 4.0.6 satisfies — nothing was wrong with the ranges. The lockfile simply kept the resolution it already had. Neither bun update form-data nor bun install --force changes it; I tried both before reaching for an override.

The same shape had @modelcontextprotocol/sdk on hono 4.12.12 (its range is ^4.11.4) while the workspace ran 4.12.34.

This is why closing #285 as "Renovate will recreate it" did not resolve anything: form-data in package.json did reach 4.0.6, and the copy axios uses never moved.

Reachability

GHSA-hmw2-7cc7-3qxx is CRLF injection in form-data via unescaped multipart field names and filenames. snow_attach_file posts multipart through axios with a caller-supplied file_name. Not theoretical.

The fix, and its own failure mode

Two root overrides:

"overrides": { "form-data": "4.0.6", "hono": "4.12.34" }
$ bun audit
No vulnerabilities found

An override writes a version down a second time, and Renovate only knows about the first. A bump of packages/servicenow-mcp/package.json therefore turns the override into a silent downgrade of the whole tree — including the direct dependency that was fine.

packages/servicenow-mcp/src/__tests__/dependency-overrides.test.ts fails on that, on a non-exact override, and on any "<parent>/<name>" entry reappearing in the lockfile. Setting the override back to 4.0.5:

(fail) root overrides > each one matches what the package declares
 2 pass, 1 fail

Verification

  • bun audit: 23 → 0
  • bun test in packages/servicenow-mcp: 423 pass, 0 fail. packages/skills: 77 pass, 0 fail.
  • typecheck clean, tsc --project tsconfig.build.json builds, generate:tools-json:check up to date
  • bun install --frozen-lockfile clean, so the committed lockfile is the one CI will get

The SDK moving from hono 4.12.12 to 4.12.34 is inside its own ^4.11.4 range; the transport-parity suite passes on it.

Not touched: the pending-approval queue on #287 (Actions v6→v7, TypeScript 7, Jest 30). Those are major bumps and a maintainer decision, not a security one.

`bun audit` reported 23 advisories, two of them high, against a tree
whose direct dependencies were all patched. Both came from a nested
resolution the lockfile had pinned and never revisited:

  "form-data":       ["form-data@4.0.6", ...]   what package.json asks for
  "axios/form-data": ["form-data@4.0.5", ...]   what axios actually got

axios declares `form-data: ^4.0.5`, which 4.0.6 satisfies, so nothing
was wrong with the ranges — the lockfile kept the resolution it already
had. Neither `bun update form-data` nor `bun install --force` touches
it. The same thing had @modelcontextprotocol/sdk on hono 4.12.12 (its
range is ^4.11.4) while the workspace ran 4.12.34.

The form-data one is reachable: GHSA-hmw2-7cc7-3qxx is CRLF injection
via unescaped multipart field names and filenames, and
snow_attach_file posts multipart through axios with a caller-supplied
file_name.

Two root overrides collapse both. 23 -> 0.

They introduce a second place a version is written down, and Renovate
only knows about the first — so a bump of packages/servicenow-mcp
turns the override into a silent DOWNGRADE of the whole tree, direct
dependency included. dependency-overrides.test.ts fails on that, on a
non-exact override, and on any nested "<parent>/<name>" entry
reappearing in the lockfile. Setting the override back to 4.0.5 turns
it red.

Refs #287
publish-mcp.yml copies packages/servicenow-mcp somewhere with no parent
manifest and runs the suite there, deliberately. Reading the repo-root
package.json unconditionally threw at import time and failed that job
while every other check passed. It now skips when there is nothing above
the package, the way sn-roles.test.ts and skills.test.ts already do.

Reproduced the gate locally before and after: 420 pass, 0 fail.
@groeimetai
groeimetai merged commit 086c967 into main Aug 20, 2026
5 checks passed
@groeimetai
groeimetai deleted the work/issue-deps branch August 20, 2026 19:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant