Threat · curated 20 Jul 2026
Deadbugz: Currently Active MCP Supply-Chain Campaign
First reported · updated · 4 reports appsentinels.ai
Coverage timeline
Why it matters
The Deadbugz campaign shows that a single untrusted MCP server can compromise an entire agent by poisoning tool descriptions and hijacking other trusted connectors, making every organization running MCP-connected agents part of the exposed supply chain.
The "Deadbugz" campaign is an active MCP supply-chain operation in which malicious Model Context Protocol servers (such as the zellkernel/productivity-suite-mcp package) embed hidden instructions in tool metadata to hijack trusted tools connected to an AI agent, enabling data exfiltration like reading .env files or SSH keys. The campaign leverages cross-tool poisoning, where one poisoned MCP server can abuse other trusted connectors already wired into the agent, and is tied to a malicious GitHub account and associated threat-actor persona.
Summary
The fenced material describes 'cross-tool poisoning,' an attack class against AI agents that use the Model Context Protocol (MCP). A malicious MCP server embeds hidden instructions in its tool metadata (description or input schema); when an agent loads its tool list, those instructions hijack the agent into misusing other, trusted MCP servers to read sensitive files or exfiltrate data. The malicious server never touches the data itself—it borrows the permissions of servers already trusted by the user.[0]
The technique is grounded in published proof-of-concept and academic research rather than a specific in-the-wild campaign detailed in the available bodies: Invariant Labs demonstrated both a poisoned calculator tool and a WhatsApp cross-server exfiltration PoC, Palo Alto Unit 42 documented additional injection vectors through MCP sampling, and an arXiv paper (ETDI) frames Tool Poisoning and Rug Pull as inherent weaknesses of the standard MCP specification. The core problem is that MCP assumes connected servers are benign and validates almost nothing, making an agent only as secure as its least-trustworthy connector.[0][5][19]
The primary source is a vendor-authored guidance article (Coograph) that recommends structurally reducing the MCP attack surface and highlights its own read-only, local, open-source code-graph MCP server as an example of a low-risk profile. The dossier is titled after a 'Deadbugz' MCP supply-chain campaign reported by Pillar Security, but that campaign is present only as an external reference without body evidence to ground its specifics.[0][2]
Attack chain
- Poisoned tool onboarding: A user wires multiple MCP servers into an AI agent, including one obtained from a marketplace whose tool description contains hidden instructions invisible in typical agent UIs.[0]
- Metadata-based injection: When the agent's LLM loads the tool list, it reads the full tool description/input schema including the buried directive, unlike the human approver who sees only a short benign summary.[0]
- Cross-server hijack: The hidden instruction directs the agent to invoke a separate, legitimate server (e.g., a WhatsApp or Slack connector) to read sensitive data and route it outbound, borrowing the trusted server's permissions.[0]
- Exfiltration through a trusted channel: Data such as .env contents, source code, or message history leaves the environment disguised as normal outbound activity, which logs may record as legitimate.[0]
Disclosure timeline
| Date | Event |
|---|---|
| 2025-06-02 | arXiv paper (ETDI) documenting Tool Poisoning and Rug Pull attacks in the MCP specification submitted.[19] |
| 2025-12-05 | Palo Alto Unit 42 published research on new prompt injection attack vectors through MCP sampling.[5] |
| 2026-06-30 | Coograph published its cross-tool poisoning explainer and guidance article.[0] |
How it works
Each MCP server advertises tools with a name, description, and input schema, all of which the agent's LLM reads to decide what to call. The description field is the attack surface: attackers embed malicious instructions in this metadata rather than in returned data. Because most agent UIs do not display metadata, a human approver sees a harmless summary ('Adds two numbers') while the LLM reads the full text including a hidden directive to read secrets like ~/.ssh/id_rsa.[0]
Cross-tool poisoning escalates this: because all connected servers share the same agent context, a poisoned server's description can instruct the agent to act through a different, legitimate server it does not itself have permissions for—demonstrated by Invariant's PoC where a malicious server targeted a separate whatsapp-mcp server to exfiltrate message history to an attacker number.[0]
MCP sampling widens the gap: a server can request LLM completions back through the client, allowing it to inject hidden prompts, persist instructions across a session, or covertly invoke tools such as writeFile without the user seeing anything but their expected answer.[0][5]
Beyond metadata injection, the MCP specification is also susceptible to Rug Pull attacks, where a tool's definition can change after it has been vetted, and tool squatting; the ETDI proposal counters these with cryptographic identity verification, immutable versioned tool definitions, and policy-based access control.[19]
Affected versions and patch status
| Product | Affected | Patch status |
|---|---|---|
| Model Context Protocol (MCP) ecosystem and agent clients | Clients such as Cursor were found highly susceptible to cross-tool poisoning in independent 2026 testing; Claude Desktop shipped stronger guardrails. The standard MCP specification validates connected servers minimally and is subject to Tool Poisoning and Rug Pull attacks. | No specific patch identified; sources recommend structural mitigations and protocol extensions (e.g., ETDI) rather than a single fix.[0][19] |
Key takeaways
- An AI agent is only as secure as the least-trustworthy MCP server connected to it, because all connected servers share the same context and a poisoned one can act through the permissions of trusted servers.[0]
- The dangerous part of a tool poisoning attack is deliberately hidden in metadata that agent UIs do not show, so 'inspecting harder' fails; risk must be reduced structurally through fewer, read-only, local, open-source, version-pinned servers.[0]
- This is a supply-chain and procurement problem, not just an engineering one: exfiltration through an authorized channel can register as normal activity and become a compliance/breach event.[0]
Defensive actions
- Connect fewer, purpose-scoped MCP servers: Every connected server is a trust decision and a slice of attack surface; keeping the toolset minimal shrinks the blast radius of any poisoned server.[0]
- Prefer read-only, local, and open-source MCP servers: Read-only servers cannot write files or send data and cannot act as an exfiltration channel; local execution keeps code and secrets off third-party clouds; open-source tool descriptions are publicly auditable so hidden instruction blocks have nowhere to hide.[0]
- Pin versions and review tool descriptions and input schemas: Treat MCP servers like dependencies: pinning prevents a server from silently changing its tool descriptions after vetting (a Rug Pull), and reviewing raw metadata (not just the README) is the only way to catch hidden directives that UIs never display.[0][19]
- Inventory every connected MCP server and identify which can write or send data: Organizations often cannot name every MCP server wired into their agents; maintaining a manifest of connectors and their write/outbound capabilities is prerequisite to reducing the attack surface.[0]