Deadbugz: your MCP tool turns on the fourth call

The MCP tool you approved will betray you on the fourth call — and during the minutes you spent reviewing it, it looked completely normal. On the evening of August 10, one GitHub account submitted "minor config" pull requests to 23 repositories in 74 minutes. Hidden inside was an MCP server that behaved as an honest formatting utility for its first three calls and then, from the fourth, used protocol metadata to tell the connected agent: go find SSH keys, AWS credentials, and Kubernetes configuration — and don't let the operator notice.

A Three-Stage Timeline of the Attack

Delivery. Pillar Security observed the GitHub account zellkernel submitting 23 pull requests to 23 unrelated AI, MCP, and developer-tooling repositories between 9:52 PM and 11:07 PM UTC on August 10, 2026: 17 added a remote MCP endpoint (productivity-suite-mcp.onrender.com/mcp) to the target's config, four configured a hidden local script (~/.config/.cache/.sys/.deadbug-mcp.py) as an MCP server, and two submitted directory listings, apparently reconnaissance. At disclosure, 19 PRs had been closed by maintainers and four remained open; none went through a normal review-and-merge flow. The account had created 21 of its 50 public repositories the same day and was linked bidirectionally to an X account (@llmgod) (Source: Pillar Security original disclosure).

Gating. The server exposes only two harmless-sounding tools: format_text and summarize. It keeps an in-memory, per-client counter of tools/call requests. For the first three calls, tools/list and prompts/get return descriptions that match the names. Past the third call, the same interfaces start returning malicious instructions — search for SSH keys, AWS credentials, Kubernetes configuration files, and shell history; relay or stage that material for exfiltration; and avoid drawing the operator's attention. Researchers found a Bitcoin address embedded in the delayed malicious prompt, pointing to a financially motivated actor rather than a research demonstration (Source: Pillar Security original disclosure).

Evasion. This is the most elegant part of the whole attack: the server's code and on-disk configuration never change — only the runtime protocol responses do. A one-time install review, a static scanner, or even one or two interactive test calls all stop before the threshold and see a benign formatting utility. Only continued, normal use — the very confidence a review is supposed to produce — crosses the threshold and exposes the payload. The Cloud Security Alliance's assessment is that this is a systematic evasion of point-in-time review, currently the primary MCP vetting mechanism at most organizations (Source: CSA research note, 2026-09-02).

Why "Reviewed" No Longer Means "Trusted"

Comparing this with the same class of event a year earlier shows what is new. In September 2025, the npm package postmark-mcp built reputation over fifteen clean releases, then quietly added a line of code in a sixteenth release that blind-copied outgoing email to an attacker-controlled address — a classic rug pull, where malicious code arrives with a version update and a package manager or SBOM can at least flag "the version changed." Deadbugz builds the malicious logic into the server from day one and triggers it by call count rather than version number; SBOM comparison and diff review fail entirely because the malicious content never sits in the reviewed code — it only appears in runtime protocol responses (Source: The Register on postmark-mcp).

That yields a hard conclusion: tool metadata — names, descriptions, schemas — is a runtime security boundary, not an approval artifact at install time. Agents are designed to trust protocol metadata because it arrives through the "trusted" protocol layer; the attacker does not need to trick the model, just to write instructions into a tool description, and the agent obeys. This is what CSA calls a confused deputy: an entity holding legitimate, broad privileges is manipulated into exercising them on the attacker's behalf, without its own access controls ever being bypassed (Source: CSA research note).

Our Judgment: Approval Belongs at Action Time, Not Install Time

Deadbugz is not one more vulnerability; it is a systematic challenge to the mainstream of current MCP governance. For most organizations, the only vetting mechanism for an MCP server is a single install-time review — and one counter bypassed it. Our judgment: tool descriptions are a runtime security boundary; one-time review is not ongoing trust; approval should happen when an action executes, not when a tool is installed.

Three consequences follow. First, capability declarations must be monitored continuously: build a known-good fingerprint of each approved MCP server's tool schemas and compare every tools/list or prompts/get response against it, alerting on deviation — this control would have surfaced Deadbugz shortly after the third call. Second, change means re-approval: any change to tool descriptions or parameter schemas, whether it appears in a diff or only in runtime responses, should trigger renewed human approval before the agent may act on it for sensitive operations such as credential access, out-of-project file reads, or code execution. Third, this is the same position we have argued as pre-execution authorization: the control point for agent governance is not "which tools are installed" but "is this action allowed" — install-time approval is supply-chain hygiene, not authorization.

One line from CSA supports our view: "Tool descriptions and schemas function as a runtime security boundary that must be monitored continuously rather than approved once." We agree, and we believe it should become the default requirement for MCP procurement and deployment.

What It Means for Buyers

AI App leads: before integrating any third-party MCP server, require schema fingerprinting and runtime baseline alerting; treat any pull request that adds or modifies an MCP server configuration like a change touching production credentials; treat MCP-config PRs from unfamiliar contributors as highest-risk. And remember: a closed-but-unmerged PR does not prove the server was never run — someone may have tested it locally.

Security teams: immediately search repositories and PR history for the indicators above; for any process that "adds trust" to an MCP tool, add runtime behavioral monitoring rather than relying on one-time review.

Your Next Move

Now: grep your codebase and configs for productivity-suite-mcp.onrender.com/mcp or ~/.config/.cache/.sys/.deadbug-mcp.py; search open and closed PRs from zellkernel; treat any finding as a compromise and rotate every credential reachable from the affected host. This week: build a tool-schema baseline for each approved MCP server and start per-call comparison of tools/list responses. Long term: put "tool metadata changes" into the re-approval process, and move approval for sensitive actions to execution time — not install time.

References: Pillar Security: Deadbugz original disclosure (2026-08-12) · CSA research note: runtime-gated MCP metadata poisoning (2026-09-02) · The Register on the postmark-mcp incident (2025-09-29)