DEV Community

Custodia-Admin
Custodia-Admin

Posted on • Originally published at pagebolt.dev

The DNS rebinding vulnerability in self-hosted browser MCPs (and why hosted matters)

The DNS Rebinding Vulnerability in Self-Hosted Browser MCPs (and Why Hosted Matters)

A DNS rebinding attack isn't new — but its application to local MCP servers is getting attention this week, and it's worth understanding concretely.

How the attack works

Self-hosted browser MCPs (Playwright MCP, Puppeteer-based servers, browser automation tools run locally) bind to localhost — typically 127.0.0.1 on a port like 3000 or 8080. They expect that only local processes can reach them.

DNS rebinding breaks that assumption. The attack sequence:

  1. A user visits a malicious website while their local MCP server is running
  2. The site's DNS initially resolves to the attacker's server (normal)
  3. After the browser caches the IP, the attacker drops the TTL to zero and rebinds the DNS to 127.0.0.1
  4. The browser's same-origin policy now treats the malicious site as same-origin with localhost
  5. JavaScript on the page makes requests to localhost:3000 — which is your MCP server
  6. The attacker now has access to every MCP tool your server exposes: browser navigation, file reads, command execution, anything

The impact depends entirely on what tools the local MCP server exposes. For a browser automation MCP with filesystem access, the exposure is significant.

Why self-hosted MCPs are specifically vulnerable

Standard web servers on localhost carry this risk, but most don't expose sensitive tooling. A browser automation MCP is different: it's designed to control a browser, navigate to URLs, interact with page content, and often read or write local files. That's a high-value target.

The attack doesn't require user interaction beyond visiting the malicious page. No phishing, no file downloads. A single visit while the MCP server is running is enough.

The hosted model eliminates the attack surface

A hosted MCP server like PageBolt has no localhost binding. The browser runs on remote infrastructure — there's no process on the user's machine to reach via DNS rebinding.

{
  "mcpServers": {
    "pagebolt": {
      "command": "npx",
      "args": ["-y", "pagebolt-mcp"],
      "env": { "PAGEBOLT_API_KEY": "YOUR_KEY" }
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

pagebolt-mcp is an MCP server that makes outbound API calls to PageBolt's infrastructure. It doesn't bind to any local port. There's no localhost surface for DNS rebinding to reach. The attack vector doesn't exist.

Mitigations for self-hosted setups

If you're running a self-hosted browser MCP and need to keep it:

  • Bind to a non-standard port with a random high number (reduces guessability, doesn't eliminate the attack)
  • Use a Host header check to reject requests that don't match your expected hostname
  • Shut down the MCP server when not actively using it
  • Run in a Docker container with network isolation

These reduce the risk but don't eliminate it. The architectural fix is moving the browser off the user's machine entirely.


Try it free — 100 requests/month, no credit card. → pagebolt.dev

Top comments (0)