MCP Inspector retained an RPC tool bridge after untrusted iframe navigation

An MCP Inspector App inside a srcdoc iframe could navigate its child frame to an attacker origin while the parent still trusted its persistent contentWindow reference for JSON-RPC.

GHSA-h9j8-vj8g-v3gg demonstrated that wildcard postMessage bridging exposed replies and forwarded tool-call requests to the replacement document. The advisory identifies 2.14.0 as the fix; it does not prove deployed-tool misuse.

The browser frame remained the same Window object even after its document moved to a different origin. MCP Inspector's parent used that stable object reference as a proxy for trusted application identity, and wildcard postMessage forwarding did not rebind authority after navigation. An untrusted App could therefore replace its document while retaining access to an established JSON-RPC bridge for responses and tool requests. The researchers demonstrated the messaging path, not a confirmed compromise of a production MCP tool. Inspector 2.14.0 is cited as the fix. The durable lesson is that a frame's continuity does not establish the identity of the code currently running inside it.

A navigation can replace the content of a child frame without necessarily changing the window handle held by its parent. The Inspector's bridge was therefore still able to address a hostile replacement document through the same contentWindow object. Testing only iframe sandbox attributes misses this identity-lifetime problem. An effective fix must bind messages and tool permissions to the current, expected document origin and revoke them on navigation; the advisory does not establish production exfiltration from a real user's MCP tools.