By ByteBot
An active MCP supply-chain campaign called Deadbugz filed 23 pull requests across unrelated GitHub repos in 74 minutes — each one adding a server called productivity-suite that offers text formatting and summarization. For the first two tool calls, it behaves exactly as advertised. On the third call, it silently rewrites its own tool descriptions to tell your AI agent to find your SSH private keys, AWS credentials, shell history, and Kubernetes config — and to hide what it is doing. Your install-time review caught nothing, because the attack is specifically designed not to fire until after you trust it.
How the Campaign Was Delivered
Pillar Security researchers tracked the campaign to a single GitHub account, zellkernel, which submitted 23 pull requests to unrelated AI, MCP, and developer-tool repos in a 74-minute window on August 10, 2026. The PRs were framed as helpful contributions — the same social engineering playbook as npm supply chain attacks. Of the 23 identified PRs, 17 configure a remote MCP server, 4 reference a hidden local Python path, and 2 are directory or listing submissions. The campaign takes its name from the delivery artifact: deadbug-mcp.py.
At time of disclosure, 19 of the 23 PRs were closed. Four remained open. The full Pillar Security writeup documents the campaign in detail, including indicators of compromise.
The Three-Call Delayed Fuse
The attack mechanism is straightforward and, for that reason, effective. The MCP server maintains a call counter. For the first two tool calls, it returns clean, benign tool descriptions. On the third call, the server rewrites the metadata it sends back to the agent — the same metadata the LLM reads as instructions. The new descriptions direct the agent to locate and read:
~/.ssh/— SSH private keys~/.aws/credentials— AWS access keys and secrets- Shell history files (
.bash_history,.zsh_history) — which often contain API tokens typed at the terminal ~/.kube/config— Kubernetes cluster credentials
The instructions also tell the agent to conceal the activity from the user. By the time the attack fires, the server is already trusted. The agent is just following what the tool told it to do — because in MCP, tool metadata is indistinguishable from instructions.
Why Your Review Process Did Not Catch It
This is the part that matters for your security posture. Every standard review — checking what tools the server lists when you connect, reading the source code once, running it in a test environment — evaluates the server before the tripwire fires. Three benign calls is all it takes to look clean. You approved a different server than the one that is running now.
The deeper problem is architectural. The MCP specification allows servers to change tool definitions at runtime without triggering any re-consent from the client. What you approved and what the agent sees on call four can be completely different. There is no cryptographic signing of tool manifests, no standard re-consent flow, and no mechanism for the client to notice the change. This is not a bug in any particular MCP implementation — it is a design gap in the protocol itself.
Security researchers have a name for this variant: a rug pull attack. The tool is clean when you approve it. The rug gets pulled later.
What to Do Now
Four actions, in order of urgency:
1. Search for the Deadbugz artifact. Run a quick check across your MCP configuration files:
grep -r "deadbug-mcp\|productivity-suite" ~/.config/ ~/Library/ ~/.claude/ 2>/dev/nullIf anything matches, remove that server configuration immediately and rotate any credentials that might have been accessible in the affected session.
2. Audit every third-party MCP server you are running. mcp-audit (open source, ships a GitHub Action and pre-commit hook) reads your MCP configs and flags security issues including dangerous cross-server combinations. The mcpserver-audit tool from the Cloud Security Alliance scores vulnerabilities and checks dependencies. Both are free.
3. Monitor tool metadata on every reconnect. If your MCP client caches tool definitions between sessions, compare the fingerprints of those definitions on each reconnect. Any change should be treated as a security event, not a routine update. Researchers logged MCP tool schemas silently drifting as recently as September 4, 2026 — in some cases with identical visible descriptions but different underlying parameter schemas.
4. Treat all third-party MCP servers as untrusted by default. Until the MCP spec adds signed tool manifests and a re-consent flow for definition changes, one-time approval is not enough. If a server changes its tool descriptions, that change should require your explicit re-approval — not silent acceptance.
Deadbugz Is a Proof of Concept
The three-call threshold is arbitrary. Change it to ten, fifty, or a timer, and the same technique works with an even longer clean window. The GitHub PR delivery is also trivially scalable — 23 PRs in 74 minutes is clearly automated. Deadbugz is not a sophisticated campaign. It is a demonstration that the attack surface is open and that no current defense catches it reliably.
The MCPTox benchmark tested 45 live MCP servers against poisoned tool descriptions and found attack success rates between 60% and 72% across popular AI agents. The protocol needs mandatory tool manifest signing and runtime re-consent for definition changes. Until that ships, your only defense is monitoring what your MCP servers are telling your agents — not just at install time, but on every call.
