DNS rebinding and MCP: why nine in ten servers skip the Origin check

Most local services are boring targets. An MCP server is not: it exists to let whoever sends it a request take actions, and it usually holds what those actions need, such as file access, a database connection, or an API token. Local servers also tend to have no authentication, because “only my machine can reach it” feels like enough. DNS rebinding is how a web page breaks that assumption.

Treat this as urgent if your MCP server speaks HTTP (stdio servers are not affected) and any of these is true:

• it runs on a developer’s machine, even “just for testing”;
• it runs inside a company network, a VPC, or a Kubernetes cluster that an employee’s browser can reach;
• it ships inside a desktop application;
• it authenticates users with a browser cookie, where a request from a foreign site is also the classic cross-site request forgery case.

A public server that needs no credentials is at less risk: a rebinding attacker gains nothing that curl could not already do. Fix it anyway. The spec requires the check of every server, it costs a few lines, and code that ships without it to production usually ships without it to the laptop, the staging cluster, and the intranet copy too, which are exactly the places where it is exploitable.

What to do today:

1. Check your server: uvx mcpscore https://your-server/mcp and look for security_origin_validation, or use the one-line curl check below.
2. If it fails, apply the fix for the Python SDK or the TypeScript SDK.
3. Run the check again, and keep it in CI.

The rest of this post explains why the fix works, so you can apply it correctly to your own setup.

An origin is the scheme, host, and port of a page: https://example.com and http://127.0.0.1:8765 are two different origins. Your browser uses origins to keep sites apart, a rule called the same-origin policy. Whenever a page’s script sends a request with a method other than GET, the browser adds an Origin header that names the page. The page cannot change it.

A web page can still send requests to any address your browser can reach, including 127.0.0.1 and the machines on your office network. What stops a script on attacker.example from POSTing JSON to http://127.0.0.1:8765/mcp is that the request crosses origins. The browser first asks the server for permission with a so-called CORS preflight request. An MCP server that does not answer it never receives the real request, and the page can never read an answer.

DNS rebinding removes the cross-origin part. The attacker makes the browser believe that the page and your server are the same origin, and from then on the browser applies no restrictions at all.

DNS is the phone book that turns a name like attacker.example into an IP address. Whoever owns a domain controls its entries, and each answer comes with a time-to-live: how long the browser may remember it. DNS rebinding means the attacker changes their own entry while your browser is on their page.

Say a developer runs an MCP server on their laptop on port 8765, with no authentication, because it only listens locally. The attacker owns attacker.example and its DNS server.

1. The developer opens a page on http://rebind.attacker.example:8765, from a link, an ad, or an embedded frame. DNS resolves the name to the attacker’s web server, with a time-to-live of a few seconds, and the page loads.
2. The page’s script waits for that DNS answer to expire. The attacker’s DNS server now answers the same name with 127.0.0.1, the developer’s own machine.
3. The script sends fetch('/mcp', …). The browser resolves the name again, gets 127.0.0.1, and connects to the developer’s MCP server. The page and the request share an origin, so there is no preflight and the script can read the answer.
4. The script calls tools/list, then tools/call on whatever it finds: read files, query a database, send a message, all with the developer’s local access. Nothing on screen shows it happening.

In step 3 the script needs only the JSON-RPC messages any MCP client sends:

// Runs on http://rebind.attacker.example:8765 after the name rebinds
const res = await fetch('/mcp', {
  method: 'POST',
  headers: {
    'Content-Type': 'application/json',
    Accept: 'application/json, text/event-stream',
  },
  body: JSON.stringify(initializeRequest),
})

The request that arrives carries two headers the server did not expect. That is the whole defence:

POST /mcp HTTP/1.1
Host: rebind.attacker.example:8765
Origin: http://rebind.attacker.example:8765
Content-Type: application/json

The Host header names the attacker’s domain, not 127.0.0.1 or localhost, and the Origin header names the page that sent the request. Rebinding can change which IP address a name resolves to. It cannot change the name the browser puts in those headers. A server that checks either one against a short allowlist refuses the attack.

The MCP Inspector’s local proxy could be driven from a web page to run commands on a developer’s machine, through DNS rebinding among other routes (CVE-2025-49596). DNS rebinding against local services is a well-documented attack class, and developer tooling that listens on a local port is exactly what it targets.

Browsers are closing part of the gap. Since version 142, Chrome asks the user before a public site may reach the local network. That helps, but only in Chromium browsers, only when the user declines the prompt, and not for a page already served from inside the network. The server check is the one you control.

Every revision of the Streamable HTTP transport carries the same security warning. Servers MUST validate the Origin header on all incoming connections to prevent DNS rebinding attacks. Since revision 2025-11-25 the answer to an invalid origin is also fixed: HTTP 403 Forbidden. The same warning says a local server SHOULD bind to 127.0.0.1 rather than 0.0.0.0, and every server SHOULD authenticate its connections. The 2026-07-28 revision keeps the requirement.

The check itself is small. Non-browser MCP clients, such as an IDE, a CLI, or an agent runtime, send no Origin header. So the rule is: no Origin, serve the request; an Origin on your allowlist, serve it; any other Origin, answer 403. Your real clients never notice.

In September we collected every remote MCP endpoint listed in six public directories, 31,503 after de-duplication, and audited each one with mcpscore 1.20.0. 11,548 answered without a login wall and served the harmless control request, so their Origin handling could be judged.

Hosting platforms decide this for all their tenants. The 18 host families with 100 or more endpoints hold 45% of everything we found, and three of them accept a foreign origin on every one of their endpoints. Set those families aside and independent operators still accept it 82% of the time. Servers on the newest, stateless lifecycle do better, and two in three of them still accept it.

mcpscore asks the same question as step 1, with one precaution. It first sends a harmless request with no Origin. Only if the server serves that does it send the twin with Origin: https://mcpscore.invalid, a domain that cannot exist. A server that refuses everyone earns nothing either way, so an access-controlled endpoint cannot pass by accident.

uvx mcpscore 'http://127.0.0.1:8765/mcp'

# Before: the server in the example above
❌ Streamable HTTP does not reject an invalid foreign Origin with HTTP 403, risking DNS rebinding. Observed HTTP status: 200.
  Fix: Validate supplied Origin headers against the origins allowed for this endpoint. Return HTTP 403 for invalid origins; do not allow every origin to satisfy browser requests.
Audit finished. Final score: 122/151

# After: with TransportSecuritySettings
✅ Streamable HTTP rejects an invalid foreign Origin with HTTP 403.
Audit finished. Final score: 125/151

The rule is security_origin_validation, HIGH severity, worth 3 points in the Security & Auth category. It applies to every HTTP server on revision 2025-03-26 or later and never to stdio. For 2025-11-25 and later the refusal must be exactly 403; before that any 4xx passes. The JSON report records what the server answered, so the finding is reproducible and disputable:

{
  "rule_id": "security_origin_validation",
  "severity": "HIGH",
  "passed": false,
  "details": {
    "http_status": 200,
    "control_http_status": 200,
    "expected": { "http_status": 403 }
  }
}

The audit tests Origin, the header the spec names. It does not send a foreign Host, so check that one yourself with the command in step 2. Every rule is in the rules reference.

When a gateway, CDN, or hosting platform sits in front of your server, the same rule can be one edge policy: requests with an Origin outside your list get 403, requests without one pass. That is the fix for the hosting platforms in the numbers above, and it covers every tenant at once.

One trap: CORS is not validation. Access-Control-Allow-Origin tells a browser whether a script may read an answer. It never stops the request from reaching your server. A server that answers every origin with * is still processing every request, including the rebound ones.

• DNS rebinding lets a web page talk to a server on your machine or network as if it were the same site.
• The Host and Origin headers still name the attacker’s site. Checking either against an allowlist stops the attack, and the spec requires the Origin check with a 403.
• Both official SDKs have the fix built in. On a server that listens on 0.0.0.0, pass your hosts and origins.
• Verify with one curl, then keep it verified with mcpscore in CI, where findings can also go to GitHub code scanning.

Check any server in seconds on mcpscore.dev, including the ones your agents already connect to.