Lateral Movement via Compromised MCP Servers

A compromised MCP server doesn't stay compromised on its own. It becomes a pivot point, because the same broad, trusted access that makes MCP servers useful in the first place also makes them the ideal launch pad for reaching across systems, credentials, and data stores. Anthropic introduced the Model Context Protocol in late 2024 to give AI agents one structured way to reach file systems, databases, APIs, code repos, and enterprise SaaS tools. One interface, many integrations, wide reach for the agent: that's the pitch.

The architecture behind that pitch fits in a sentence. Host applications spawn clients, clients hold live sessions with servers, and servers expose three kinds of capability: tools you can run, resources you can read, and prompts you can reuse. A single server routinely holds credentials for several downstream systems at once, and that's the whole point of the design. It's also the whole problem: once that one server gets turned, every system it touched becomes reachable too.

The agent trusts the server, and the agent acts on its own, with no human clicking "approve" between the moment a server issues an instruction and the moment that instruction runs against a downstream system. An MCP server is a go-between holding keys to a dozen rooms, and that's exactly the starting position an attacker wants. It's the reason this piece treats lateral movement as the default outcome of a breach, not a worst-case edge scenario.

How authentication was left optional — and what that gap looks like at scale

MCP's own authorization spec lays out an OAuth 2.1 framework, then marks it optional. The expectation on paper is that developers bolt on their own protections, and that expectation goes unmet more often than not. Optional security, in practice, means no security for a large share of what's running today.

A lot of deployments still lean on static API keys instead of proper OAuth flows. Static keys don't expire on their own, they don't scope cleanly, and they don't revoke well across the pile of services a single server aggregates. This rhymes with past OAuth abuse incidents, where a single credential flaw has let attackers walk across multiple trust boundaries that were never supposed to touch.

The scale is worth sitting with. A July 2025 internet scan turned up at least 1,862 publicly reachable MCP instances answering unauthenticated requests. By April 2026, Trend Micro put that number at 1,467, still well over a thousand, and that's just what's facing the open internet. A server sitting behind a corporate firewall isn't safe by virtue of being hidden; a malicious insider, or an attacker who's already found a foothold through some other door, can hit an unauthenticated internal MCP server and use it to pivot right back out.

Then there's the supply chain angle, and this is the part that should worry people most. A systemic flaw disclosed in April 2026 by OX Security reportedly touches around 200,000 vulnerable instances, sitting inside a supply chain with more than 150 million package downloads, according to CSA's research note. That's a crack running under a huge chunk of the whole ecosystem.

The CVE record so far — what confirmed vulnerabilities reveal about the attack surface

The disclosure pace tells its own story. Between January and February 2026 alone, more than 30 CVEs were filed against MCP servers, clients, and related tooling. As of May 2026, at least seven confirmed high- or critical-severity CVEs span major MCP-integrated platforms, spanning major MCP-integrated platforms, per CSA's research note.

Two of those are worth walking through, because together they show how wide the surface really is. CVE-2025-6514 hit mcp-remote, versions 0.0.5 through 0.1.15, with a CVSS score of 9.6. It's an OS command injection bug, and with more than 437,000 downloads on that package, It represents a confirmed case of remote code execution through a malicious MCP server. The mechanism is almost blunt in its simplicity: a rogue server supplies a crafted response, the client processes it without adequate validation, and the attacker walks away with code execution under the user's own privileges.

CVE-2025-49596 hit MCP Inspector, CVSS 9.4, and let unauthenticated instances run arbitrary commands. Inspector is a standard developer diagnostic tool, so this exposure sat inside development and staging environments, often well before anything reached production. Put the two side by side and the pattern is plain: the risk spans both client-side and tooling layers at once, and no layer gets to call itself the safe one.

There's an unresolved issue sitting underneath all of this, and it's the one that should bother people the most. In April 2026, researchers reported a shared design flaw surfacing across multiple platforms, a single root cause manifesting in different codebases. The flaw was treated as a protocol-level design choice rather than a defect to be corrected. Some vendors patched at the application layer to compensate, but the underlying exposure remained in the reference implementation, a situation worth calling out directly.

How cross-server tool shadowing turns one compromised server into a session-wide infection

Picture a multi-server MCP deployment. By default, MCP doesn't wall servers off from each other, so a malicious tool sitting on one server can plant hidden instructions that stick around in the model's working context. The malicious server never has to touch the trusted one directly.

Here's the sequence. The bad server slips instructions in during its own tool interaction, and those instructions sit inside the model's context window, waiting. Later, the user calls a completely different, legitimate tool on a trusted server, and the LLM follows the planted instructions instead of the trusted tool's actual intended behavior. The malicious server corrupts the agent's judgment, and lets the agent do the reaching for it.

What that buys an attacker is substantial. Credentials meant for one server get silently handed to another, rules set by a trusted server get overridden by whatever got planted earlier in the session, and data walks out the door through a real, trusted tool call, one that looks completely legitimate on the surface, because it is the legitimate tool, just aimed at the attacker's goal instead of the user's.

Cross-server tool shadowing stretches the blast radius of one compromised server across every tool the agent can touch in that session. The weakest server in a deployment sets the security ceiling for the whole session, not the strongest one, and that's the fact most teams get backwards when they audit their "best" servers and call it done. Add ten well-secured servers and one sloppy one, and the sloppy one decides how bad things can get.

Rug pulls and tool poisoning — how the attack surface reaches back through the supply chain

Prompt injection and tool poisoning get lumped together sometimes, but they're not the same attack. Prompt injection targets the conversation itself, while tool poisoning corrupts the tool registry, baking a malicious instruction into a tool's description before the agent ever calls it.

The rug pull version works in stages. An attacker submits a benign-looking MCP configuration to a shared repository, and a developer reviews it, approves it, and moves on. Later, quietly, the attacker swaps the tool definition for a malicious one, and nothing re-triggers approval. CVE-2025-54136, nicknamed "MCPoison" and disclosed by Check Point Research against Cursor IDE, is exactly this pattern in the wild. Any credential the Cursor process could reach, API keys, cloud credentials, repository tokens, sat within range of a successful exploit.

Rug pulls break the normal supply chain security model because the payload lives inside a runtime API response, specifically the tools/list call, and there's nothing sitting at rest for a static scanner to catch. Once poisoned, a tool stays poisoned for every session that calls it afterward; cleaning up one bad session does nothing, since the tool itself keeps serving the malicious definition on the next call.

The numbers on model susceptibility deserve a second look, because they cut against the usual assumption that better models mean safer models. A benchmark study by Wang et al. in 2025, called MCPTox, ran 1,312 tool-poisoning cases across 45 real MCP servers and found that more capable models were often more susceptible, with refusal rates under 3%. Attack success rates cleared 60% across testing, and the best-performing model in the study hit 72.8%. The model is doing exactly what it's built to do, following instructions well, and that strength is precisely what the attack exploits.

Compromised session credentials and OAuth abuse as a lateral movement bridge

OAuth flows, meant to be a security feature, turn into a pivot point under the right conditions. CVE-2025-6514 shows one version of this: an OS command injection flaw in the OAuth flow allows a malicious server to trigger full code execution on the client side. Persistence, credential theft, and malware installs all follow from that single exchange.

Related session-hijacking vulnerabilities in MCP tooling work differently but land in the same place, letting an attacker operate inside an already-established, already-authenticated context without needing to authenticate independently at all.

Underneath both of these sits a confused-deputy problem. The MCP server acts on behalf of the agent, the agent acts on behalf of the user, and an attacker who controls the server can issue instructions that downstream systems accept as legitimate, simply because they arrived through a channel that's supposed to be trusted. Static API keys make this worse. Keys aggregated across many services don't expire or scope on their own, so stealing one key can unlock several systems at once, since the credential and the access it grants sit right next to each other on the same server.

Multi-tenant token isolation failures show how this plays out even without an outside attacker in the picture, where a session credential meant for one customer's data ends up reaching another's entirely. That points at something bigger than MCP itself: the credentials sitting on a compromised MCP server usually authenticate into systems that have nothing to do with AI at all, cloud infrastructure, code repos, SaaS platforms. The lateral movement doesn't stay inside the AI stack; it walks straight out of it.

Three incidents that show what lateral movement from a compromised MCP server looks like in practice

Smithery.ai's registry compromise in June 2025 started with something almost mundane: a path traversal bug in the dockerBuildPath parameter, a configuration flaw rather than anything exotic. That traversal exposed files holding overprivileged administrative credentials, and those credentials opened up Fly.io's machine API, which allowed arbitrary code execution across more than 3,000 hosted MCP servers on the platform. API keys and secrets belonging to potentially thousands of customers, spread across hundreds of downstream services, sat within reach. The flaw was reported and Smithery rotated the token and patched within days. The access existed the whole time the misconfiguration was in place. One misconfiguration, one key, and the path to everything the platform touched was wide open.

A subsequent incident brought a documented malicious MCP package caught in the wild. It ran undetected for an extended period, exfiltrating data the entire time, and that detection lag is the number worth remembering. Without real-time visibility into what an agent is actually doing with its access, detection lag gets measured in weeks, not hours. The package arrived through a standard distribution channel, offering little at install time to distinguish it from a legitimate integration.

Then there's the April 2026 STDIO flaw, which is really a platform-level failure rather than a single-vendor bug. The same core issue turned up independently across multiple major platforms. The underlying exposure persisted in the reference implementation even as several vendors patched at their own application layer. For any enterprise running these tools, that's the real takeaway: protocol-level vulnerabilities don't wait around for one central fix. Each deployment inherits the risk on its own, until either the vendor patches or the organization builds its own control layer on top.

What defenses actually need to address in MCP-specific lateral movement

Start with inventory, because nothing else works without it. Lateral movement through an unregistered MCP server is the predictable result of running a server nobody's tracking, and a central registry of every server in use is the precondition for every other control that follows. You can't enforce policy on something you don't know exists, and every server added without a registry entry is an identity gap, exactly the kind attackers go looking for.

Credentials need to change next, and this is where most teams are still stuck in 2023 thinking. Static API keys sitting on a server that aggregates access to a dozen systems are a single point of failure in practice, not just on a whiteboard somewhere. Swap them for short-lived, scoped credentials wherever possible, and push authentication enforcement to the gateway layer instead of trusting each individual server implementation to get it right. The CVE record makes clear they often don't.

Session isolation matters just as much. Cross-server tool shadowing only works because MCP deployments treat every server's context as safe by default, and that assumption needs to flip. Treat each server's context as potentially hostile to its neighbors, with isolation enforced at the infrastructure level rather than assumed from the protocol spec. Agents working across multiple servers need real boundaries on what one server's output is allowed to tell the agent to do with a different server's tools.

Tool definitions need the same skepticism. Rug pulls succeed because tool definitions get trusted at runtime with no re-check step. Treat tools/list responses as untrusted input, the same way you'd treat any other untrusted payload, not as settled configuration. Static analysis won't catch a runtime swap; verification has to happen at the moment of execution, every time, not once at review.

Underneath all of it sits the one control that actually decides how a breach ends: real-time visibility into what agents are accessing, not a post-incident log pulled together after the damage is done. The Smithery flaw got caught in two days, while the malicious package from September 2025 ran for two weeks before anyone noticed. That gap, between catching something as it happens and finding it after the fact, is the entire difference between an incident and a disaster.