Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Force GitHub README to respect dark mode (function() { var style = document.createElement('style'); style.textContent = ' .markdown-body { color-scheme: dark light; } .markdown-body pre { background: #161b22 !important; } .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; } .markdown-body table th, .markdown-body table td { border-color: #30363d !important; } .markdown-body img { background: #0d1117; } .markdown-body blockquote { border-left-color: #8b949e; } .markdown-body hr { border-color: #30363d; } '; document.head.appendChild(style); })(); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Highlight search terms from Google/DuckDuckGo/Bing referrer (function() { var ref = document.referrer; var terms = []; if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) { var url = new URL(ref); var q = url.searchParams.get('q') || url.searchParams.get('p'); if (q) { terms = q.split(/\s+/).filter(function(t) { return t.length > 2; }); } } if (terms.length === 0) return; var style = document.createElement('style'); style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }'; document.head.appendChild(style); function highlight(node) { if (node.nodeType === 3) { // text node var text = node.textContent; var found = false; terms.forEach(function(term) { var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi'); if (regex.test(text)) { found = true; var frag = document.createDocumentFragment(); var parts = text.split(regex); parts.forEach(function(part, i) { if (i % 2 === 0) { frag.appendChild(document.createTextNode(part)); } else { var span = document.createElement('span'); span.className = 'userscript-highlight'; span.textContent = part; frag.appendChild(span); } }); node.parentNode.replaceChild(frag, node); } }); } else if (node.nodeType === 1 && node.childNodes) { // element var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT']; if (!skipTags.includes(node.tagName)) { Array.from(node.childNodes).forEach(highlight); } } } highlight(document.body); // Re-highlight on dynamic content var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1 || node.nodeType === 3) highlight(node); }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Strip utm_, fbclid, gclid, etc. from all links on page (function() { var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content', 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid', 'ref', 'ref_src', 'source', 'medium', 'campaign']; function cleanUrl(url) { try { var u = new URL(url, window.location.origin); var changed = false; trackingParams.forEach(function(p) { if (u.searchParams.has(p)) { u.searchParams.delete(p); changed = true; } }); return changed ? u.toString() : url; } catch (e) { return url; } } function cleanLinks() { document.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } cleanLinks(); var observer = new MutationObserver(function(mutations) { mutations.forEach(function(m) { m.addedNodes.forEach(function(node) { if (node.nodeType === 1) { if (node.tagName === 'A') cleanLinks(); node.querySelectorAll('a[href]').forEach(function(a) { var clean = cleanUrl(a.href); if (clean !== a.href) a.href = clean; }); } }); }); }); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + ' fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Auto-enable theater mode on YouTube (function() { function tryTheater() { var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]'); if (btn && !btn.classList.contains('activated')) { btn.click(); } } // Try immediately tryTheater(); // Try after navigation (SPA) var lastUrl = location.href; setInterval(function() { if (location.href !== lastUrl) { lastUrl = location.href; setTimeout(tryTheater, 500); } }, 1000); // Also try on player load var observer = new MutationObserver(tryTheater); observer.observe(document.body, { childList: true, subtree: true }); })(); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Remove or un-stick sticky/fixed headers that block content (function() { function unstick() { document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) { if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') { el.style.position = 'static'; el.style.top = 'auto'; el.style.zIndex = 'auto'; } }); } unstick(); var observer = new MutationObserver(unstick); observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] }); })(); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + ' fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua
, 'i'); if (__m === '*' || __re.test(location.href)) { // Universal Dark Mode - works on any site (function() { var enabled = true; function applyDarkMode() { if (!enabled) return; // Create style element if it doesn't exist var style = document.getElementById('universal-dark-mode-style'); if (!style) { style = document.createElement('style'); style.id = 'universal-dark-mode-style'; document.head.appendChild(style); } // Dark mode CSS - inverts colors but preserves images/video style.textContent = ' /* Invert everything except media */ html { filter: invert(1) hue-rotate(180deg) !important; background: #1a1a2e !important; } /* Restore images, videos, iframes, canvas */ img, video, iframe, canvas, svg, picture, [style*="background-image"] { filter: invert(1) hue-rotate(180deg) !important; } /* Preserve specific elements that should not be inverted */ .no-dark-mode, .no-dark-mode *, [data-theme="light"], [data-theme="light"], .ace_editor, .ace_editor *, .CodeMirror, .CodeMirror *, .monaco-editor, .monaco-editor *, .markdown-body pre, .markdown-body pre *, .highlight, .highlight *, pre code, pre code * { filter: none !important; } /* Fix common UI elements */ .modal, .popup, .dropdown-menu, .tooltip, .popover { filter: invert(1) hue-rotate(180deg) !important; background: #2d2d44 !important; border-color: #444 !important; } /* Scrollbars */ ::-webkit-scrollbar { background: #1a1a2e !important; } ::-webkit-scrollbar-thumb { background: #444 !important; } ::-webkit-scrollbar-thumb:hover { background: #555 !important; } /* Selection */ ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; } ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; } '; } function removeDarkMode() { var style = document.getElementById('universal-dark-mode-style'); if (style) style.remove(); } // Toggle with Alt+Shift+D document.addEventListener('keydown', function(e) { if (e.altKey && e.shiftKey && e.key === 'D') { e.preventDefault(); enabled = !enabled; if (enabled) { applyDarkMode(); console.log('[Universal Dark Mode] Enabled'); } else { removeDarkMode(); console.log('[Universal Dark Mode] Disabled'); } } }); // Apply on load applyDarkMode(); // Re-apply on dynamic content var observer = new MutationObserver(function(mutations) { if (enabled && !document.getElementById('universal-dark-mode-style')) { applyDarkMode(); } }); observer.observe(document.head, { childList: true }); console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle'); })(); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })(); fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9 by ANcpLua · Pull Request #2574 · modelcontextprotocol/typescript-sdk · GitHub
Skip to content

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

Open
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range
Open

fix(node): widen @hono/node-server past GHSA-frvp-7c67-39w9#2574
ANcpLua wants to merge 2 commits into
modelcontextprotocol:mainfrom
ANcpLua:fix/widen-hono-node-server-range

Conversation

@ANcpLua

@ANcpLuaANcpLua commented Jul 29, 2026

Copy link
Copy Markdown

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

@ANcpLua
ANcpLua requested a review from a team as a code ownerJuly 29, 2026 06:20
@changeset-bot

changeset-botBot commented Jul 29, 2026

Copy link
Copy Markdown

🦋 Changeset detected

Latest commit: 62e1796

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

This PR includes changesets to release 1 package
NameType
@modelcontextprotocol/nodePatch

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

pkg-pr-newBot commented Jul 29, 2026

Copy link
Copy Markdown

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: 62e1796

@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 192ab2c to 185a02fCompareJuly 29, 2026 07:15
The runtimeServerOnly catalog pinned ^1.19.9, which cannot reach the
advisory's fix (2.0.5; no patched 1.x exists). Widen to
^1.19.9 || ^2.0.5, matching the range merged for v1.x in modelcontextprotocol#2549 and
shipped in 1.30.0 — that fix landed on a branch without changesets, so
it could not propagate to the v2 monorepo. The lockfile resolution moves
to 2.0.11, as the v1.x change did. getRequestListener is the only
imported symbol and keeps the same signature and contract in 2.x;
@hono/node-server@2 requires Node >= 20, which @modelcontextprotocol/node
already declares.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ANcpLua
ANcpLuaforce-pushed the fix/widen-hono-node-server-range branch from 185a02f to 88fcc8bCompareJuly 29, 2026 10:04
@ANcpLua

Copy link
Copy Markdown
Author

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.

@claudeclaudeBot added the v2 Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes label Aug 18, 2026
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

v2Ideas, requests and plans for v2 of the SDK which will incorporate major changes and fixes

Projects

None yet

1 participant

@ANcpLua