CVE-2025-66414
Wolfi vulnerability analysis and mitigation

Overview

CVE-2025-66414 is a DNS rebinding protection misconfiguration vulnerability in the Model Context Protocol (MCP) TypeScript SDK (@modelcontextprotocol/sdk) that allows malicious websites to bypass same-origin policy restrictions and interact with locally running MCP servers. All versions of the npm package prior to 1.24.0 are affected when using StreamableHTTPServerTransport or SSEServerTransport without authentication and without explicitly enabling enableDnsRebindingProtection. The vulnerability was published on December 2, 2025, with a patch released the same day. It carries a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 7.6 (High) (Github Advisory, GitHub Security Advisory).

Technical details

The root cause is classified as CWE-1188 (Insecure Default Initialization of Resource) and CWE-350 (Reliance on Reverse DNS Resolution for a Security-Critical Action): the SDK's HTTP-based server transports did not enable DNS rebinding protection by default, leaving the enableDnsRebindingProtection option opt-in rather than opt-out (Github Advisory). In a DNS rebinding attack, a malicious website tricks the victim's browser into resolving the attacker's domain to 127.0.0.1, then uses JavaScript to send cross-origin requests to the local MCP server — effectively bypassing the browser's same-origin policy. The vulnerable code path existed in validateRequestHeaders() within both streamableHttp.ts and sse.ts, where the original condition if (!originHeader || !this._allowedOrigins.includes(originHeader)) incorrectly rejected requests without an Origin header (non-browser clients) while also failing to enforce protection against browser-originated DNS rebinding requests by default (GitHub PR #1205). The fix changed the condition to if (originHeader && !this._allowedOrigins.includes(originHeader)), ensuring only requests with an invalid Origin header are rejected, and enabled protection by default in createMcpExpressApp() (GitHub Commit).

Impact

Successful exploitation allows a remote attacker — via a malicious website visited by the victim — to invoke any tools or access any resources exposed by the locally running MCP server, without authentication. This results in high confidentiality and integrity impact against the vulnerable system, as the attacker can read sensitive data accessible to the MCP server and trigger unauthorized actions or tool invocations on the user's behalf. Availability is not directly impacted. The scope is limited to scenarios where an HTTP-based MCP server is running on localhost without authentication, which, while not recommended by MCP security best practices, may occur in developer or local AI assistant environments (Github Advisory).

Exploitability

No public proof-of-concept exploit code or in-the-wild exploitation has been reported for CVE-2025-66414. The EPSS score is approximately 0.052% (17th percentile), indicating a low near-term exploitation probability (Github Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires user interaction (the victim must visit a malicious website while running a vulnerable local MCP server without authentication), limiting the attack surface. No threat actor attribution has been identified.

Exploitation steps

  1. Reconnaissance: Identify whether the target user is running an HTTP-based MCP server locally (e.g., via StreamableHTTPServerTransport or SSEServerTransport) on a default port (commonly 3000 or similar) without authentication, using SDK versions prior to 1.24.0.
  2. Set up malicious domain: Register a domain and configure a DNS server to respond with a very short TTL (e.g., 1 second), initially resolving to the attacker's own server IP.
  3. Serve malicious page: Host a web page on the attacker's domain that loads JavaScript in the victim's browser. The page initially communicates with the attacker's server to confirm the victim has loaded it.
  4. DNS rebind: After the short TTL expires, update the DNS record to resolve the attacker's domain to 127.0.0.1 (localhost). The browser's DNS cache expires and re-resolves the domain to localhost.
  5. Cross-origin request to MCP server: The JavaScript on the malicious page now sends HTTP requests (e.g., POST to the MCP server endpoint) using the attacker's domain as the origin. Because the domain now resolves to localhost, the browser sends the request to the local MCP server. The vulnerable server, lacking DNS rebinding protection, does not validate the Host/Origin header and processes the request.
  6. Invoke MCP tools/resources: The attacker's JavaScript sends crafted MCP protocol messages to invoke exposed tools or read resources, exfiltrating results back to the attacker's server via the still-open connection or secondary requests (Github Advisory, GitHub PR #1205).

Indicators of compromise

  • Network: Unexpected HTTP POST or GET requests to local MCP server endpoints (e.g., http://localhost:<port>/) originating from browser processes with an Origin header pointing to an unfamiliar external domain; outbound connections from the local machine to unknown external IPs shortly after MCP tool invocations.
  • Logs: MCP server access logs showing requests with Origin headers from domains not associated with legitimate local development (e.g., Origin: http://attacker-domain.com); repeated MCP tool invocation log entries not initiated by the local user.
  • Process: Browser processes (e.g., Chrome, Firefox) making network connections to 127.0.0.1 on the MCP server port outside of normal developer activity.

Mitigation and workarounds

The primary remediation is to upgrade the @modelcontextprotocol/sdk npm package to version 1.24.0 or later, which enables DNS rebinding protection by default for servers created via createMcpExpressApp() when binding to localhost (Github Advisory). Users with custom Express configurations should update to 1.24.0 and apply the exported hostHeaderValidation() middleware to their unauthenticated localhost servers. As a general best practice, avoid running HTTP-based MCP servers locally without authentication; prefer stdio transport for local use cases, which is not affected by this vulnerability. If immediate upgrade is not possible, manually enable enableDnsRebindingProtection: true and configure allowedOrigins in the transport options as a temporary workaround (GitHub Security Advisory).

Community reactions

The vulnerability was credited to researcher JLLeitschuh and published by maintainer pcarleton on December 2, 2025, the same day the patch was released, indicating a coordinated disclosure process (GitHub Security Advisory). The fix was contributed by community member jacopoc via pull request #1205, reflecting active community engagement in MCP security. Red Hat also tracked the vulnerability, indicating broader ecosystem awareness (Feedly). No significant social media controversy or major media coverage has been identified beyond standard vulnerability database entries.

Additional resources


SourceThis report was generated using AI

Related Wolfi vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

CVE-2026-71847HIGH8.7
  • Ruby logoRuby
  • ruby3.2-rails-8.1
NoYesAug 07, 2026
CVE-2026-45808HIGH7.1
  • Wolfi logoWolfi
  • openbao-debugsource
NoYesAug 07, 2026
CVE-2026-71557MEDIUM6.3
  • Packer logoPacker
  • cloudbeat-9.2
NoYesAug 07, 2026
CVE-2026-46358MEDIUM5.4
  • Wolfi logoWolfi
  • openbao
NoYesAug 07, 2026
CVE-2026-46405MEDIUM5.3
  • Wolfi logoWolfi
  • openbao-debugsource
NoYesAug 07, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management