Widen @hono/node-server range to ^1.19.9 || ^2 so GHSA-frvp-7c67-39w9 is reachable (npm suggests a breaking downgrade)

Open Beginner friendly
#2,548 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
74/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Quiet
Tech stack
node.js, typescript
Domain
backend-api-design, security

Research direction

Start by inspecting the SDK dependency declaration and the import from dist/esm/server/streamableHttp.js. Check the proposed @hono/node-server range against its export map, peer requirement, and Node version support. Done means the fixed 2.x line is reachable without breaking the WebStandardStreamableHTTPServerTransport build or the existing import.

Written by the indexing model from the issue text.

Description

bug P2 ready for work v2
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.

Dominant language
TypeScript
Stars
13.4k
Forks
2.2k
Avg merge
3d 12h
Merged PRs (30d)
3

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/typescript-sdk

All issues in modelcontextprotocol/typescript-sdk

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.