Summary
Every @modelcontextprotocol/sdk release since 1.25.0 pins "@hono/node-server": "^1.19.9". The advisory GHSA-frvp-7c67-39w9 (path traversal in serve-static) is fixed in @hono/node-server >= 2.0.5, which that caret cannot reach.
The result: npm audit flags the SDK for every downstream consumer, and because no version forward clears it, npm's suggested fix resolves backwards to 1.24.3 — the last release before @hono/node-server became a dependency.
Why the suggested fix is unusable
1.24.3 predates WebStandardStreamableHTTPServerTransport. Any consumer importing that transport (we do, from Next.js route handlers) fails at build time if they take npm's advice. So the practical options today are "ship with a permanent audit finding" or "break the build."
Request
Widen the range so the fixed line is reachable:
"@hono/node-server": "^1.19.9 || ^2"
2.x keeps the same export map (., ./conninfo, ./serve-static, ./utils/*), the same hono@^4 peer, and still exports getRequestListener — which appears to be the only symbol the SDK imports from it (in dist/esm/server/streamableHttp.js). The bump requires Node >= 20.
Impact note
For consumers who only use the Web-Standard transport, the vulnerable serve-static module is never imported, and the flaw itself is Windows-specific (%5C → \ path resolution). So this is largely an audit-noise problem rather than an exploitable one — but it is noise that every downstream project has to triage and document individually, and the obvious automated remediation actively breaks builds.
Happy to open a PR if the range widening is acceptable.
Summary
Every
@modelcontextprotocol/sdkrelease since 1.25.0 pins"@hono/node-server": "^1.19.9". The advisory GHSA-frvp-7c67-39w9 (path traversal inserve-static) is fixed in@hono/node-server>= 2.0.5, which that caret cannot reach.The result:
npm auditflags the SDK for every downstream consumer, and because no version forward clears it, npm's suggested fix resolves backwards to 1.24.3 — the last release before@hono/node-serverbecame a dependency.Why the suggested fix is unusable
1.24.3predatesWebStandardStreamableHTTPServerTransport. Any consumer importing that transport (we do, from Next.js route handlers) fails at build time if they take npm's advice. So the practical options today are "ship with a permanent audit finding" or "break the build."Request
Widen the range so the fixed line is reachable:
2.xkeeps the same export map (.,./conninfo,./serve-static,./utils/*), the samehono@^4peer, and still exportsgetRequestListener— which appears to be the only symbol the SDK imports from it (indist/esm/server/streamableHttp.js). The bump requires Node >= 20.Impact note
For consumers who only use the Web-Standard transport, the vulnerable
serve-staticmodule is never imported, and the flaw itself is Windows-specific (%5C→\path resolution). So this is largely an audit-noise problem rather than an exploitable one — but it is noise that every downstream project has to triage and document individually, and the obvious automated remediation actively breaks builds.Happy to open a PR if the range widening is acceptable.