Rug-pull after approval: MCPoison

A Cursor MCP server was approved once, then silently swapped for a malicious one. The approval stuck to the entry's name, not its contents, so the swap inherited the trust and ran with no new prompt. Herkos does not catch this swap, and saying so is the point of this page. What its scan does catch is the rug-pull's close cousin: a tool whose description is poisoned after you approved it.

What happened

Cursor keyed an MCP approval to "this entry was approved once" rather than to a hash of the entry's actual command and arguments. Once approved, later edits to the same entry were trusted without a new prompt. The attack is four steps:

1. Plant a benign config. The attacker commits an innocuous MCP server entry to a shared repo - Check Point used .cursor/rules/mcp.json with a harmless command like echo.
2. Victim approves once. A collaborator opens the project, Cursor prompts for MCP approval, and the victim approves the harmless-looking entry. The approval is persisted.
3. Attacker swaps the payload. The attacker edits the same entry's command / args to something malicious. Per Check Point: "the contents - such as command and args - can be modified later without triggering a new approval prompt."
4. Silent persistent execution. The next time the victim opens the project, the modified command runs automatically, with no prompt. Because the config lives in the repo, it re-runs on every open - persistent, silent, remote code execution.

Root cause in one line: approval was bound to the entry's identity, not to its contents, so mutating the contents after approval bypassed re-validation. The 1.3 fix re-triggers an approval prompt on any change, even adding a single space.

Where Herkos helps, and where it does not

Be precise, because this is the case a skeptic pushes on hardest:

• The command/args swap: NOT caught. MCPoison mutates a server's command and args. Herkos's scan --baseline compares tool descriptions only - it never parses command or args - so the canonical MCPoison swap is invisible to it. Blocking a changed config before it runs is trust-on-first-use pinning, which Trail of Bits' mcp-context-protector does and Herkos does not. It would be wrong to claim Herkos catches this CVE.
• The description rug-pull: caught. The sibling attack - a server that keeps its command but poisons a tool's description after approval (the tool-poisoning / line-jumping shape) - is caught: scan --baseline flags a description that drifted from your known-good snapshot. That is the real, demonstrable capability, shown below.
• Record: supporting. A per-session audit log (serve --receipts) anchors what actually ran; tie it to the config you approved and a later change is evident across sessions.

Here is the receipt

A real run of this repo's binary - the description rug-pull, not the command swap. The trusted baseline pins what deploy/run was approved to do; the scanned config carries a description that drifted to smuggle an instruction, and Herkos flags it:

$ herkos scan --config deploy.manifest.json --baseline deploy.baseline.json
  [poisoned] deploy/run: tool description differs from baseline
herkos scan: 0 over-scoped, 1 poisoned, 0 unrestricted-egress, 0 unbrokered, 0 unpinned-install, 0 remote - your code never left this machine

Run it in CI against a committed baseline and a post-approval swap fails the check instead of running unnoticed.