MCP rug pull attacks
Last updated 7 November 2026
An MCP rug pull is an attack in which something behaves well when you approve it and changes afterwards. The approval is real, but it no longer describes what runs. Two cases are easy to mix up: a server that rewrites a tool description after approval, and a package that changes between releases. Below are the scanner rules that touch each case, and the gap that the scanner has.
What it is
Invariant Labs uses the name rug pull for a server that changes a tool's description after the user has approved the tool. The new description can carry instructions for the model that the old one did not, as described in MCP tool poisoning. Because a client usually asks for approval once, the later change is not shown to anyone.
A related and weaker case is a package. If you install a server or a skill with no exact version, or from a moving reference such as a latest release or a main branch, the next install can fetch code that differs from the code somebody reviewed. This page calls that the package form: unpinned code that can change after review.
# Unpinned: the next run can fetch a different release
npx example-mcp-server
# Pinned to an exact version: the reviewed release is the one that runs
npx example-mcp-server@1.4.2How it works
- A server or package is published in a form that passes review.
- It is approved, installed or added to a client, and the approval is recorded.
- Later the server serves a different description, or a new release replaces the package contents.
- The client or the installer takes the change without asking again, so the reviewed version and the running version differ.
A remote MCP server cannot be pinned to a version at all: the server operator decides what it serves on each request. That is why the useful defence for a remote server is a repeated check, and the useful defence for a package is an exact version.
Sources
Read on 7 November 2026. The first page below is the source of the name.
- Invariant Labs, MCP Security Notification: Tool Poisoning Attacks (1 April 2025) describes MCP rug pulls, and names tool poisoning and tool shadowing as the other two attacks.
- The scanner's own rule pages, linked in the table below, describe what each rule matches.
The OWASP MCP Top 10 entry for tool poisoning does not use the term rug pull, and this page does not credit it with the term.
Rules that touch it
Detects
No scanner rule detects this attack as such.
Partly covers
| Rule | Title | How it relates |
|---|---|---|
| SW-SKL-009 | Unpinned dependency install | An install in a skill's script with no exact version: a later release can differ from the one that was reviewed. |
| SW-SKL-037 | Executable downloaded from a moving reference and run without an integrity check | A download from a moving reference, such as a latest release, that is run without an integrity check. |
| SW-CFG-003 | MCP server launched from an unpinned package | An MCP server launched from a tag, a range or no version, so each start can run different code. |
| SW-CFG-009 | Marketplace plugin source not pinned to a commit | A marketplace plugin that is not pinned to a full commit, so it can change after it was reviewed. |
The four rules in the second table detect the package form: code that can change after review. None of them detects a server that changes a tool description after approval. A rule page may list rug pull (package form) among the names for its check, always with that qualifier.
What no rule covers
No scanner rule detects a server that changes a tool description after approval, because that needs two observations of the same server. What the product has is a re-check, not a rule: the catalog checks remote servers about once a day, and weekly re-probes check the servers added to Spellwarden again.
Read the catalog guide for what the daily re-check of a listed server covers, and the MCP server guide for the weekly re-probes. Both compare a new check with an earlier one in the product; neither is a scanner rule.
What to do
- Pin what you install: an exact version for a package, a full commit for a plugin, a checksum for a download.
- Re-read the tool descriptions of a remote server after every change that you hear about, and on a schedule if you rely on it.
- Run the open-source scanner in CI so that an unpinned install fails a pull request before it reaches a machine.
- See when a public server was last checked in the Spellwarden catalog, and follow How to vet an MCP server or an agent skill before you approve it.