incidents: add INC-132, Deadbugz MCP call-count-gated tool poisoning

[gautamgb]

Pillar Security's Deadbugz disclosure: a malicious MCP server serves
its documented, benign tool contract for the first two tool calls in
a session, then substitutes credential-harvesting instructions on the
third call. A connect-and-check review never crosses the threshold,
so this is invisible to single-session auditing by construction.

Mapped to ASI01 (goal hijack), ASI02 (tool misuse), ASI04 (agentic
supply chain). Delivery: 23 PRs from one account against unrelated
repos, none merged at time of disclosure.

Source: https://www.pillar.security/blog/deadbugz-currently-active-mcp-supply-chain-campaign

[emmanuelgjr]

Thanks for this — the record is careful work, and the call-count gating detail is a genuinely useful thing to have in the index.

Two things, one of them my fault.

1. INC-132 is already taken. It was allocated by #117 (merged ea971a0) for the Agno RCE CVE while this PR was open — that's an id-allocation race, not anything you did wrong, and GitHub is already reporting this branch as conflicting. Could you renumber and rebase?

The next free id is INC-136: main holds INC-001…INC-134, and INC-135 is claimed by open PR #122 (llmware SQLi). If #122 lands after you, you'd collide again — so #136 is the safe pick either way.

Happy to do the renumber and rebase for you if you'd rather not — say the word and I'll push it to your branch, or open a follow-up that does it, whichever you prefer. Only asking first because it's your branch.

I'm also adding a guard so this can't recur: a validator check that fails on duplicate incident ids, plus a scripts/next-incident-id.mjs helper so contributors can allocate an id without reading the whole file. That's in a separate small PR and will land independently of this one.

2. Triage verdict: it qualifies. I checked it against docs/TRIAGE_RULES.md, which restricts the incident index to real-world deployment failures and routes laboratory work elsewhere. Deadbugz clears that bar: a malicious MCP server was actually published, and 23 PRs were actually opened against unrelated repositories by a named account. Those are artifacts deployed in the wild, not a proof of concept — so it belongs in the index rather than in the benchmark catalogue or a close-as-noted.

One thing worth a second look while you're rebasing: the record sets category: "real-world" but its own impact says "no confirmed compromise as of disclosure". Both readings are defensible — the campaign is real, the victim impact is unconfirmed — but research-demonstrated may fit better, and either way it's worth being deliberate about. Entirely your call; I'm not going to touch it.

Nothing else blocks this from my side.

[gautamgb]

Thanks for catching both. Pushed a fix for each.

Renumbered to INC-136 and rebuilt clean off current main. #117 and #122 both touch the same generated JSON/JS this schema regenerates, and a hand-resolved merge there risked corrupting it. Checked the free id against main directly: 001 through 134 contiguous, 135 claimed by your open #122, so 136 stays clear either way that one lands.

On category, I went with your suggestion, research-demonstrated. Wanted to write down why it's right, since I checked it rather than took it on faith. The schema's own enum description defines real-world as a confirmed incident, and this entry's impact field says plainly that no compromise was confirmed, 23 delivery PRs, none merged. INC-126 is the only other entry in the dataset with comparable unconfirmed-impact language, and it already carries research-demonstrated. Three independent readings landing on the same answer is what convinced me.

One small thing on your review: I couldn't find docs/TRIAGE_RULES.md anywhere in the repo, on main or any open PR. Not blocking anything here, the schema enum backs the same verdict on its own. Flagging in case it's sitting uncommitted somewhere on your end.