fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9

[ANcpLua]

Closes #2548, closes #2531 — the v1.x half shipped in 1.30.0 via #2549; this is the main half.

What

Widen @hono/node-server from ^1.19.9 to ^1.19.9 || ^2.0.5 — the same range #2549 merged for v1.x — and move the lockfile resolution to 2.0.11, as that change did. On main the range lives in the runtimeServerOnly catalog in pnpm-workspace.yaml; that one line feeds @modelcontextprotocol/node and the examples. A changeset is included (patch on @modelcontextprotocol/node).

Why a separate PR

#2549 merged to v1.x, which doesn't version through changesets, so the fix structurally cannot propagate to the v2 monorepo: @modelcontextprotocol/node@2.0.0 still declares ^1.19.9, and GHSA-frvp-7c67-39w9 (Windows-only path traversal in serve-static via encoded backslash, moderate severity; fixed in 2.0.5, no patched 1.x exists) remains unreachable for every v2 consumer. #2548 covers why npm's suggested downstream remediation is unusable.

Why 2.x is safe here

• getRequestListener is the only symbol @modelcontextprotocol/node imports (packages/middleware/node/src/streamableHttp.ts:12); it keeps the same signature and contract in 2.x (the implementation behind it was reworked upstream — the tests covering the affected disconnect and backpressure paths pass), and the . entry's exports are a superset of 1.x's (2.x adds the WebSocket API). What 2.x does change: the ./vercel subpath is removed, and declarations ship as .d.mts/.d.cts only (no plain .d.ts), with types nested per condition — nothing in this repo uses either, and there are no type-only imports from the package anywhere in the workspace.
• The examples are fed by the same catalog entry and import serve (19 files); they compile and build against 2.0.11 — pnpm -r typecheck and pnpm -r build both exit 0.
• @modelcontextprotocol/node already declares engines.node >= 20 — exactly @hono/node-server@2's floor, so the engines conflict discussed on the issue for v1.x does not arise on main.
• The vulnerable serve-static module is never imported by the package or the examples.

Verification

• pnpm install --frozen-lockfile exits 0; the lockfile diff contains only the @hono/node-server entries.
• pnpm -r build and pnpm -r typecheck (all packages + examples): exit 0.
• pnpm --filter @modelcontextprotocol/node test: 97 passed, 2 failed — the same two SSE tests (should handle batch request messages with SSE stream for responses, should store and replay MCP server tool notifications) fail identically on unmodified main with @hono/node-server@1.19.11 in my environment (Node 26.5.0, macOS), so the delta from this change is zero.
• Note for anyone re-checking with pnpm audit: the branch still reports GHSA-frvp-7c67-39w9 once, via examples/cli-client → @google/genai → @modelcontextprotocol/sdk@1.29.0 — the published v1 SDK from before fix(deps): widen @hono/node-server past GHSA-frvp-7c67-39w9 #2549. That transitive path is outside this PR's reach and clears when @google/genai moves to 1.30.0.

🤖 Generated with Claude Code

[changeset-bot]

🦋 Changeset detected

Latest commit: 88fcc8b

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@modelcontextprotocol/node	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[pkg-pr-new]

Open in StackBlitz

@modelcontextprotocol/client

npm i https://pkg.pr.new/@modelcontextprotocol/client@2574

@modelcontextprotocol/codemod

npm i https://pkg.pr.new/@modelcontextprotocol/codemod@2574

@modelcontextprotocol/core

npm i https://pkg.pr.new/@modelcontextprotocol/core@2574

@modelcontextprotocol/server

npm i https://pkg.pr.new/@modelcontextprotocol/server@2574

@modelcontextprotocol/server-legacy

npm i https://pkg.pr.new/@modelcontextprotocol/server-legacy@2574

@modelcontextprotocol/express

npm i https://pkg.pr.new/@modelcontextprotocol/express@2574

@modelcontextprotocol/fastify

npm i https://pkg.pr.new/@modelcontextprotocol/fastify@2574

@modelcontextprotocol/hono

npm i https://pkg.pr.new/@modelcontextprotocol/hono@2574

@modelcontextprotocol/node

npm i https://pkg.pr.new/@modelcontextprotocol/node@2574

commit: 88fcc8b

[ANcpLua]

One question for maintainers rather than a change request: is the ^1.19.9 arm worth keeping on main?

It mirrors #2549, where it had a concrete job — v1.x declares engines.node >=18, so Node 18 consumers needed the 1.x line to stay reachable. On main that consumer doesn't exist: every published package declares engines.node >=20 and CI runs 20/22/24. Meanwhile the arm keeps a resolvable path the advisory permanently applies to (no patched 1.x exists), and 1.19.9–1.19.12 — which it also admits — are additionally affected by GHSA-92pp-h63x-v22m (patched in 1.19.13). Since @hono/node-server doesn't appear in the package's public type surface, narrowing wouldn't be a type break for consumers.

If consistency with the v1.x range is the priority, this PR as-is is that. If closing the vulnerable resolution path matters more, I'm happy to narrow the catalog to ^2.0.5. The lockfile resolves 2.0.11 either way.