MCP's new spec opens three attack surfaces

MCP's July 28 spec swaps session tokens for conversation-visible handles, opening the door to hijacking, per Backslash Security's analysis.

Handles replay across users unless a server validates the handle against its own auth context, the firm found. Most teams don't know how many local-filesystem MCP servers their developers have installed, which decides how exposed they actually are.

The mechanism is blunt. A malicious tool response can inject an attacker-controlled ID, like {"task_id": "t-ATTACKER-CONTROLLED"}, and because the model treats handles as legitimate state, it just obeys. Session hijacking used to mean stealing an opaque server-side token. Handle hijacking just means guessing or copying a string the model already trusts.

Deprecating Roots compounds it. Filesystem boundary enforcement used to live in the protocol itself. Now it's opt-in, left to whatever the individual developer's code decides to check.

MCP Apps, specified in SEP-1865, adds a third surface: server-controlled HTML rendered inside IDE iframes with access to your source and every connected server.

None of this requires a new exploit chain, just a server that skips a validation check. And per the analysis, most orgs haven't audited which servers they're running long enough to know if that check exists.