Widen `@hono/node-server` range: `^1.19.9` cannot resolve past GHSA-frvp-7c67-39w9 (no patched 1.x)

Summary

@modelcontextprotocol/sdk@1.29.0 depends on @hono/node-server: ^1.19.9. GHSA-frvp-7c67-39w9 affects all < 2.0.5, and there is no patched 1.x line — so no version satisfying ^1.19.9 is unaffected, and the range itself has to widen to clear the advisory.

This is what makes it different from #2036 and #2042, which cover hono and fast-uri. Both of those note that the SDK's existing semver ranges already permit the fixed versions, so a lockfile refresh resolves them. That is not true here: 1.x → 2.x is a major bump, so consumers cannot fix it on their own without an overrides entry that forces a major version of an adapter the SDK was written against.

Ask

Widen @hono/node-server to ^2.0.5 (or otherwise allow the 2.x line), so consumers can resolve to a patched version.

Reachability (FYI for triage — argues this is low urgency, but not zero)

Worth separating the load graph from the vulnerable surface, since they point in different directions:

serveStatic is never referenced anywhere in the SDK. grep -rn "serveStatic" dist/ returns nothing in 1.29.0. The vulnerable code path needs a running static file server, so no SDK consumer should be exploitable through the SDK itself. That is the main reason we are filing this rather than forcing an override downstream.

But the package is on a genuine runtime path, not just examples. Issue #2036 observes that hono is loaded only by dist/esm/examples/server/honoWebStandardStreamableHttp.js. That holds for hono itself, but @hono/node-server is different:

dist/esm/server/streamableHttp.js:9:import { getRequestListener } from '@hono/node-server';

So it loads for anyone using StreamableHTTPServerTransport — outside the examples/ tree. Only getRequestListener is imported, which is not the affected surface, but it does mean the "could this be a peerDependency / optionalDependency?" suggestion in #2036 doesn't straightforwardly apply to this package the way it might to hono.

Net: not urgent, but it can't be dismissed as examples-only either, and it will keep appearing in every consumer's Security tab until the range moves.

Reporter context

Surfaced as a Dependabot alert on dathere/qsv, whose MCP server uses StdioServerTransport exclusively — so we are not affected in practice and have deliberately not added an overrides workaround, since forcing a major bump of the adapter carries more risk for us than the unreachable vulnerability does. We are waiting on the upstream range instead. Filing so the constraint is visible, as it can't be resolved consumer-side as cleanly as #2036 / #2042 can.

Related: #2036, #2042.

Start by locating the dependency declaration for @hono/node-server and inspect dist/esm/server/streamableHttp.js, where getRequestListener is imported. Verify the transport tests and dependency resolution with the 2.x line. Done means consumers can resolve a patched @hono/node-server version without an override, while StreamableHTTPServerTransport remains compatible.