MCP Security Intelligence · Attack-path research

Cross-MCP attacks: the dangerous path between individually ordinary tools

An MCP that reads sensitive data and an MCP that transmits or executes can form an attack path neither repository contains. This report explains the composition boundary, the exact evidence required, and the three paths our analysis engine currently detects.

Living methodology · Production catalog: 71,565 canonical MCP implementations · Updated with the catalog

What is a cross-MCP attack?

A cross-MCP attack uses authority exposed by tools from two or more MCP servers in the same agent environment. One tool is the source: it obtains data or attacker-controlled content. Another is the sink: it sends information outside the trust boundary or executes code.

The installed combination is the unit of analysis. Public catalog evidence can identify possible capability compositions. Actual organizational exposure requires the exact enabled versions, permissions, credentials, and shared agent context.

Three attack paths detected by the current engine

Sensitive-data exfiltrationHIGH · POTENTIAL CHAIN
Source primitiveFiles, source code, secrets, credentials
→
Sink primitiveHTTP, webhook, email, message, upload

Required condition: an agent or user passes source-tool output into the egress tool.

Browser-session exfiltrationCRITICAL · POTENTIAL CHAIN
Source primitiveCookies, browser sessions, local storage
→
Sink primitiveExternal network destination

Required condition: the browser tool exposes session material and it is passed to the sink.

Untrusted content to code executionHIGH · POTENTIAL CHAIN
Source primitiveFetch, scrape, crawl, web search
→
Sink primitiveShell, command, script, code execution

Required condition: attacker-controlled content influences the command or code passed to the execution tool.

How MCP Security identifies a path

  1. Resolve every installed MCP to an exact package version or source coordinate.
  2. Use the latest successful protocol observation for that exact version.
  3. Classify tool interfaces into disclosed security primitives.
  4. Compare tools across different MCP implementations using bounded source-to-sink rules.
  5. Return the exact MCP, tool, primitive, confidence, explanation, and precondition.

What a potential chain does not prove

A capability chain is not proof that either MCP is individually vulnerable, that an exploit occurred, or that the agent has the necessary permissions. Severity describes the consequence if the stated precondition is satisfied. This distinction prevents capability metadata from being turned into unsupported vulnerability claims.

Why this creates a new security boundary

Repository scanners, package scanners, and single-server runtime tests cannot see tools installed by another team or used in the same agent session. Security policy must therefore evaluate changes to the complete MCP inventory, not only changes inside one repository.

Continue the investigation

Explore the broader MCP market, publisher, capability, remote infrastructure, and verification research in the Intelligence Center.

Open the MCP Intelligence Center

Let’s talk about MCP security.

Share your details and our security team will contact you.