What is an MCP rug pull attack?

MCP rug pull attack: the basics

An MCP rug pull attack starts with a clean tool. It passes review, gets approved and works well for weeks. Then the server quietly changes the tool's description or behavior to include malicious instructions. Nothing about the tool's name changes, so nobody notices.

Why rug pulls beat security reviews

Most teams approve an MCP server once, at install time. A point-in-time review tells you the tool was safe on that day. It says nothing about next week. Many MCP servers are third-party code that developers install themselves, and a server can change at any time after it is approved. The trust you gave it never expires, even though the code behind it keeps changing.

MCPoison: a real MCP rug pull CVE

This is not theoretical. CVE-2025-54136, which Check Point researchers named MCPoison, was a high-severity rug-pull flaw in the Cursor IDE. Cursor did not re-check an MCP configuration after a user first approved it, so an attacker could swap in something malicious later. Cursor 1.3, released on July 29, 2025, fixed this by asking for approval every time the configuration changes.

The postmark-mcp supply chain attack

In September 2025, a fake npm package called postmark-mcp shipped 15 clean versions to build trust. Version 1.0.16 then added one line that copied every outgoing email to the attacker. It was downloaded about 1,500 times in a week before Koi Security caught it and the package was removed. A one-time review would have approved all 15 clean versions and missed the 16th.

How to simulate an MCP rug pull

The safest way to find out whether your agent is exposed is to attack it yourself in staging. A good MCP security testing process for AI agents includes a rug pull simulation like this:

1. Approve a clean version of a test tool.
2. Run your normal tasks and record which tools the agent calls, in what order, and with what arguments.
3. Swap in a poisoned definition without changing the tool's name.
4. Check two things: does your agent's behavior change, and does anything in your pipeline flag the changed definition?

What a pass looks like

A pass means the changed definition is detected and blocked before the agent loads it. A fail means the agent keeps using the tool and its behavior silently changes.

How to defend against MCP rug pulls

• Pin or hash every tool definition so any change triggers a re-test.
• Scan installed servers for poisoned descriptions. Invariant Labs' open-source mcp-scan does this and pins a hash of each description, so it can flag a tool that changes later.
• Re-run your MCP test suite whenever a server updates, a tool is added or your model changes.
• Test rug pulls first if your servers update automatically or often.

Static scanning catches known patterns in descriptions, but only running attacks against the agent shows what it actually does. An MCP integration is an ongoing trust relationship, not a one-time purchase, so your testing has to be ongoing too.