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

[arimu1]

Summary

Widens @hono/node-server so consumers can resolve a version that clears GHSA-frvp-7c67-39w9 (path traversal in serve-static on Windows; fixed in >= 2.0.5). There is no patched 1.x line, so ^1.19.9 alone can never satisfy the advisory.

Range change: "^1.19.9" → "^1.19.9 || ^2.0.5"

• Dual range keeps the existing 1.x floor for Node 18 installs (SDK still declares engines.node: >=18).
• ^2.0.5 makes the first patched version (and later 2.x) reachable without requiring every consumer to add an overrides entry.
• The SDK only imports getRequestListener from @hono/node-server (src/server/streamableHttp.ts); it does not use serveStatic. Downstream reports (see Widen @hono/node-server range: ^1.19.9 cannot resolve past GHSA-frvp-7c67-39w9 (no patched 1.x) #2531) confirm the 2.x export is a drop-in for that symbol.

Fixes #2531
Fixes #2548 (duplicate)

Motivation

Unlike the hono / fast-uri cases in #2036 / #2042, this cannot be fixed by a lockfile refresh alone: the published range cannot select any patched version. npm audit therefore keeps flagging every consumer of @modelcontextprotocol/sdk@>=1.25.0, and npm’s suggested remediation incorrectly points at a downgrade to 1.24.3 (before the dependency existed), which breaks StreamableHTTPServerTransport.

Test plan

• node -e "import { getRequestListener } from '@hono/node-server'" — function export present on @hono/node-server@2.0.11
• npm run build (esm + cjs)
• npm test -- test/server/streamableHttp.test.ts — 162 passed
• npm test -- test/integration-tests/stateManagementStreamableHttp.test.ts — 8 passed
• Direct @hono/node-server dependency resolves to 2.0.11 under the new range (lockfile updated)

Notes

• @hono/node-server@2.x declares node >= 20. The dual range preserves Node 18 compatibility for consumers who stay on 1.x; Node 20+ installs can take 2.x and clear the advisory.
• Nested vulnerability noise from @modelcontextprotocol/conformance’s older SDK copy is out of scope for this PR.

[changeset-bot]

⚠️ No Changeset found

Latest commit: 71f3363

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

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

[pkg-pr-new]

Open in StackBlitz

npm i https://pkg.pr.new/@modelcontextprotocol/sdk@2549

commit: 71f3363

[arimu1]

Follow-up note after self-review:

The dual range ^1.19.9 || ^2.0.5 does not select 1.x on Node 18. Package managers resolve the highest matching version (here 2.x); they do not pick by consumer Node version. The lockfile already pins @hono/node-server@2.0.11.

So the “Node 18 keeps 1.x” framing in the earlier description was wrong. What this PR actually does:

• Clears GHSA-frvp by allowing 2.0.5+ (and CI/install resolves 2.x)
• Keeps a 1.x alternative only if a consumer’s resolver is constrained elsewhere

If maintainers prefer a cleaner story, happy to switch to "@hono/node-server": "^2.0.5" only (and optionally note engines / Node 20 for that path), or keep 1.x and document the advisory as out of reach for our getRequestListener-only usage.

Also happy to add a changeset if this branch uses them for the published package (v1.x layout may differ from main monorepo).

[leansii]

Another affected downstream here: a Vue / shadcn-vue app that only pulls the SDK transitively (shadcn-vue → @modelcontextprotocol/sdk) as a build-time CLI. We never run the HTTP server transport at all, yet every npm audit flags GHSA-frvp-7c67-39w9 because ^1.19.9 can't resolve past it, and npm's auto-fix points at the build-breaking 1.24.3 downgrade.

Confirming the fix from a consumer's side: I applied "@hono/node-server": "^2.0.5" as an npm overrides entry, resolved to 2.0.12, and everything (type-check + build) is green — getRequestListener is indeed a drop-in and serveStatic is never imported by the SDK. So the dual range in this PR is a clean, non-breaking fix. Would be great to see it merged — it'd let every downstream drop the override. 👍