DNS rebinding has been on the security radar for over two decades. In 2025, it stopped being a conference curiosity and became the direct cause of critical vulnerabilities in AI tooling, local developer infrastructure, and the Model Context Protocol ecosystem — prompting Google to ship a structural rewrite of how Chrome handles local network access entirely.
Between early 2024 and the end of 2025, at least five significant CVEs were assigned specifically to DNS rebinding flaws in software that tens of thousands of developers run every day. Google shipped a fundamental architectural change to Chrome in response. And security researchers documented attacks that can complete the full rebind in under three seconds on modern browsers. The conventional wisdom — that DNS pinning, same-origin policies, and private IP filtering made exploitation too impractical to worry about — has collapsed.
How DNS Rebinding Works
To understand the attack, you first need to understand what it circumvents. The same-origin policy (SOP) is the browser security boundary that prevents JavaScript loaded from one domain from making requests to a different domain and reading the response. An attacker who serves malicious JavaScript to a victim cannot use that script to query the victim's router admin panel at 192.168.1.1 — the browser enforces SOP and refuses to carry responses from a different origin back to the attacker's script.
DNS rebinding does not break SOP. It subverts it. The attack exploits the fact that SOP is enforced based on domain names, not IP addresses, while DNS is the system that maps domain names to IPs — and DNS records can change.
Here is the full attack sequence. T1583.002 An attacker controls both a malicious domain (say, attack.example.com) and the authoritative DNS server for that domain. They set the DNS TTL to an extremely low value — often zero or one second. A victim visits the domain, T1189 and the attacker's DNS server initially resolves it to the attacker's real web server IP. The page loads and serves JavaScript that begins making repeated requests back to attack.example.com. After the TTL expires, the attacker changes the DNS record to resolve to an internal IP address: the victim's router, a local API server, or 127.0.0.1 for localhost services. The browser, following the domain name, now sends those JavaScript requests directly to that internal address. From the browser's perspective, it is still talking to attack.example.com — the same origin. SOP is satisfied. The internal service receives the request. T1046 The attacker reads the response.
The attack is not new. Security researcher Dan Kaminsky documented early forms of it in the early 2000s. Princeton researchers published formal analysis in 2007. What is new is the target surface — and the tooling available to exploit it.
The Tooling That Changed the Calculus
For years, DNS rebinding was treated as theoretically interesting but operationally inconvenient. TTL expiration could take minutes, victim browsers often cached DNS longer than they should, and the attacker needed to know what service sat on which internal IP. In 2018, NCC Group released Singularity of Origin, an open-source DNS rebinding attack framework that transformed those limitations into manageable engineering problems.
Singularity includes a custom DNS server, an HTTP manager interface, and a growing library of attack payloads targeting specific applications. It can perform the full rebind in under three seconds using techniques like multiple-answer DNS responses and DNS cache flooding. It ships with payloads for etcd key-value dumps, AWS metadata exfiltration, remote code execution via exposed Chrome DevTools, Rails console RCE, and more. The framework includes automated scanning that can identify vulnerable services on a target network and chain them with matching payloads without manual intervention.
"Singularity provides a complete DNS rebinding attack delivery stack: custom DNS server, HTTP server, and several sample attack payloads, ranging from grabbing the home page of a target application to performing remote code execution." — NCC Group, Singularity of Origin repository
Singularity maintains a live demo instance at rebind.it, upgraded to support IPv6 in May 2025. It is the de facto standard tool for DNS rebinding research and red team exercises — and an obvious resource for malicious reconnaissance. The NCC Group repository noted in November 2025 that Chrome 142's Local Network Access feature blocks Singularity's classic rebinding techniques, while simultaneously documenting a workaround via Chrome's origin trial that remains available until May 18, 2026.
Why DNS-over-HTTPS Does Not Help
When DNS-over-HTTPS (DoH) began rolling out widely, some assumed it would offer incidental protection against rebinding. The reasoning: if DNS queries are encrypted and routed through trusted resolvers like Cloudflare or Google, surely an attacker cannot inject malicious DNS responses. That reasoning is incorrect.
DoH encrypts the DNS query channel. DNS rebinding does not rely on intercepting or injecting DNS traffic in transit. The attacker controls the authoritative DNS server for their own domain. When a browser asks what IP corresponds to attack.example.com, that query legitimately travels through the DoH resolver to the attacker's authoritative server, which then returns whatever IP the attacker chooses. DoH faithfully delivers that malicious answer, encrypted, to the browser. NCC Group confirmed this: all traditional DNS rebinding strategies continue to function in DoH environments, and protections advertised by DoH providers do not address the rebinding threat.
CVE-2024-28224: Ollama and the AI Tooling Gap
The 2024–2025 wave of DNS rebinding disclosures began with Ollama. Ollama is an open-source platform for running large language models locally — tools like Llama, Mistral, and others — and had become one of the fastest-growing pieces of AI developer infrastructure, accumulating millions of installations.
NCC Group researcher Gérald Doussot identified a DNS rebinding vulnerability in Ollama tracked as CVE-2024-28224, disclosed in April 2024 and affecting all versions prior to v0.1.29. The vulnerability gave attackers full unauthenticated access to Ollama's API from any malicious website a victim visited, even though the Ollama instance was not exposed to the public internet.
"The Ollama DNS rebinding vulnerability grants attackers full access to the Ollama API remotely, even if the vulnerable system is not configured to expose its API publicly. Access to the API permits attackers to exfiltrate file data present on the system running Ollama." — NCC Group, Technical Advisory CVE-2024-28224
The specific capability chain was alarming. Ollama's API includes endpoints with access to the file system and the ability to pull data from remote repositories. Once an attacker completed the DNS rebind, they could chain multiple API calls to read arbitrary file data accessible to the Ollama process, then exfiltrate it to attacker-controlled servers T1041. NCC Group built a working proof-of-concept using Singularity as the delivery mechanism. Ollama released the fix the same day NCC Group disclosed the issue privately — March 8, 2024 — with the patched version v0.1.29 shipping on March 14.
The MCP Vulnerability Wave: Four CVEs in One Ecosystem
The Ollama disclosure was a preview. The larger DNS rebinding story of 2025 unfolded inside the Model Context Protocol (MCP) ecosystem — the open standard that connects large language models to external tools, APIs, file systems, and business services. MCP servers running locally had become the connective tissue for agentic AI applications, and their architectural assumptions about localhost security made them structurally exposed to rebinding.
MCP servers typically listen on localhost without authentication, on the premise that only local processes should be able to reach them. That premise is exactly what DNS rebinding invalidates.
CVE-2025-66414: MCP TypeScript SDK
Disclosed December 2, 2025, CVE-2025-66414 affected the official MCP TypeScript SDK in versions prior to 1.24.0. HTTP-based MCP servers using StreamableHTTPServerTransport or SSEServerTransport did not enable DNS rebinding protection by default. A malicious website could bypass same-origin policy and send arbitrary requests to a victim's local MCP server, invoking any tools or accessing any resources the server exposed. The fix in version 1.24.0 enabled DNS rebinding protection by default and introduced hostHeaderValidation() middleware for custom configurations.
CVE-2025-66416: MCP Python SDK
The parallel vulnerability in the Python SDK, also disclosed December 2, 2025, carried a CVSS 4.0 score of 7.6 (High) and was classified as CWE-1188: Insecure Default Initialization of Resource. CVE-2025-66416 affected the FastMCP class constructor, which did not enable DNS rebinding protection for localhost-bound servers. The fix in version 1.23.0 modified FastMCP.__init__ to automatically apply TransportSecuritySettings whenever the server binds to 127.0.0.1, localhost, or ::1.
"The root cause is the insecure default configuration for servers running on localhost. The __init__ method of the FastMCP class did not enable DNS rebinding protection by default." — Miggo Security, CVE-2025-66416 Analysis
CVE-2025-49596: Anthropic MCP Inspector — Critical RCE
The highest-severity case was CVE-2025-49596, a critical remote code execution vulnerability in Anthropic's MCP Inspector with a CVSS score of 9.4. Oligo Security Research reported this to Anthropic in April 2025, with public disclosure and the patch arriving in June 2025. The MCP Inspector is the official developer tool for testing and debugging MCP servers, and versions below 0.14.1 were vulnerable to a combination of DNS rebinding and a missing authentication layer between the Inspector client and proxy.
"With code execution on a developer's machine, attackers can steal data, install backdoors, and move laterally across networks — highlighting serious risks for AI teams, open-source projects, and enterprise adopters relying on MCP." — Oligo Security Research, CVE-2025-49596 Disclosure
Oligo's proof-of-concept centered on the 0.0.0.0 IP address — some browsers treat requests to 0.0.0.0 as routing to localhost services, bypassing protections that specifically filter 127.0.0.1. DNS rebinding provided an additional attack path for browsers that handled 0.0.0.0 correctly. Oligo described a scenario where a developer reading a blog post about MCP could end up with arbitrary code executing on their machine T1203. Anthropic patched the vulnerability in MCP Inspector 0.14.1, adding session token authentication, allowed origins verification, and Host/Origin header validation.
CVE-2025-9611: Microsoft Playwright MCP
The vulnerability pattern extended beyond Anthropic's ecosystem. In January 2026, a DNS rebinding vulnerability was publicly disclosed in Microsoft's official Playwright MCP server, affecting versions prior to 0.0.40. The vulnerability carries the identifier CVE-2025-9611. Playwright MCP is among the most widely deployed MCP servers — it provides browser automation capabilities to AI agents, enabling navigation, screenshot capture, and file downloads.
The vulnerability was originally reported to Microsoft in October 2025 and silently patched in v0.0.40 without a CVE assignment. When the researcher sought a CVE from Microsoft's Security Response Center, MSRC declined on the grounds that the vulnerability had already been fixed. VulnCheck subsequently assigned CVE-2025-9611. The root cause was identical to the other MCP SDK CVEs: the Playwright MCP server failed to validate the Origin header on incoming HTTP connections. A malicious website could use DNS rebinding to reach the locally-running Playwright server and invoke its full tool set, using the developer's authenticated browser session as a pivot point into internal resources T1557. The fix in version 0.0.40 added Origin header validation and introduced the allowedHosts configuration option, rejecting requests whose origin did not match localhost or 127.0.0.1.
All four of these CVEs share the same root assumption: that binding to localhost was equivalent to being secure. The attack does not require the service to be publicly exposed. It only requires the developer to visit a malicious web page while the service is running.
Chrome’s Structural Response: Local Network Access
Browser vendors have long known about DNS rebinding. Earlier mitigation attempts included DNS pinning — locking a domain to its first-resolved IP for a session — and blocking requests to RFC 1918 private address ranges. Both approaches proved inadequate. DNS pinning has compatibility issues and fails against attacks that serve multiple IP addresses in a single DNS response. IP range blocking has been bypassed using 0.0.0.0 and other non-standard address representations.
Google's structural response, years in development, shipped as Local Network Access (LNA) in Chrome 142, released October 28, 2025. LNA replaces an earlier failed effort called Private Network Access (PNA), which attempted to require local devices to opt in to receiving cross-origin requests. That approach stalled because updating firmware on millions of routers and IoT devices is not operationally feasible. LNA shifts the enforcement responsibility to websites instead.
Under LNA, any request from a public-origin website to a private IP address (10.x.x.x, 172.16.x.x, 192.168.x.x), a loopback address (127.0.0.1, localhost), or a .local domain now requires explicit user permission via a browser prompt. The LNA specification notes directly that this protection must be applied per-connection, not per-hostname, because DNS can change between connections:
"This check MUST be performed for each new connection made, as DNS rebinding attacks may otherwise trick the user agent into revealing information it shouldn't." — WICG Local Network Access Specification
LNA is a meaningful improvement. Even if an attacker injects JavaScript into a vulnerable public site via XSS, that script cannot silently pivot to private network resources without the user explicitly granting permission. There are important limitations: LNA does not yet apply to WebSockets, WebTransport, or WebRTC connections. Enterprise administrators can disable it globally via policy. Browser extensions are not subject to LNA prompts. And the 0.0.0.0 bypass remains unresolved in major browsers as of early 2026, pending an RFC that would standardize browser handling of that address.
What Still Works Against Defenders in 2026
DNS rebinding is not a single technique — it is a delivery mechanism that chains multiple ATT&CK tactics into a browser-native kill chain. Resource Development (T1583.002) funds the attack: attacker-controlled DNS infrastructure. Initial Access (T1189) delivers it: a victim simply navigating to a page. Discovery (T1046, T1016) expands the blast radius: JavaScript mapping the victim's internal services. Execution (T1203) escalates it: unauthenticated API calls becoming code execution. Exfiltration (T1041) monetizes it: file system contents leaving over the same HTTP channel that staged the attack. The adversary never touches the target machine directly. Every step happens inside the victim's browser — which the browser itself vouches for as same-origin.
LNA and patched SDK defaults have raised the floor, but the threat is not resolved. Non-Chrome browsers do not implement LNA. Firefox, Safari, and others have their own mitigation approaches with varying effectiveness, but none have shipped an equivalent permission-gated architecture. Attackers targeting victims on non-Chrome browsers face a significantly lower barrier.
The 0.0.0.0 vector documented by Oligo Security remains unpatched in major browsers. Services that bind to all interfaces on localhost can be reached from public websites on affected browsers without requiring a DNS rebind at all — rebinding is simply an additional path to the same outcome.
Developers who have not updated to patched MCP SDK versions remain exposed. Version update lag in developer tooling is a documented, persistent problem, and organizations with large developer populations cannot assume all workstations are running current versions of every locally-deployed tool. IoT devices with web-based management interfaces represent a persistently vulnerable class: routers with UPnP enabled can have port forwarding rules configured via DNS rebinding to create persistent inbound access from the internet.
Defenses That Actually Work
Validate Host and Origin headers. This is the single most reliable application-level control. Any locally-running HTTP service should reject requests whose Host header does not match expected local values and whose Origin header is not null or a trusted local origin. This is exactly what the MCP SDK patches implement — it is the correct model for any locally-bound service. Against T1557, it means an attacker who successfully rebinds DNS still cannot invoke authenticated API endpoints because their JavaScript origin is rejected at the transport layer before the request body is parsed.
Use stdio transport for MCP servers where possible. CVE-2025-66414 and CVE-2025-66416 both explicitly state that stdio transport is not affected by these vulnerabilities. For MCP servers where HTTP transport is not required, switching to stdio eliminates the entire attack surface.
Add authentication to local services. Unauthenticated localhost services are a structural vulnerability. Session token models — as implemented by Jupyter notebooks and now by the patched MCP Inspector — provide meaningful protection even against a successful rebind, because the attacker's JavaScript does not have the session token.
Update to patched SDK versions. MCP TypeScript SDK 1.24.0 and MCP Python SDK 1.23.0 both enable DNS rebinding protection by default. MCP Inspector 0.14.1 addresses CVE-2025-49596. Playwright MCP 0.0.40 addresses CVE-2025-9611. Ollama v0.1.29 or later addresses CVE-2024-28224. These are not optional updates for developer machines in enterprise environments.
Do not disable Chrome LNA in enterprise policy. The LocalNetworkAccessAllowedForUrls: ["*"] policy setting restores pre-LNA behavior and eliminates one of the most significant structural browser protections shipped in years. It should not be deployed broadly, even to resolve short-term compatibility issues with internal tooling.
Deploy DNS filtering at the resolver level. Configuring internal DNS resolvers to refuse to resolve external domain names to private IP address ranges prevents a significant subset of rebinding attacks. Palo Alto Networks Unit 42 has documented real-world attacks against internal Hadoop management interfaces reached via developer browsers, and their DNS Security subscription identifies DNS rebinding patterns in real time.
Key Takeaways
- Localhost is not a security boundary. Any HTTP service bound to localhost can be reached by a malicious website via DNS rebinding on most browsers, and via the
0.0.0.0vulnerability on all current browsers. Local does not mean safe. - AI tooling created a new high-value target class. Ollama, MCP servers, and developer tools that expose powerful APIs without authentication are structurally similar to the IoT devices that made 2018's DNS rebinding research alarming — except they carry higher-privilege access to developer machines and internal data.
- Chrome LNA is a real improvement, not a complete solution. It raises the bar meaningfully for attacks via Chrome, but does not protect users on other browsers, does not cover WebSockets or WebRTC, and has a documented bypass via
0.0.0.0that remains unresolved. - The 2025 MCP CVEs share a common root cause: insecure defaults. Services that assumed localhost bindings were inherently safe, and shipped without Host/Origin validation or authentication, created the conditions for exploitation. CVE-2025-66414, CVE-2025-66416, CVE-2025-49596, and CVE-2025-9611 all trace back to the same architectural failure. Secure defaults must be the starting point, not an optional configuration.
- This threat class is still evolving. The Straiker research on MCP-over-SSE rebinding and the Oligo analysis of
0.0.0.0exploitation show that researchers and attackers alike are actively finding new angles. Organizations that treat the patched CVEs as the end of the story rather than a snapshot of an ongoing arms race will remain behind the curve.
DNS rebinding is not back because defenders stopped paying attention. It is back because the software landscape changed. The proliferation of locally-running AI tools, developer infrastructure, and agentic applications has created a target surface that did not exist five years ago. The attack itself has not fundamentally changed since 2007. What changed is what it can reach — and in 2025, that turned out to include the AI tools sitting on virtually every developer machine in the industry.