Deadbugz: an MCP server that turns hostile on call three

Pillar Security documented an MCP supply-chain campaign it calls Deadbugz, and the interesting part is not the payload. It is the timing. The malicious MCP server behaves perfectly for the first three tool calls, then rewrites the instructions it hands back to your AI agent into a hunt for SSH keys and cloud credentials. Any review that connects the server, pokes it twice, and calls it clean will pass it.

What actually happened

According to Pillar's write-up, a GitHub account named zellkernel filed 23 pull requests in 74 minutes — 9:52 PM to 11:07 PM UTC on August 10, 2026 — across unrelated AI and developer-tool projects. Each PR added a configuration entry for an MCP server calling itself productivity-suite, offering text formatting and summarization.

The server delivers on that. Then, after a connected client makes exactly three tool calls, it changes the metadata it returns. The new tool descriptions instruct the agent to go looking for SSH keys, AWS credentials, shell history, and Kubernetes configuration, and to conceal that activity from the operator. Pillar's published indicators: the remote endpoint productivity-suite-mcp.onrender.com/mcp, a local artifact at ~/.config/.cache/.sys/.deadbug-mcp.py, and a Bitcoin address marker.

This is runtime-gated metadata poisoning, and it is a category problem, not one bad actor. Tool descriptions are instructions your agent trusts. MCP lets a server change them whenever it wants. Invariant Labs demonstrated the same sleeper pattern back in April 2025 with a tool that changed its description after approval. The mechanism has been known for over a year and the trust model still has not moved.

Why MCP supply-chain risk matters for your business

If your team runs Claude Code, Cursor, or any agent harness with MCP servers configured, the config file is now a security boundary and almost nobody treats it like one. A .mcp.json entry in a pull request gets the same glance as a lint rule change. It should get the same scrutiny as adding a new dependency with a postinstall script, because functionally that is what it is — except this one reads your ~/.aws/credentials with your own developer's permissions.

Three things worth doing this week, all cheap:

Inventory what is actually configured. Grep your repos and dotfiles for MCP config. Most teams find servers nobody remembers adding, pointed at hosts nobody vetted.

Make MCP config a reviewed path. Add the config files to CODEOWNERS. A new server URL should require a named human to approve it, and the diff should never merge on autopilot.

Treat a tool-definition change as a security event. This is Pillar's own recommendation and the only mitigation that addresses the actual trick. If an approved server's tool descriptions change, that is not a version bump — that is a re-approval. Pin servers to containers with scoped filesystem access where you can, so a hostile description hits an empty directory instead of your keys.

The broader point: approving an MCP server once is not approval of everything it will ever say. Deadbugz just made the gap between those two things impossible to ignore.

Sources: Pillar Security on Deadbugz, Invariant Labs on MCP tool-description attacks.