How MCP Server Rug Pulls Work

The MCP rug pull is not primarily a hacking story. It is a story about what happens when an organization delegates authority to a system it cannot observe, and that delegation turns out to be permanent by default. The attack exploits a gap between the moment of approval and every subsequent moment of execution. Closing that gap is a governance problem first, and a security engineering problem second.

What a rug Pull Is and How It Differs from Other MCP Attacks

Anthropic open-sourced the Model Context Protocol in late 2024 as a universal interface for connecting large language models to external tools, data sources, and services. The core mechanism is straightforward: MCP clients read structured tool definitions from servers at runtime. Those definitions tell the model what a tool is, what it does, and when to invoke it. In a conventional REST API, documentation describes behavior and the code enforces it separately. In MCP, the tool description is the executable context. It loads directly into the model's reasoning before any call is made. Whoever controls the description controls what the model does next.

That architectural reality is what makes the rug pull possible and what distinguishes it from every other class of MCP attack.

A prompt injection attacks the model's reasoning through adversarial input. A tool poisoning attack plants a malicious tool at install time. A rug pull does something structurally different: it earns trust first, then exploits it later. The tool was approved. The agent accepted it. The workflow was built around it. Then, after all that trust was established, the description or behavior silently changed — like a business partner who smiles through every meeting until the contract is signed.

The protocol never signals that re-evaluation is needed. The agent never re-evaluates. The approval record stays intact while the underlying reality shifts.

This is classified as OWASP MCP03 in the 2025 OWASP MCP Top 10, and in vendor threat matrices it appears under the label "bait-and-switch." Researcher Nasser Ali Alzahrani put it plainly: "Your AI agent's tools can change after you approve them, without triggering any notification or re-consent. The MCP spec allows this by design." Cequence Security CISO Randolph Barr classifies it as a new category of AI supply chain attack because trust is the mechanism being exploited, not a code vulnerability in any conventional sense. There is no buffer overflow here, no SQL injection, no credential stuffing. The vulnerability is the institution of trust itself, operating in an environment where that trust cannot be audited in real time.

How the Protocol's Own Update Machinery Enables the Switch

The update path is not a loophole. It is a documented feature. MCP servers that declare the listChanged capability can emit notifications/tools/list_changed. The client re-fetches tools/list and gets whatever definitions the server now returns. The specification mandates no re-approval on that re-fetch. No version pinning. No content hash verification on the updated definitions.

Trust is bound to the tool's name, not its content. A server returning a fundamentally different description under the same name passes silently.

This hides inside the ordinary mechanics of software maintenance. Package managers like npm, pip, and Cargo auto-update by default. Tool descriptions are plain text, so a malicious change is a single added line in a docstring, with no compiled binary to trigger static analysis. Most practitioners do not audit changelogs for every dependency patch, because historically they haven't needed to. A changelog note saying "improved tool descriptions" is invisible as a threat signal — you might as well label a knife "improved cutlery."

The mutability of server-side logic is the structural vulnerability. The server's code and behavior can change with no notification to the client and no re-verification required. The client was designed to trust the server, and that trust has no expiration date.

The Four-Phase Attack Sequence a Rug Pull Follows

The sequence is clean enough to teach, and that should concern anyone responsible for agentic deployments.

Phase one is trust establishment. The attacker publishes a genuinely useful server with clean code and benign tool descriptions. Users install it. Agents approve it. It becomes part of the daily workflow.

Phase two is agent approval. The agent calls tools/list, reviews the metadata, and stores an approved record. What gets remembered is the tool name.

Phase three is dormancy. The server runs cleanly for days or weeks, long enough to clear any post-install scrutiny and become a taken-for-granted component of the stack. This is not accidental; the dormancy period is the attack's most important feature. It separates cause from effect in time, making attribution hard. Think of it as a sleeper agent embedded in your kitchen — perfectly helpful every morning until the day it isn't.

Phase four is the swap. The server pushes an update. Most clients accept the new definition without re-prompting because the tool name has not changed. That same endpoint now posts to a third-party service, BCC's outbound communications, injects prompts into subsequent model calls, or spawns a reverse shell. The agent's behavior changes. Its approval record does not.

What the attacker gains is persistent, trusted access to everything the agent can reach, without appearing in the interaction log as an untrusted actor. The attacker's name never shows up. Only the trusted tool's name does.

Three Variants the Attack Takes in Practice

The MCP-38 threat taxonomy, documented in arXiv:2603.18063, classifies rug pull attacks into three variants that share one enabling condition but differ in mechanism.

The first is the post-audit description swap. The server passes a security review with benign descriptions, then silently replaces them with poisoned versions. This is the most common form. The tool still answers to the same name, takes the same inputs, and returns plausible outputs. Only what happens in between has changed.

The second is endpoint redirection. The server's runtime endpoint changes from a trusted domain to an attacker-controlled server. The tool description remains completely accurate; the destination is what moves. From the client's perspective, everything looks right up until the traffic hits the wrong server.

The third is implementation backdooring. Server code is updated to include backdoors while the tool interface and descriptions remain unchanged. This is the hardest variant to detect precisely because the description the agent reads is still honest. The dishonesty lives in the execution layer, below what any description-level inspection can see.

All three variants exploit the same gap: the client has no mechanism to compare current behavior against what was approved at install time.

CVE-2025-54136: How the Cursor Vulnerability Made the Attack Concrete

Until a vulnerability gets a CVE number and a CVSS score, it is easy to treat as theoretical. CVE-2025-54136 changed that.

Tracked with a CVSS score of 7.2 and codenamed MCPoison by Check Point Research, the vulnerability exposed a fundamental architectural assumption in Cursor's trust model. Cursor bound trust exclusively to the MCP key name in .cursor/rules/mcp.json, not to the underlying command or arguments. The name was the identity. Whatever the name said was trusted.

The attack sequence was almost elegant in its simplicity. An attacker commits a benign MCP configuration to a shared repository. A developer opens the project in Cursor, sees an innocuous command, and approves it. The attacker later modifies the same configuration entry to execute arbitrary system commands: reverse shells, data exfiltration, persistent backdoors. Those modifications execute silently on every subsequent project open, with no re-prompt.

At the time of disclosure, Cursor had over a million users and was in active use at more than half of the Fortune 500, including NVIDIA, Uber, and Adobe. Check Point reported the vulnerability to Anysphere on July 16, 2025. A fix shipped in Cursor 1.3 on July 29. Research was published August 5.

The fix is instructive: re-approval on any configuration change, including adding a single space. That is what a protocol-level control looks like when an implementer actually applies one. It is friction in the right place.

Four named CVEs appeared in the MCP layer in 2025 alone. That is not a run of bad luck. That is a vulnerability class announcing itself.

The Postmark Incident: What a Near-Miss Supply Chain Rug Pull Looks Like Operationally

In September 2025, Koi Security disclosed a backdoor in the Postmark MCP server, distributed under the official Postmark namespace. The malicious logic silently BCC'd every outbound email processed by the server to an address controlled by the maintainer.

Anyone who had connected that server to Claude or Cursor and used it to draft sensitive correspondence had been quietly leaking that content for weeks before disclosure. The blast radius was not just emails explicitly sent. It was drafts, context passed to the model, anything the agent surfaced while composing. Every conversation those agents had touched was potentially in scope.

What makes this the clearest enterprise analogy is what was absent. There was no exploit code. No zero-day. No intrusion in the conventional sense. Just a behavior change in a trusted, named package distributed through official channels. Victims had no way to know without an independent audit of outbound traffic. The server continued to function correctly from the user's perspective, which is precisely what made it dangerous.

The Postmark incident is what a supply chain rug pull looks like when it runs undetected. You don't know it happened until someone outside your organization tells you — like finding out your house was robbed only because your neighbor mentions they watched someone walk out your front door.

How a Rug-Pulled Server Can Compromise Tools the Agent Never Called Through It

Multi-server environments are standard in production agentic deployments. An agent in a real workflow calls a database tool, a calendar tool, a communications tool, and a code-execution tool within a single session. The assumption that a compromised server is a contained risk is incorrect.

A rug-pulled server can inject instructions into the agent's reasoning that affect how it behaves toward other connected servers. This takes several forms. Credential hijacking: credentials surfaced by one trusted server are secretly passed to an attacker-controlled endpoint through instructions the malicious server placed in the model's context. Rule override: the malicious server's injected instructions supersede safety or access policies set by other, legitimate servers. Exfiltration via trusted channels: the agent is instructed to use an approved, legitimate tool to send data somewhere it should not, and the audit trail shows only trusted tool calls.

The attacker never needs to appear in the user-facing interaction log. Only trusted tool names show up there. The malicious server's influence is in the instructions the model followed, not the tools it invoked.

This is why a single ungoverned server in a multi-server deployment is not a contained risk. It is a pivot point.

Why Approval Dialogs and One-Time Consent Don't Stop This

Approval dialogs fail at two structural points, and both failures are architectural rather than implementational.

The first failure is timing. The payload is already in the model's context before the invocation the dialog is guarding. The gate sees the tool name, not the current description.

The second failure is rendering. In Invariant Labs' April 2025 proof-of-concept in Cursor, the confirmation UI didn't render the full tool input. The injected instruction and the exfiltrated key were hidden at approval time. The user approved what appeared to be a safe action and had no visibility into what was actually being authorized.

One-time consent is the deepest structural problem. Consent was given to a description that no longer exists. The agent has no mechanism to notice the discrepancy because it fetches current definitions at runtime without comparing them to what was approved. The approval is a snapshot. The tool is a living, mutable entity.

The browser extension analogy is apt here: a benign extension approved at install, later updated with malicious functionality. Bitdefender analysts draw that comparison explicitly. The MCP version is harder to catch because the change is a text string, not a compiled artifact. There is no binary diff to flag. There is no signature that breaks. There is just a different sentence in a docstring.

Approval is a point-in-time control applied to a continuously mutable surface. It is necessary. It is not sufficient.

The Empirical Scope of Vulnerable MCP Servers Already in Circulation

The population of potentially vulnerable servers is not hypothetical.

A study of 1,899 open-source MCP servers found that 7.2% contained general security vulnerabilities and 5.5% exhibited MCP-specific attack vectors including tool poisoning. A separate systematic analysis of more than 1,800 deployed servers (arXiv:2508.12538) found that more than a third had at least one exploitable vulnerability. The common underlying conditions across both studies were inadequate input sanitization, absent authentication mechanisms, and insufficient access controls.

What these figures mean practically: an organization deploying even a modest number of community or third-party MCP servers is statistically likely to have at least one with a known vulnerability class. The rug pull does not require the server to be broken at install. It requires only that the server be trusted and mutable. That describes nearly all of them.

As of spring 2026, no publicly confirmed in-the-wild rug pull with named victims had been documented. The attack is a demonstrated, formally recognized threat class, not yet a breach pattern. That gap is the cheapest possible moment to deploy a detection control. Once there is a named victim, that window closes.

Why This Is a Governance Failure Before It Is a Security Incident

The attack works because organizations typically authorize a tool once and then retain no ongoing record of what that tool's description actually said when the agent invoked it. That is not a security engineering failure. That is a governance failure.

An audit log that records tool names but not tool descriptions at call time is a postmortem document, not a detection control. It tells you what was invoked, not what the agent was actually instructed to do. The gap between those two things is where the rug pull lives.

The governance failure has three dimensions. First, no registry: organizations often cannot enumerate all MCP servers connected to their agents, let alone their current descriptions. Second, no versioning: there is typically no record of what a tool's description said at the moment of the last approval versus what it says now. Third, no real-time signal: changes propagate silently, and the first indication of a rug pull is usually an anomalous downstream event, not a detection in the MCP layer.

The MCP-38 taxonomy identified 57 distinct threats across five ecosystem components. The rug pull sits at the intersection of server mutability and client trust, which is precisely where governance controls live, not security controls. You cannot patch your way out of this with a firewall rule. The solution is knowing, in real time, what your agents are touching and whether what they are touching today is the same thing you authorized last week.

An MCP attack surface discovered after deployment is a governance failure. The organization did not lose control in the moment of the attack. It lost control the moment it granted trust without a mechanism to verify that trust was still warranted. Every day that gap stays open is a day the rug pull is free to run.