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

[jqnatividad]

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.

Advisory	GHSA-frvp-7c67-39w9 — path traversal in serve-static on Windows via encoded backslash (%5C)
Severity	Moderate (CVSS 5.9)
Vulnerable	< 2.0.5
First patched	2.0.5 (current latest: 2.0.11)
SDK range	^1.19.9 — cannot resolve to a patched version

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.

[kriptoburak]

Downstream confirmation: openclaw@2026.7.1-2 pins @modelcontextprotocol/sdk@1.29.0, and a clean @xquik/tweetclaw install reports this chain as 5 moderate audit entries. We verified that OpenClaw latest and beta both still carry it, and we did not force a major-version override.

One compatibility constraint is important for a v1.x fix: @hono/node-server@2.0.5 declares node >=20, while @modelcontextprotocol/sdk@1.29.0 declares node >=18. A direct range change to ^2.0.5 would therefore drop the SDK's documented Node 18 compatibility. A patched Hono 1.x release, or an SDK-side change that avoids this dependency while preserving Node 18, would be safer.

Our reachability result matches the issue: the SDK imports getRequestListener, while the vulnerable serveStatic surface is not referenced. We are treating it as low-reachability but unresolved until upstream ships a compatible fix.

[AviVahl]

Workaround for npm users:

"overrides": {
    "@modelcontextprotocol/sdk": {
      "@hono/node-server": "^2.0.11"
    }
}

new @hono/node-server version drops EOL Node 18, but seems to have the same API, so everything should work as expected (assuming you're using Node 20 or above).

[mitchallen]

Downstream confirmation — the ^2.0.11 override works for a Node 20+ HTTP-transport consumer.

Applied the workaround from this comment on an SDK 1.29.0 server that uses StreamableHTTPServerTransport (so it does load @hono/node-server at runtime, not stdio-only):

"overrides": {
  "@modelcontextprotocol/sdk": {
    "@hono/node-server": "^2.0.11"
  }
}

Resolves to @hono/node-server@2.0.11. getRequestListener — the only symbol the SDK imports (dist/esm/server/streamableHttp.js) — is unchanged in 2.x, so it's a drop-in. Verified: npm audit --omit=dev → 0 vulnerabilities, full test suite passes, and a live initialize handshake over the HTTP transport succeeds.

The Node 18 concern raised above is the deciding factor: 2.x requires Node >=20, so this override is only safe for consumers who already require Node >=20 (we declare "engines": { "node": ">=20" }). Consumers still supporting Node 18 can't take it, which is exactly why the fix needs to land in the SDK's range/major rather than being pushed to every consumer. +1 on waiting for the upstream widen or SDK v2's optional-transport split.