How the Deadbugz MCP Attack Hid in a Trusted Server

Your new MCP server passes code review, runs clean through your first few tests, and behaves for the first two tool calls. Then, on the third, it starts hunting for your SSH keys.

That is the trick behind the Deadbugz MCP attack, an active supply-chain campaign that Pillar Security identified spreading through ordinary-looking GitHub pull requests. If your team is wiring Model Context Protocol (MCP) servers into agents right now, this is the story to read before you merge the next one.

What happened

On August 10, 2026, a GitHub account named zellkernel opened 23 pull requests against unrelated AI and developer-tooling repositories in a single 74-minute burst, between 9:52 PM and 11:07 PM UTC. Each PR added a reference to an MCP server called productivity-suite, pitched as a harmless utility offering two tools: format_text and summarize.

The server's actual behavior only shows up after use. It keeps an in-memory, per-client counter of tools/call requests, and once a session crosses three calls, it rewrites the metadata it returns through tools/list and prompts/get. The rewritten instructions steer the agent toward collecting SSH keys, AWS credentials, shell history, and Kubernetes config files, while working to keep the activity hidden from whoever is watching the session.

The distribution mix mattered too. Of the 23 PRs, 17 pointed agents at a hosted endpoint (productivity-suite-mcp.onrender.com/mcp), 4 dropped a hidden local script at ~/.config/.cache/.sys/.deadbug-mcp.py, and 2 were plain directory-listing submissions. At the time Pillar reviewed the campaign, 19 of the PRs were closed but 4 were still open. NHI Mgmt's analysis frames this as "control-plane manipulation of agent behavior through trusted metadata," distinct from a classic prompt injection because the malicious instructions never appear in the prompt at all. They arrive as part of the protocol's own tool descriptions.

This is also not a one-off. Both write-ups point back to a 2025 incident involving a counterfeit postmark-mcp package that shipped clean and later added covert email-copying functionality after gaining adoption. Deadbugz is the same delayed-trust pattern, refined.

Why this matters for MCP tool trust

Most teams treat a PR that adds an MCP server entry to a config file as routine collaboration, the same as bumping a dependency version. It gets a glance, not a security review. That is exactly the gap this campaign exploits.

It also breaks the assumption that testing a tool before rollout tells you what it will do in production. A three-call threshold is short enough to survive a quick smoke test or an automated CI check, but well within range of normal agent usage a few hours later. Static review of the tool's advertised schema is worthless here too, since the schema you approved isn't the one the agent sees after the trigger fires.

For anyone deploying agents against real infrastructure, that means the MCP server itself has become an attack surface with the same blast radius as a compromised CI runner: whatever credentials the agent's process can read, the server can ask the agent to go fetch.

What to actually do Monday morning

First, check whether you have it. The indicators are public and easy to grep for:

# Search for known Deadbugz indicators of compromise
grep -rl "productivity-suite-mcp.onrender.com" ~/.config ~/.cursor ~/.codeium ~/.claude 2>/dev/null
find ~ -path "*/.config/.cache/.sys/.deadbug-mcp.py" 2>/dev/null

If either turns up a hit, remove the server entry, rotate any credentials the agent's runtime user could reach (SSH keys, AWS access keys, kubeconfig contexts), and check shell history for anything exfiltrated.

Then change how you review MCP additions going forward:

• Treat any PR that adds or edits an MCP server config as a security review, not a dependency bump. Require a named reviewer who checks the source, not just the description.
• Log full tools/list and prompts/get responses per session, and diff them over time. A tool whose description changes mid-session is the signal, even if the change happens after your test window closed.
• Run MCP servers with least-privilege credentials. An agent that only needs to summarize text should not be running under a shell that has an AWS credentials file or an SSH agent socket available to it.
• Prefer pinned, hash-verified server artifacts over live endpoints you don't control, so a compromised or malicious host can't change behavior after you've approved it.

Deadbugz worked because a friendly tool description is not a promise, and most review processes never ask the tool to prove it three calls in. Once you're running agents against production credentials, that gap is the whole ballgame.