We have written before about MCP servers nobody vetted and about the majority of public servers that still skip OAuth. Both are about servers you should not have trusted in the first place. Deadbugz, an active campaign that researchers at Pillar Security disclosed and that the community MCP incident tracker logged as INC-136 on 18 September 2026, is a different problem: a server that looked fine when you approved it, and changed what it does afterward.

What was found

A single GitHub account filed 23 pull requests across unrelated AI and developer-tooling repositories, each one adding a small MCP server pitched as a productivity utility — text formatting and summarization, nothing that would raise an eyebrow in a code review. None of the pull requests were merged before the campaign was caught, and no compromise has been confirmed as of disclosure; researchers are treating this as a demonstrated technique, not a breach with victims.

The mechanism: call-count gating

The server's behaviour depends on how many times a client has called it, not on what it is asked to do — which is what let it pass a quick look and a first session unnoticed.

01

Calls one and two

The server returns exactly what its description promises: formatted or summarized text. A reviewer testing it sees a small, boring, working tool.

02

Call three

The server rewrites the metadata it returns — the tool descriptions the model reads as instructions — into directions to search for SSH keys, AWS credentials, shell history and Kubernetes config, and to do it quietly.

03

Why session-based review misses it

Most manual testing and most one-off approval flows stop after a call or two. The payload is timed to appear after the point where a human has usually stopped watching.

Why this is a distinct threat from a server that was malicious on day one

Tool descriptions in MCP are not documentation for a human — they are text the connected model reads and can act on, which is what makes prompt injection via tool metadata possible at all. A one-time approval assumes the thing you approved stays the thing that is running. Deadbugz demonstrates that assumption is not currently enforced anywhere in the ecosystem: nothing in the specification requires a signed tool manifest, and nothing in most clients re-prompts for consent when a previously approved server's tool definitions change.

What to actually do about it

  • Fingerprint tool definitions at approval time, and compare the fingerprint on every reconnect — a change is a security event, not a routine update.
  • Treat any definition change on an already-approved server as requiring renewed, explicit consent, not silent auto-acceptance.
  • Do not rely on a first session to vet a third-party server. If your process is 'try it once, then trust it,' this is exactly the gap that exploits.
  • Prefer servers you or your platform control the definition of over ones pulled from an open registry or a pull request you did not write.

On SuperCognit, an agent's tools are HTTP endpoints the workspace owner defines and can see in full, not third-party servers pulled in from a registry — there is no pull request from a stranger in that path. That sidesteps this specific campaign, but it does not make the underlying problem go away: anyone connecting Claude, Claude Code or any other MCP client to servers from the open ecosystem should treat the source of a server, and any change in what it advertises, as things worth actually checking.

This account is based on Pillar Security's public disclosure and the community MCP incident database entry (INC-136); some detail is drawn from secondary reporting rather than the original write-up, and neither source has published a confirmed victim as of this writing.