The two GHSAs hiding across popular MCP servers

When we scanned the five official @modelcontextprotocol reference servers in April 2026, every one came back with the same two findings: GHSA-8r9q-7v3j-jr4g and GHSA-w48q-cv73-mx4w, both HIGH severity, both on @modelcontextprotocol/sdk@1.0.1, both invisible to standard SCA tooling because the SDK is a transitive rather than a declared dependency.

This post breaks down what those two advisories actually are, how each one plays out against an MCP deployment, and what it takes to verify whether your servers are affected.

What they share

Both advisories affect the same package and the same installed version: @modelcontextprotocol/sdk@1.0.1. The SDK is the core implementation library the official server packages wrap. Every server in the @modelcontextprotocol namespace pulls it in; none of their lockfiles currently resolve it above 1.0.1.

The fixes exist. They've existed for a while - 1.24.0 for the DNS rebinding issue, 1.25.2 for the ReDoS. The installed version is 24 and 25 minor releases behind those fixes respectively. The advisories are open, the patched versions are published to npm, and a fresh install of any of the five official servers today still lands on 1.0.1.

GHSA-w48q-cv73-mx4w - DNS rebinding

Severity: HIGH  /  Fixed in: @modelcontextprotocol/sdk@1.24.0  /  Installed: 1.0.1

The mechanism

The SDK's HTTP listener doesn't validate the Host header. This is the prerequisite for a DNS rebinding attack.

DNS rebinding is a technique that collapses the browser's same-origin policy for a specific domain. The attack flow:

1. A user visits an attacker-controlled webpage while an MCP server is running on localhost.
2. The page's domain initially resolves to the attacker's IP - completely normal, no red flags.
3. The attacker lets the DNS TTL expire (typically 60 seconds), then changes the DNS record to resolve to 127.0.0.1.
4. The browser's same-origin policy now considers the attacker's domain to be same-origin with localhost. Requests from the page's JavaScript to that domain are treated as local.
5. The attacker's page starts issuing fetch requests to the MCP server. It enumerates tools, invokes them, reads responses.

No malware is written. No privilege escalation occurs. The user's browser tab is the attack surface. The MCP server on localhost - with its full tool access to the filesystem, code environment, or API keys - responds normally to every request.

The MCP-specific exposure

This matters more for MCP than for a typical localhost web server because of what MCP tools can do. An MCP server might expose: read/write access to the filesystem, shell execution, database queries, API calls authenticated with the user's stored credentials. The attacker doesn't need to compromise the host - they just need to call the tools.

The attack is also passive from the user's perspective. They open a browser tab. They might not interact with it at all. After ~60 seconds, the rebinding takes effect, and the attacker's script runs silently in the background.

Who is affected

Any deployment where:

• An MCP server using sdk@1.0.1 is running and accessible on an HTTP endpoint (localhost or otherwise)
• A browser is running on the same machine (or network path) during the session

This is the standard developer setup. It's also common in CI environments that run integration tests with a live MCP server.

The fix

Update to @modelcontextprotocol/sdk@1.24.0 or later. The patch adds Host header validation that rejects requests from unexpected origins. Verify the installed version with:

npm ls @modelcontextprotocol/sdk --all

GHSA-8r9q-7v3j-jr4g - ReDoS

Severity: HIGH  /  Fixed in: @modelcontextprotocol/sdk@1.25.2  /  Installed: 1.0.1

The mechanism

The SDK's message parser contains a regular expression with catastrophic backtracking - a pattern that can cause the regex engine to enter exponential time complexity when given a crafted input.

The specific trigger is a crafted string in the content of an MCP tool response, not in an inbound request. An agent calls a tool on an MCP server; the server returns a response; the SDK's parser processes that response. If the response content matches the catastrophic pattern, the JavaScript event loop is pinned for as long as it takes the regex to fail - which for sufficiently crafted inputs is effectively indefinitely.

The practical effect: the agent process stops making progress. Any other tools, requests, or callbacks queued in the event loop are blocked. If the MCP server is hosted (not localhost), this is a remote DoS against the agent process.

The attack surface inversion

This advisory is worth spelling out carefully because it inverts the standard threat model.

Most application security tooling is built around the assumption that attack traffic flows inward - through user input, HTTP requests, uploaded files. Defenses like WAFs, input validation, and rate limiting are positioned at the inbound boundary.

The ReDoS in GHSA-8r9q arrives through the response path - outbound traffic coming back to the agent. The MCP server controls the response content. If the server is compromised, misconfigured, or malicious, it can return a crafted string that disables the calling agent. A WAF on the agent's inbound HTTP port provides no protection at all.

Who is affected

Any agent process that:

• Calls an MCP tool over a server using sdk@1.0.1
• Processes the tool response through the SDK's parser

This includes any agent that calls a third-party or community-hosted MCP server where the response content is not fully trusted, and any internal setup where a compromised server could return attacker-controlled content.

Agentic pipelines that call multiple servers in sequence are particularly relevant - a single poisoned response early in the chain can stall the entire pipeline.

The fix

Update to @modelcontextprotocol/sdk@1.25.2 or later. This version patches the catastrophic backtracking in the parser. Since this fix is in a higher version than the DNS rebinding fix, updating to >=1.25.2 addresses both advisories.

Checking your exposure

npm ls @modelcontextprotocol/sdk --all

Important: updating package.json to declare >=1.25.2 is not sufficient on its own. If package-lock.json already pins 1.0.1, npm install will honor the lock and leave the vulnerable version installed. You need to update the lockfile entry explicitly and regenerate, then verify with npm ls.

Why these are easy to miss

Neither advisory surfaces on a standard PURL-based scan of the server packages themselves. The @modelcontextprotocol/server-* packages have no GHSA entries - the advisories are on the SDK they transitively depend on. Dependabot, GitHub's dependency graph, and most CI advisory scanners query packages at the declared-dependency level and return clean.

You need to walk the installed npm tree recursively and query every node to reach sdk@1.0.1. That's what our scanner found, and it's what npm ls --all exposes.

A detailed explanation of the scan-depth gap is in the companion post: PURL vs. npm-tree scanning.

Scope of impact

From our April 2026 scan: 5 of 5 official @modelcontextprotocol reference servers carry both advisories. Every server we scanned resolved sdk@1.0.1. The aggregate finding count from a full tree scan:

Raw scan output is attached to the Bindfort research page: bindfort.com/research.

What to do

If you operate or maintain an MCP server built on any of the @modelcontextprotocol packages:

1. Run npm ls @modelcontextprotocol/sdk --all in the installed directory.
2. If the resolved version is below 1.25.2, update the lockfile to resolve >=1.25.2 and regenerate.
3. Verify the installed version changed with npm ls.
4. If you depend on any community or third-party MCP servers, ask maintainers to do the same.

If you want to check whether other MCP servers you run carry these or other advisories - including servers not in the official namespace - compare notes with us.