127.0.0.1.evil.com Passes the Allowlist: CVE-2026-102878 Lets Any Website Drive Your Browser Agent

NVD published CVE-2026-102878 on 29 September 2026: an origin validation error (CWE-346) in mcp-chrome-bridge through 1.0.31, the native host component of Chrome MCP Server — a project with 12,456 stars and 1,147 forks that exposes your real, logged-in Chrome browser to AI assistants. VulnCheck, which published the coordinating advisory and credits finder George Chen, scores it 8.6 High on CVSS 4.0; NVD also carries a CVSS 3.1 base of 8.1. The effect, in NVD's words: attackers can craft malicious web pages that make cross-origin requests to the local server and invoke browser automation tools including script execution, page content reading, and screenshot capture. The entire defect is one method call.

One startsWith away from a public API

The upstream code is public and unambiguous. In app/native-server/src/server/index.ts, the bridge registers @fastify/cors with an origin callback that reads, verbatim at tag v1.0.0:

const allowed = SERVER_CONFIG.CORS_ORIGIN.some((pattern) =>
  pattern instanceof RegExp ? pattern.test(origin) : origin.startsWith(pattern),
);

The allowlist is [/^chrome-extension:\/\//, /^moz-extension:\/\//, 'http://127.0.0.1']. The two regular expressions are properly anchored and behave. The string entry is compared with startsWith — a prefix test, not an origin test. Any hostname an attacker registers under a domain they control, such as 127.0.0.1.evil.com, is a syntactically valid DNS name that produces the origin http://127.0.0.1.evil.com, which satisfies startsWith('http://127.0.0.1') while identifying a host that has nothing to do with the loopback interface. The same block sets credentials: true, so the browser attaches credentials to the cross-origin requests it is now permitted to make. The reporter's issue notes the MCP protocol endpoints themselves — /mcp (StreamableHTTPServerTransport) and /sse — are reachable through that bypass, and frames the impact as cross-site WebSocket hijacking.

Notice what this attack does not require. No DNS rebinding infrastructure, no TTL games, no race window — the distinction from Google MCP Toolbox's rebinding flaw and the MCP Java SDK's. An attacker registers a subdomain whose label happens to start with the allowlisted prefix, points it anywhere, and serves a page. Per the CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H), the only cost is passive user interaction: the victim visits a page while the bridge is running.

Why this is worse on a browser agent than on an ordinary local service

Local-service CORS bugs are usually bounded by what the service does. Here, the service is your browsing identity. Chrome MCP Server's stated purpose is to expose your existing Chrome instance — sessions, cookies, logged-in tabs — to an AI assistant so it can automate real work. An attacker who can invoke those tools does not need to steal a credential, phish a password, or bypass MFA; they operate the already-authenticated browser and read what it renders. Script execution lets them run in page context; page content reading and screenshot capture exfiltrate whatever is on screen in any open tab. Corporate mail, cloud consoles, internal dashboards — all rendered post-authentication.

That is the same collapse we documented when one extension hijacked the AI inside five browsers with no prompt injection required, and the mechanism echoes Cline Kanban's cross-origin WebSocket hijack and Oasis Security's ClawJacked takeover. The recurring lesson is that localhost has never been a security boundary for a browser, and an allowlist enforced with string prefixes is not even an attempt at one.

The timeline is the story

The GitHub issue — #384, "CORS origin bypass in native-server HTTP API allows any website to drive the MCP server (CSWSH)" — was filed 4 September 2026, reporting the flaw confirmed on main at commit 139f838, with proof-of-concept withheld and offered on request. As of this writing the issue is still open, and the vulnerable line is present in the published v1.0.0 source that NVD references. The npm registry's latest tag for mcp-chrome-bridge remains 1.0.31, published 30 December 2025 — the version the CVE names as affected. The repository's most recent commits are from 6 January 2026 and are documentation and feature work, not a fix. Responsible reporting, a CVE, a vendor advisory from VulnCheck, and 25 days of public disclosure have not yet produced a patched release. We found no evidence of in-the-wild exploitation, and the flaw is not in CISA KEV — but the bypass is a single DNS registration away from weaponised, and the fix (anchor the check, or drop the string entry for a proper origin comparison) is one line.

What to do today

  • Stop the native host when you are not actively using it. The attack requires the local server to be listening. For a tool used in bursts, "running only during agent sessions" removes the exposure window entirely and costs nothing.
  • Assume every open tab is readable while the bridge runs. Do not keep a Chrome MCP session alive alongside cloud consoles, password managers, mail, or internal dashboards. Use a separate browser profile — ideally a separate OS user — for agent-driven browsing.
  • Audit your own local MCP servers for prefix-based origin checks. Grep for startsWith, includes, and unanchored regex against Origin or Host. Correct validation is an exact match on the full serialised origin, and credentials: true should force a second look at whatever gate precedes it.
  • Treat 127.0.0.1 and localhost as attacker-reachable names, not locations. They are DNS labels an attacker can prefix, suffix, or resolve at will. Bind local agent services to loopback and require a per-session bearer token the page cannot guess.
  • Track the issue, not the version number. With no patched release published, "update to latest" is not remediation here — npm's latest is the affected version. Watch issue #384 and verify the origin callback in the shipped code before declaring yourself fixed.

Sources: