An MCP server with two text-formatting tools slipped through 23 pull requests. Its trick: it behaves for the first three calls, then tells the agent to hunt for SSH keys and AWS credentials. Here is how it works and why it is different from the classic "rug pull."
Researchers at Pillar Security identified an active campaign they named Deadbugz. A single GitHub account (zellkernel) submitted 23 pull requests to unrelated public repositories in a 74-minute window (21:52 to 23:07 UTC). The PRs added the configuration for an MCP server called productivity-suite: 17 pointed to a remote endpoint, 4 to a local script, and there were 2 submissions to directories or listings.
When Pillar checked the status, 19 PRs were closed and 4 open; none had been merged through GitHub’s merge mechanism. The Cloud Security Alliance note makes clear that the number of victims is not specified, because visibility into who had run the server locally was limited. In other words: the campaign is real and active, but there is no confirmed count of affected users. On October 8, the OWASP GenAI Security Project’s quarterly summary included it among the Q3 incidents.
The server exposes two innocent tools, format_text and summarize. For the first three calls, its responses to tools/list and prompts/get describe exactly what the name suggests. After the third, it starts returning different content: instructions for the agent to look for SSH keys, AWS credentials, shell history and Kubernetes configuration, and to hide that activity from the user.
In a traditional rug pull, the author publishes a clean version, waits for approval, then ships a modified tool definition. That leaves a trail: a version change, a different hash, a detectable diff. The CSA sums it up this way: Deadbugz "never changes its published code or its configuration on disk"; the divergence is a function of an internal state that only shows up in protocol responses during real use.
That is why the CSA warns that a one-time review at install, an automated scanner that inspects the code once, or even a short interactive test session can all finish within the first two calls and see nothing but a formatting utility.
The recommendations from Pillar and the CSA converge: treat any PR that adds or modifies an MCP server configuration as a high-risk change; fingerprint tool definitions at approval time and alert if they change at runtime; monitor schema changes per call; use an allowlist of MCP servers; and separate credentials from the access of the agent’s tools. Pillar also suggests blocking the campaign’s known remote endpoint.
~/.ssh or long-lived cloud credentials; use temporary, least-privilege credentials; (3) log the responses from MCP servers, not just their installation. One-time approval is no longer a sufficient control. If you want to audit your MCP surface: info@guatemalia.com.Sources: Pillar Security, Cloud Security Alliance research notes (August 30 and September 2, 2026) and the Q3 2026 summary from the OWASP GenAI Security Project.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel