chore(deps): clear 21 Dependabot alerts in the MCP bridge lockfile - #28
Merged
Conversation
npm audit reported 8 advisory groups (5 high, 2 moderate, 1 low) against mcps/fluttersdk-mcp: hono ReDoS in the CORS middleware, three ip-address SSRF and trust-boundary bypasses, fast-uri, body-parser, and on the dev side postcss path traversal in source-map auto-loading plus a vite server.fs.deny bypass. All of them resolved inside the existing semver ranges, so package.json is untouched and this is a lockfile-only change. The runtime half arrives transitively through @modelcontextprotocol/sdk (hono, @hono/node-server, body-parser) and the dev half through vitest (vite, postcss). npm audit now reports 0 vulnerabilities. tsc builds and the bridge tests pass unchanged.
This was referenced Aug 3, 2026
anilcancakir
added a commit
that referenced
this pull request
Aug 3, 2026
#29) typescript 6.0.3 to 7.0.2, @types/node 25.9.1 to 26.1.1, vitest 4.1.7 to 4.1.10. All devDependencies; the published package's runtime deps and ranges are untouched. Each was an open Dependabot PR cut against the lockfile #28 replaced, so they are verified once here instead of three rebase cycles. tsc 7 compiles with no source change, vitest 4.1.10 runs the bridge tests green, npm audit stays at 0.
Comment on lines
27
to
34
| "node_modules/@hono/node-server": { | ||
| "version": "1.19.14", | ||
| "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-1.19.14.tgz", | ||
| "integrity": "sha512-GwtvgtXxnWsucXvbQXkRgqksiH2Qed37H9xHZocE5sA3N8O8O8/8FA3uclQXxXVzc9XBZuEOMK7+r02FmSpHtw==", | ||
| "version": "2.0.12", | ||
| "resolved": "https://registry.npmjs.org/@hono/node-server/-/node-server-2.0.12.tgz", | ||
| "integrity": "sha512-eWpQYr67tqJLeaSUl0Q+TquuYfUdTibpOJlUMV2FfUP7+KqCC5TufnwnlXL6mobZBJbGAYRd7ZvEBDCbLInjhg==", | ||
| "license": "MIT", | ||
| "engines": { | ||
| "node": ">=18.14.1" | ||
| "node": ">=20" | ||
| }, |
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.
What
Lockfile-only update of
mcps/fluttersdk-mcp.package.jsonis untouched: every fix landed inside the existing semver ranges.honoAccess-Control-Request-Headers(high)@hono/node-serverip-addressfast-uribody-parserpostcss.mapdisclosure (high, dev)viteserver.fs.denybypass on Windows alternate paths, plus the launch-editor NTLMv2 disclosure (high, dev)@modelcontextprotocol/sdkTree went from 171 to 165 packages.
Why
GitHub reported 21 open alerts (7 high, 13 moderate, 1 low) on the default branch, all pointing at
mcps/fluttersdk-mcp/package-lock.json. The runtime half arrives transitively through@modelcontextprotocol/sdk(hono,@hono/node-server,body-parser) and the dev half throughvitest(vite,postcss), so nothing here is a direct dependency choice, only a stale lock.The
ip-addressgroup is the one worth naming: this package is a stdio-to-HTTP bridge, so SSRF-adjacent parsing bugs in the transitive tree are not purely theoretical for it.Testing
npm audit: 8 advisory groups before, 0 vulnerabilities after.npm run build(tsc): clean.npm test(vitest run): 2 tests, both pass, unchanged from before.package.jsonedit, so the published package's declared dependency ranges are identical.Noted, not fixed here
npm run lintrunseslint src/, buteslintis not indevDependencies, so the script fails from a clean clone. CI's MCP job runs build and test, not lint, which is why nobody has hit it. Worth either adding the dependency plus a config or dropping the script; both are a separate change from a security lockfile bump.