--- title: "Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review | Anomity Blog" description: "Pillar/CSA Deadbugz: 23 PRs from zellkernel on Aug 10 2026 planted MCP servers that look clean for three calls, then poison tools/list. One-time review is not enough." url: "https://anomity.ai/blog/deadbugz-runtime-gated-mcp-metadata-poisoning/" source: html --- On this page - What Deadbugz did - Why one-time MCP review fails - What to change in governance - How Anomity detects and governs runtime MCP drift - Frequently asked questions [← Back to blog](https://anomity.ai/blog/) - Home - Blog - Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review ![Anomity robot illustrating Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review] Insights # Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review Anomity Research Anomity Research · Sep 14, 2026 · 4 min read Share: Copied TL;DR - Deadbugz is a runtime-gated MCP metadata poisoning campaign documented by Pillar Security and summarized in a Cloud Security Alliance research note ( 2 September 2026 ). - On 10 August 2026 , GitHub user zellkernel opened 23 pull requests that tried to land malicious MCP server wiring into open-source projects. - The hostile endpoint cited in reporting is productivity-suite-mcp.onrender.com . Tool metadata looked benign until a call-count gate flipped behavior after three calls. - After the gate, subsequent tools/list responses carried poisoned tool descriptions - the same content-layer class as classic MCP tool poisoning, delayed past install-time review. - Reporting describes exfiltration-oriented instructions targeting SSH material, cloud credentials, and shell history once the poisoned metadata steered the agent. - There is no CVE for Deadbugz: it is a campaign pattern, not a single patched product bug. None of the PRs were reported as merged via ordinary GitHub review. Most MCP reviews still look like a one-time checklist: connect the server, read `tools/list`, approve the descriptions, move on. **Deadbugz** exists to beat that checklist. Documented by **Pillar Security** and summarized in a **Cloud Security Alliance** research note on **2 September 2026**, the campaign shows malicious MCP metadata that stays clean until a **runtime call-count gate** flips - then the same `tools/list` channel that passed review starts steering the agent. ## What Deadbugz did On **10 August 2026**, GitHub account **zellkernel** opened **23 pull requests** aimed at wiring a hostile MCP server into open-source projects. The server hostname called out in reporting is **productivity-suite-mcp.onrender.com**. Early interactions looked ordinary. After **three** calls, later **tools/list** responses carried **poisoned tool descriptions** - hidden instructions in the metadata MCP clients inject into model context. That is the same content-layer failure mode as classic [MCP tool poisoning via hidden instructions](https://anomity.ai/blog/mcp-tool-poisoning-hidden-instructions-campaign/), with a timing trick on top. Install-time and first-list review see a clean suite. Production agents that keep listing tools as sessions continue get the payload. Reporting describes the post-gate instructions as oriented toward **SSH material, cloud credentials, and shell history** exfiltration - the usual high-value local secrets on a developer workstation. There is **no CVE**. Deadbugz is a campaign pattern, not a single patched library version. CSA and Pillar also note that **none** of the **23** PRs merged through ordinary GitHub review - which is fortunate for the targeted repositories and beside the point for anyone whose approval process would have green-lit the still-benign first listing. ## Why one-time MCP review fails Tool poisoning works because clients trust server-supplied descriptions when they plan. We covered that hinge in the [tool poisoning campaign advisory](https://anomity.ai/blog/mcp-tool-poisoning-hidden-instructions-campaign/) and in adjacent instruction-splitting research such as [GhostSplice](https://anomity.ai/blog/ghostsplice-cross-channel-mcp-instruction-splitting/). Deadbugz adds a simple insight: **if review is a moment, wait until after the moment**. Call-count gating is cheap to implement on a hosted MCP endpoint and expensive to catch with screenshots from onboarding day. It also composes with other MCP trust failures: a server that later changes who answers the hostname (see [MCPJacking](https://anomity.ai/blog/mcpjacking-expired-domain-mcp-registry-hijack/)) or that only becomes dangerous once an agent has already authorized a chain of actions (see [GhostJacking](https://anomity.ai/blog/ghostjacking-agentic-kill-chain-authorized-actions/)). The shared theme is that **MCP trust is continuous**, not a badge earned at install. ## What to change in governance - Snapshot and re-hash tools/list metadata after approval; alert on drift, not only on first connect. - Inventory MCP URLs and server identities on developer endpoints, including one-off onrender.app and similar hosts that never entered a registry. - Assume early benign behavior is not a verdict - especially when a server is remote and operator-controlled. - Gate the resulting tool calls at the agent hook. Poisoned descriptions steer plans; allow/deny/log decides whether the dangerous call runs. - Hunt the delivery path : unexpected PRs that add MCP config, new remote MCP hosts, and agents that suddenly grow new tools mid-week. For protocol-level background on why tool metadata reaches the model at all, see [Model Context Protocol security explained](https://anomity.ai/blog/model-context-protocol-mcp-security-explained/). For a practical registry practice that would have made `productivity-suite-mcp.onrender.com` stick out, see [how to build an MCP server registry](https://anomity.ai/blog/how-to-build-an-mcp-server-registry/). A complementary HTTP-boundary class: [why local MCP HTTP keep falling to DNS rebinding](https://anomity.ai/blog/mcp-local-http-dns-rebinding-class-2026/) - SDK allowlists exist, packages keep shipping without them. ## How Anomity detects and governs runtime MCP drift Anomity's **Endpoint Sensor** inventories MCP servers among the eight AI artifact types on each managed endpoint, so a remote host such as an unexpected onrender MCP URL is a fleet query rather than a rumor. **Browser Sensor** and **cloud discovery** (Google Workspace / GitHub OAuth grants) cover adjacent AI surfaces; secrets are redacted on-endpoint and only metadata leaves the machine. On agents that expose a hook such as Claude Code **PreToolUse**, [runtime governance](https://anomity.ai/#runtime-governance) returns **allow, deny, or log** before a tool call runs. That is the control that still works when `tools/list` looked clean on day one and poisoned on call four: the exfiltration-oriented call is visible at the boundary even if the description that inspired it was not. Every decision lands in a [queryable 90-day audit trail](https://anomity.ai/#outcomes) and can route to SIEM, Slack, email, or Jira. Anomity is SOC 2 Type II and complements Network, EDR, DLP, and GRC. Deadbugz is what happens when attackers notice your MCP review is a single screenshot. Continuous metadata comparison plus hook-time enforcement beats one-time approval. To see which MCP servers your fleet actually connected - and what [runtime governance](https://anomity.ai/#runtime-governance) would have denied - [book a 30-minute demo](https://anomity.ai/#early-access). Share: Copied ## Frequently asked questions What is Deadbugz? Deadbugz is the name used in Pillar Security and Cloud Security Alliance coverage for a campaign that plants MCP servers whose tool metadata stays clean during early review and then changes after a runtime call-count gate. The point of the gate is to defeat one-time human or scanner review that only inspects the first tools/list response. How does the call-count gate work? Per Pillar/CSA reporting, the malicious MCP server served benign tool listings for the first three calls. After that threshold, later tools/list responses introduced poisoned tool descriptions and instructions. A reviewer who connected once, listed tools, and approved the server never saw the post-gate metadata. How is Deadbugz different from earlier MCP tool poisoning? Classic tool poisoning, as in the Invariant Labs disclosure covered in Anomity's MCP tool poisoning advisory, hides instructions in tool descriptions from the start. Deadbugz adds a temporal dimension: the poison is withheld until after review pressure drops. Both abuse the fact that MCP clients inject server-supplied tool metadata into model context. Was there a CVE? No. Deadbugz is tracked as a campaign and research note, not as a CVE against a specific upstream package version. Defenders should hunt for the delivery PRs, the onrender.com endpoint, and runtime tool-metadata drift rather than waiting for a CVE match in a scanner. Did any of the zellkernel PRs merge? Reporting states that none of the 23 pull requests merged through ordinary GitHub review. That is good news for the targeted repos and bad news for anyone who assumes PR volume alone equals impact - the interesting control failure is review that would have approved a still-benign first tools/list. What should security teams do about runtime-gated poisoning? Stop treating install-time MCP review as a one-shot decision. Continuously compare tools/list metadata against the approved snapshot, inventory which endpoints connected to which MCP URLs, and evaluate resulting tool calls at the agent hook with allow, deny, or log. A server that changes its tool surface after three calls should page someone. ## Related [Insights ### Claude Fable 5.1 and Mythos 5.1: One Model, Two Safeguard Tiers, and a Fallback Your Security Team Will Hit Fable 5.1 and Mythos 5.1 are one model with two safeguard tiers. Flagged cyber requests in Claude Code fall back to Opus 4.8. What it means for you. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/claude-fable-5-1-mythos-5-1-model-fallback-governance/) [Insights ### NVIDIA's Open Agent Safety Platform Puts Controls Outside the Agent. Now Count the Agents Outside It. OpenShell sandboxes agents with policy outside their reach, and Sentry watches from the DPU. Both cover the agents you enroll. The rest need a list first. Anomity Research · Oct 2, 2026 · 6 min](https://anomity.ai/blog/nvidia-open-agent-safety-platform-openshell-sentry/) [Insights ### OpenAI Astra Crossed the Critical Cyber Threshold. Its Safeguards Stop at the Model. Astra is OpenAI's first model rated Critical for cyber. OpenAI built safeguards for the model. The agents running it on your endpoints are still yours. Anomity Research · Oct 2, 2026 · 5 min](https://anomity.ai/blog/openai-astra-critical-cyber-capability-enterprise/) ## Structured data ```json { "@context": "https://schema.org", "@type": "BlogPosting", "headline": "Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review", "description": "Pillar/CSA Deadbugz: 23 PRs from zellkernel on Aug 10 2026 planted MCP servers that look clean for three calls, then poison tools/list. One-time review is not enough.", "datePublished": "2026-09-14", "dateModified": "2026-09-14", "author": { "@type": "Person", "name": "Anomity Research", "jobTitle": "Anomity Research" }, "publisher": { "@type": "Organization", "name": "Anomity", "url": "https://anomity.ai/", "sameAs": [ "https://www.linkedin.com/company/anomity", "https://github.com/Anomity-ai", "https://www.wikidata.org/wiki/Q140763940" ], "logo": { "@type": "ImageObject", "url": "https://anomity.ai/icon-512.png" } }, "mainEntityOfPage": { "@type": "WebPage", "@id": "https://anomity.ai/blog/deadbugz-runtime-gated-mcp-metadata-poisoning/" }, "image": { "@type": "ImageObject", "url": "https://anomity.ai/assets/blog/covers/mcp-servers.jpg", "width": 1200, "height": 630 }, "articleSection": "Insights", "url": "https://anomity.ai/blog/deadbugz-runtime-gated-mcp-metadata-poisoning/" } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "name": "What is Deadbugz?", "acceptedAnswer": { "@type": "Answer", "text": "Deadbugz is the name used in Pillar Security and Cloud Security Alliance coverage for a campaign that plants MCP servers whose tool metadata stays clean during early review and then changes after a runtime call-count gate. The point of the gate is to defeat one-time human or scanner review that only inspects the first tools/list response." } }, { "@type": "Question", "name": "How does the call-count gate work?", "acceptedAnswer": { "@type": "Answer", "text": "Per Pillar/CSA reporting, the malicious MCP server served benign tool listings for the first three calls. After that threshold, later tools/list responses introduced poisoned tool descriptions and instructions. A reviewer who connected once, listed tools, and approved the server never saw the post-gate metadata." } }, { "@type": "Question", "name": "How is Deadbugz different from earlier MCP tool poisoning?", "acceptedAnswer": { "@type": "Answer", "text": "Classic tool poisoning, as in the Invariant Labs disclosure covered in Anomity's MCP tool poisoning advisory, hides instructions in tool descriptions from the start. Deadbugz adds a temporal dimension: the poison is withheld until after review pressure drops. Both abuse the fact that MCP clients inject server-supplied tool metadata into model context." } }, { "@type": "Question", "name": "Was there a CVE?", "acceptedAnswer": { "@type": "Answer", "text": "No. Deadbugz is tracked as a campaign and research note, not as a CVE against a specific upstream package version. Defenders should hunt for the delivery PRs, the onrender.com endpoint, and runtime tool-metadata drift rather than waiting for a CVE match in a scanner." } }, { "@type": "Question", "name": "Did any of the zellkernel PRs merge?", "acceptedAnswer": { "@type": "Answer", "text": "Reporting states that none of the 23 pull requests merged through ordinary GitHub review. That is good news for the targeted repos and bad news for anyone who assumes PR volume alone equals impact - the interesting control failure is review that would have approved a still-benign first tools/list." } }, { "@type": "Question", "name": "What should security teams do about runtime-gated poisoning?", "acceptedAnswer": { "@type": "Answer", "text": "Stop treating install-time MCP review as a one-shot decision. Continuously compare tools/list metadata against the approved snapshot, inventory which endpoints connected to which MCP URLs, and evaluate resulting tool calls at the agent hook with allow, deny, or log. A server that changes its tool surface after three calls should page someone." } } ] } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://anomity.ai/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://anomity.ai/blog/" }, { "@type": "ListItem", "position": 3, "name": "Deadbugz - Runtime-Gated MCP Metadata Poisoning Evades One-Time Review", "item": "https://anomity.ai/blog/deadbugz-runtime-gated-mcp-metadata-poisoning/" } ] } ```