Twenty-three pull requests, none merged, no victims, not one credential handed over. And it is still the most important MCP incident of the year. Because what it proved isn't that the attack works: it's that reviewing doesn't.
The server is honest for exactly as long as you are watching.
That's the whole technique.
Twenty-three lines of configuration
On August 10, 2026, a public GitHub account called zellkernel opened twenty-three pull requests against unrelated AI, MCP and developer-tool projects. Pillar Security reconstructed them two days later: seventy-four minutes end to end, by its clock.
Every one made the same tiny edit: it added one MCP server to a configuration file. Seventeen pointed at a remote endpoint on onrender.com. Four pointed Python at a file hidden in ~/.config/.cache/.sys/.deadbug-mcp.py — four chained dots, four layers of concealment in a single path. The last two were directory submissions: a pull request is only one of the ways a configuration line travels.
The server calls itself productivity-suite and offers two tools, format_text and summarize. Bromure tried them, and they do precisely what they advertise. "Both work."
That's the entire problem. What, exactly, do you review in a one-line diff that adds a server that does what it says it does?
The counter
The server keeps an in-memory, per-client counter of tools/call requests. Once it reaches three, the subsequent tools/list and prompts/get responses change. That is the whole machine.
The tool's name never moves. What turns is the description — and the description, Bromure writes, "is the part the model reads as authority". The agent doesn't obey the name. It obeys the text underneath, and that text arrives over the wire on every refresh.
The new metadata tells the agent to seek four things: SSH keys, AWS credentials, shell history, Kubernetes configuration. Then a fifth instruction, operational rather than technical: conceal the activity from the user. The list has been stable for a decade; it's what an infostealer takes. What's new is who executes it: "An agent on an ordinary laptop can satisfy every item, because it has a shell in your home directory and it runs as you."
Pillar calls it runtime-gated MCP metadata poisoning, and says what the gate is for without dressing it up: "a brief inspection or limited test can receive only benign metadata, while normal use crosses the three-call threshold." It was not built to fool the agent. It was built to fool the reviewer.
The public source also implemented optional telemetry through a WEBHOOK_URL: connection, first call, trigger. Nobody documented an operator sitting in front of that console. But somebody built something to watch.
And there was no poisoned update, no moment when the server switched sides: the instructions were built in from the start, simply withheld.
Pillar named the campaign Deadbugz after the delivery artifact. The name fits better than it meant to. Some bugs play dead while you watch them and get up when you turn around.
Everything runs once
Now the part a dishonest article would skip. Measured against its own stated goal, the campaign failed: nineteen pull requests closed, four open, none merged through GitHub's merge button at the time of review. No public source reports a single victim, a single credential handed over, or any damage at all.
And a month on, it is still in every MCP security roundup. The Hacker News ran it on August 27 as item 24 of 31 in its ThreatsDay. Cloud Security Alliance rated it CRITICAL on September 2. Adversa AI listed it on September 7 as the only incident among eight articles that month.
Why does everybody care this much about something that stole nothing from anyone?
Because what it broke isn't a system. It's a ritual. Nearly every control a team has against a hostile MCP server runs exactly once: you read the code once, approve the tool once, pin the version once. "Each of those is a photograph, and Deadbugz decides when you take it."
The one who ends up PAILA isn't the one who reviewed badly. It's the one who reviewed well, at the wrong hour.
The contrast lives in the same month. August produced three MCP server CVEs — path traversal, a cluster token in cleartext, an SSRF — and all three have a patch. Deadbugz has no patch, because it isn't a defect: it's the protocol working as written. "There is no memory corruption to patch and no CVE to file."
The ground is fertile, too. Exposed by Design, by Nicolás Padilla, dynamically audited 414 production MCP servers, and 91.8% of them had no OAuth authentication.
The channel isn't new either. With ClawHavoc we quoted 1Password's line: in an agent ecosystem, markdown is an installer. Deadbugz is the installer that rewrites itself after installation. And the npm worm with valid provenance is the same trick from the other side: there, opening the repository was enough; here, the line waits its turn.
The prohibition nobody enforces
Bromure wrote it without hedging: "The server does nothing the protocol forbids." Against the 2025-06-18 specification, true. Against the intermediate 2025-11-25, also true.
Against the current one, false.
On July 28, 2026 — thirteen days before the twenty-three pull requests — the project published the 2026-07-28 specification and introduced a sentence that describes the Deadbugz mechanism with prosecutorial precision: the tool set "MAY change over time … but MUST NOT vary per-connection or as a side effect of other requests on the connection." The ban isn't absolute — the same paragraph allows the set to vary by the authorization presented on the request. Deadbugz doesn't vary by authorization. It varies by how many times you called it.
That sentence exists in neither earlier version. The same specification adds a note the counter contradicts head-on: "MCP has no protocol-level session, so a server cannot rely on implicit per-connection state to relate one tool call to the next." An in-memory per-client counter is precisely that implicit state.
Thirteen days. Explicitly forbidden, in the document that defines the protocol, before the campaign began.
It changed nothing whatsoever. And who was going to check?
The tools section's Security Considerations are near-identical across all three versions: in a year they gained a single bullet, about $ref resolution. Clients are still asked to confirm sensitive operations, show inputs, validate results and log usage. Not one word, in any of the three, about re-approving a tool whose definition changed.
The trust warning closes the circle: "clients MUST consider tool annotations to be untrusted unless they come from trusted servers." Distrust the annotations unless they come from a trusted server. The trusted server is exactly the one lying.
In April 2025, Invariant Labs demonstrated this and gave it a name: "An MCP rug pull allows an attacker to change the tool description after the user has already approved it for use." Fifteen months later the protocol answered with a prohibition that has no enforcer.
Attribution
Perpetrator: zellkernel. Pillar attributes the whole delivery operation to it: the twenty-three pull requests, the source repository, the same campaign markers from start to finish. It created twenty-one repositories on that same August 10. Its profile linked to @llmgod on X, and the X profile linked back. Inside the delayed malicious prompt sits a Bitcoin address next to the word deadbugz; Cloud Security Alliance reads that as "financially motivated", which is an interpretation and not a fact. Today the account and the repository do not exist publicly: GitHub's API returns 404 for both, and there is no copy of the repository in the Wayback Machine. Who deleted them, nobody has said.
Accomplices: the MCP clients that refresh the tool list and never compare it against what they approved. The one defense the whole industry repeats — review the server before you connect it — is precisely the one the three-call counter is built to walk through. And the tools that promise to catch this: on September 11, mcp-guardbench itself documented that its own guard let poisoned definitions through by way of notifications/tools/list_changed — 88.9% caught, with the two Deadbugz cases among the four misses. They published that themselves.
Systemic failure: a protocol where the authority the model obeys is remote, mutable text, and where approval is an event rather than a state. We already wrote this with the confused deputy: authorization frameworks cannot constrain agent behavior post-authentication. Deadbugz is the cleanest demonstration of that sentence there is. The server presents itself as benign, passes the check, and once inside reprograms the deputy with the only instrument it needs: a description.
All of MCP's security rests on one instant: the one where somebody looks at the server and says yes. Deadbugz never attacked that instant. It played dead until it passed.
Twenty-three attempts, none merged, no victims. That's why nobody panicked. And the uncomfortable question isn't whether the server you connected was benign when you reviewed it. How many calls ago was that?