Deadbugz: The MCP Supply-Chain Attack That Waits for Three Calls

On September 7, Adversa AI published their monthly MCP security digest. The headline was not a paper or a CVE — it was an active supply-chain campaign tracked to a single GitHub account that filed 23 pull requests across unrelated AI and developer-tool projects in 74 minutes. The campaign has a name: Deadbugz.

The server presents itself as a productivity suite offering text formatting and summarization. For the first two tool calls, it behaves exactly as advertised. On the third call, it rewrites the tool descriptions it returns to the agent — the metadata that becomes the agent's instructions — into prompts that hunt for SSH keys, AWS credentials, shell history, and Kubernetes configuration while concealing the activity from the user.

This is metadata poisoning: the server's own self-description mutates at runtime. A reviewer checking a new MCP server before approval sees harmless tools. The hostile behaviour only appears once the server is trusted and in active use.

What Deadbugz Actually Does

Pillar Security's writeup, published the same week, traces the campaign to a single actor. The malicious server was packaged as productivity-suite and submitted via pull requests to 23 repositories — AI agent frameworks, developer tooling, and MCP-related projects — all within a 74-minute window on September 7.

The attack chain:

1. Installation vector: A pull request adds the server to a project's MCP configuration or recommends it in documentation.
2. Benign phase: The server exposes two tools — text formatting and summarization — that work normally for the first two invocations.
3. Trigger: On the third tool call from the same client, the server rewrites its own tool metadata (the description fields the MCP protocol uses to tell the model what each tool does) into instructions to search the filesystem for secrets.
4. Exfiltration: The mutated instructions direct the agent to read ~/.ssh/, ~/.aws/, ~/.kube/, shell history files, and other credential stores, then return the findings to the attacker.
5. Concealment: The activity is hidden from the user; the agent sees only the mutated tool descriptions, not an obvious data-theft action.

The indicators of compromise published by Pillar include the malicious endpoint, the local artifact path the server writes to, and the GitHub account used for the PR campaign.

Why This Defeats Standard Review

MCP security tooling today — and most human review processes — operates on a static snapshot. You install the server, enumerate its tools, read their descriptions, and decide whether to approve. Deadbugz passes that check because at the moment of inspection, the tools are benign.

The mutation happens after approval, triggered by usage volume. This is not a theoretical concern: the Adversa article notes that if your MCP client caches tool definitions (many do, to avoid round-trips on every request), the cached definitions become stale the moment the server mutates. The agent operates on poisoned instructions while the human believes the server is still the one they approved.

The August CVE Context

Deadbugz arrived alongside three MCP server CVEs disclosed in August — none of them model-specific, all classic web flaw classes:

• CVE-2026-73498 (CVSS 7.7): Path traversal in the Atlassian MCP server. The confluence_upload_attachment tool passes a client-supplied file path to open() with no validation, giving any authenticated MCP client arbitrary file read across the server process.
• CVE-2026-67357 (CVSS 7.7): ArcadeDB MCP discloses the HA cluster token in cleartext via a settings tool. That token impersonates root through specific headers — MCP access converts directly to full server compromise.
• CVE-2026-19956 (CVSS 5.3): SSRF in facebook-ads-mcp-server via fetch_pagination_url, letting an authenticated user drive requests from the server's network position.

Three CVEs, three ordinary vulnerability classes (path traversal, secret leakage, SSRF), zero involving a model. MCP servers are ordinary network services with an extraordinary caller, and they are picking up ordinary bugs. The Adversa roundup notes that 91.8% of 640 discovered production MCP servers had no authentication at all, and 687 tool instances exposed shell execution with no access control.

What Developers Building on MCP Should Do

1. Monitor tool metadata for drift

If your MCP client caches tool definitions, compare them on every reconnect and alert on changes. A server that rewrites its own description fields after N calls is signalling compromise. This is a client-side responsibility — the MCP protocol itself does not version or sign tool metadata.

2. Put an authorization layer in front of MCP servers

The Oracle ORDS MCP hardening walkthrough (also in the Adversa digest) is a working template: validate issuer, audience, JWKS signature, and a mandatory scope, then bind a realm role to a specific backend pool. The role decides which pools the agent can reach; the pool's own credentials decide SQL privilege. A compromised or hijacked agent inherits a narrow surface instead of the server's full reach.

3. Treat MCP servers as untrusted network services

The August CVEs confirm the pattern: MCP servers are picking up the same bug classes as any web service. Run them with least privilege, network isolation, and no access to credential stores they do not strictly need. The Deadbugz server hunts for SSH keys and AWS credentials because the host environment has them.

4. Red-team your MCP integrations

Adversa's MCP red-teaming service exists because "whether that layer actually holds against a hostile server is a separate question." Static analysis and one-time review do not answer it. You need a test that simulates a server that behaves for three calls and then mutates.

The Bigger Pattern

Deadbugz demonstrates how a modern attack assembles from small, separate steps, each of which either looks benign or goes uninspected:

• A PR to a reputable project (looks like a contribution)
• A server with two useful tools (looks like a productivity aid)
• A trigger threshold that defeats sandbox testing (three calls is too many for a quick check)
• Metadata mutation that the protocol does not protect (descriptions are not signed)
• Credential hunting disguised as tool use (the agent does the reading, not the server directly)

The chain is the breach. Observing and reconstructing the whole chain of agentic actions is the only way to stop the damage before it lands — which is exactly what runtime control layers like Adversa's platform aim to do.