fix(deps): pin the nested resolutions two advisories were hiding in - #327
Merged
Conversation
`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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Refs #287 — this is the actionable part of the dependency dashboard. Independent of #322/#323/#324; branches off
main.What
bun auditwas actually reporting23 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:
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. Neitherbun update form-datanorbun install --forcechanges it; I tried both before reaching for an override.The same shape had
@modelcontextprotocol/sdkon 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-datainpackage.jsondid reach 4.0.6, and the copy axios uses never moved.Reachability
GHSA-hmw2-7cc7-3qxxis CRLF injection in form-data via unescaped multipart field names and filenames.snow_attach_fileposts multipart through axios with a caller-suppliedfile_name. Not theoretical.The fix, and its own failure mode
Two root overrides:
An override writes a version down a second time, and Renovate only knows about the first. A bump of
packages/servicenow-mcp/package.jsontherefore 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.tsfails on that, on a non-exact override, and on any"<parent>/<name>"entry reappearing in the lockfile. Setting the override back to4.0.5:Verification
bun audit: 23 → 0bun testinpackages/servicenow-mcp: 423 pass, 0 fail.packages/skills: 77 pass, 0 fail.tsc --project tsconfig.build.jsonbuilds,generate:tools-json:checkup to datebun install --frozen-lockfileclean, so the committed lockfile is the one CI will getThe SDK moving from hono 4.12.12 to 4.12.34 is inside its own
^4.11.4range; 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.