MCP SDK npm Audit Wants a Downgrade? Upgrade to 1.30.0

If an npm-family audit tells you to downgrade @modelcontextprotocol/sdk to 1.24.3 for GHSA-frvp-7c67-39w9, do not accept that automated fix. Upgrade the v1 SDK to 1.30.0 or later, refresh the lockfile, and verify that @hono/node-server resolves to 2.0.5 or later on Node.js 20+.

The downgrade removes newer MCP transport APIs and can break a working server. The forward fix shipped in @modelcontextprotocol/sdk@1.30.0: its dependency range now permits the first patched Hono Node adapter. The steps below prove which package introduced the alert, apply the smallest safe change, and test the transport you actually use.

Match the Exact Alert

Use this guide when your dependency tree contains:

• @modelcontextprotocol/sdk version 1.25.0 through 1.29.x;

• @hono/node-server version 1.x;

• advisory GHSA-frvp-7c67-39w9; and

• an automated remediation that proposes @modelcontextprotocol/sdk@1.24.3 or another backward move.

The advisory is a moderate-severity Windows path-traversal flaw in @hono/node-server's serve-static implementation. An encoded backslash can bypass prefix-mounted middleware and expose a file inside the configured static root. It does not escape that root.

This is not the same as every Hono or MCP audit finding. Record the advisory ID and dependency chain before changing versions.

Prerequisites

Before updating:

• commit or otherwise preserve the current manifest and lockfile;

• use the repository's existing package manager;

• confirm the application can run on Node.js 20 or later; and

• identify a real MCP transport smoke test, not only a clean audit report.

Run these read-only checks from the package root:

node --version
pnpm list @modelcontextprotocol/sdk @hono/node-server --depth 10
pnpm why @hono/node-server

Expected result: the tree shows which direct or transitive dependency owns the old SDK and adapter. If the runtime is still Node.js 18, stop before forcing the adapter to 2.x. The patched adapter requires Node.js 20 or later even though the v1 SDK package still declares Node.js 18 compatibility.

Step 1: Save the Audit Evidence

Capture the production audit before modifying the lockfile:

pnpm audit --prod

Save the advisory ID, affected package, installed version, and proposed remediation. Do not use a broad automatic fix yet.

Expected result: you can distinguish this exact Hono adapter alert from unrelated advisories that need separate fixes.

Step 2: Upgrade the v1 MCP SDK Forward

If your project directly depends on the v1 SDK, update it in place:

pnpm up @modelcontextprotocol/sdk@^1.30.0

Then inspect the resolved tree:

pnpm list @modelcontextprotocol/sdk @hono/node-server --depth 10

Expected result:

@modelcontextprotocol/sdk 1.30.0 or later
@hono/node-server 2.0.5 or later

Version 1.30.0 changed the adapter range from ^1.19.9 to ^1.19.9 || ^2.0.5. Package managers normally select the newest compatible release, which makes the patched 2.x line reachable. This is why Node.js 20+ is a real prerequisite, not an optional cleanup.

Step 3: If the SDK Is Transitive, Update Its Owner

When pnpm why shows that another package brings in @modelcontextprotocol/sdk, update that parent package first. Re-run the tree inspection after every change.

If the parent has not released an update and you already require Node.js 20+, a narrow temporary override can unblock verification:

{
  "pnpm": {
    "overrides": {
      "@modelcontextprotocol/sdk>@hono/node-server": "^2.0.5"
    }
  }
}

Then refresh the lockfile with the normal project install and repeat pnpm list.

Treat the override as a reviewed compatibility decision, not a universal fix. Scope it to the SDK dependency, document why it exists, and remove it after the owning package adopts SDK 1.30.0 or later. Do not apply it on Node.js 18.

Step 4: Test the Transport Boundary

A clean dependency tree is necessary, but it does not prove that your MCP server still works. Run the project's existing unit and integration test commands, then exercise the transport you deploy.

For a local stdio server, verify that the client can:

1. start the server process;

2. complete initialize;

3. list tools; and

4. call one harmless read-only tool.

For a Streamable HTTP server, verify:

1. the server starts on the supported Node.js runtime;

2. initialize completes over HTTP;

3. the tool list matches the pre-upgrade result; and

4. one read-only call returns the expected typed response.

Expected result: the same public tool contract works before and after the dependency update. The upstream change was tested against getRequestListener, the only adapter export used by the v1 SDK's Streamable HTTP server transport.

For a separate protocol-level check, use the MCP Inspector testing guide. If the server exposes provider credentials, also review how to audit an Agent Skill before installing it.

Step 5: Re-run the Audit Without Hiding Other Findings

Run the production audit again:

pnpm audit --prod

Expected result: GHSA-frvp-7c67-39w9 no longer appears through this dependency chain. Other advisories may remain and should be triaged independently. Do not raise an audit threshold or add an ignore rule merely to make the command exit successfully.

Review the final diff:

git diff -- package.json pnpm-lock.yaml pnpm-workspace.yaml

The expected change is narrow: the SDK constraint if it is direct, the resolved adapter version, and the corresponding lockfile entries.

Why the Downgrade Is the Wrong Fix

The old SDK range could never select a patched adapter because every patched @hono/node-server release is in the 2.x line. Automated remediation therefore found a version of the MCP SDK from before that dependency was introduced: 1.24.3.

That removes the alert by removing the dependency, not by preserving the current contract on a patched adapter. Projects using newer Streamable HTTP APIs can then fail to build or run. SDK 1.30.0 solves the constraint in the forward direction.

How Reachable Is the Vulnerability?

The advisory matters, but reachability changes urgency:

• the vulnerable function is serveStatic;

• the exploit requires a Windows host and an HTTP request containing an encoded backslash;

• the protected file remains inside the configured static root; and

• the v1 MCP SDK imports getRequestListener, not serveStatic.

An stdio-only MCP server is therefore not exposed through this SDK path. A Streamable HTTP server using only the SDK's listener also does not call the affected function. That makes many downstream alerts low-reachability dependency findings, not proof of exploitation.

Still, leave that conclusion in a dated security note only when you cannot upgrade immediately. A dependency may use the adapter's static middleware elsewhere, and future code can change reachability. Removing the vulnerable version is cleaner than maintaining a permanent exception.

Common Failure Modes

Do Not Turn an Audit Fix Into an MCP v2 Migration

The MCP TypeScript SDK v2 splits the monolithic package into client, server, core, and runtime adapter packages. It also requires Node.js 20+ and changes imports and several APIs.

That migration can be worthwhile, but it is not required to clear this v1 advisory. Apply the small v1 update first. If you later migrate, follow the official staged migration guide and keep v1 and v2 objects from crossing the same in-process boundary.

Reduce the Integration Surface You Own

If your MCP server exists mainly to reach third-party APIs, consider whether maintaining its authentication, provider SDKs, and transitive security updates is part of your product advantage. A managed integration layer can expose a typed Action while keeping provider credentials outside the repository.

Give your coding agent this instruction:

Follow https://aident.ai/SETUP.md

Then ask it to search for one connected read-only Action, inspect the current input schema, and execute one narrow request. The measurable success condition is one typed provider response with no provider API key copied into source code, shell history, or the task transcript.

For the security boundary behind that workflow, read how to give AI agents API access without exposing keys and how to reduce MCP token usage.

Ready to test it? Set up Aident Loadout, run one read-only Action, and keep the provider credential out of the project.

Sources

• GHSA-frvp-7c67-39w9, GitHub Advisory Database, published June 15 and reviewed July 21, 2026

• MCP SDK dependency-range report, opened July 21, 2026

• Report that automated remediation suggests a breaking downgrade, opened July 24, 2026

• Merged v1 fix and transport test plan, merged July 27, 2026

• @modelcontextprotocol/sdk package, version 1.30.0 available August 3, 2026

• Official MCP TypeScript SDK v1-to-v2 migration guide

This article reflects package metadata and public security reports available on August 3, 2026. Recheck the advisory, package versions, runtime requirements, and your resolved lockfile before applying the change.