By ByteBot
On August 10, 2026, a GitHub account named zellkernel submitted 23 pull requests in 74 minutes — each carrying a malicious MCP server designed to look safe until it wasn’t. That campaign, named Deadbugz, is the clearest proof yet that the MCP trust model is broken for production use. Not “needs improvement.” Broken.
The Deadbugz Attack: How It Actually Worked
The server called itself productivity-suite and offered two reasonable-sounding tools: text formatting and summarization. Any developer reviewing the PR would have seen a harmless helper. That was the point.
After the connected AI agent made exactly three ordinary tool calls, the server changed what it returned. The new instructions weren’t about text formatting. They were about hunting SSH keys and cloud credentials.
This is what Pillar Security’s analysis calls a runtime-gated rug pull: the payload is real and present, just conditionally withheld. A one-time code review — the standard approval gate for most teams — passes every check, because the server genuinely does behave during review. It’s only trusted, integrated, and running in production that it activates.
OWASP already has a category for this: MCP03:2025, listed alongside tool shadowing and description poisoning in the MCP Top 10. Deadbugz is not novel in theory. It is novel in that it was deployed at scale against real projects, in a coordinated 74-minute window.
The Audit Numbers Make It Worse
Deadbugz would be bad enough if it were isolated. It isn’t. A July 2026 research paper titled “Exposed by Design” audited 414 of 640 confirmed production MCP servers and found the following:
- 68 reportable vulnerabilities across SQL injection, SSRF, prompt template injection, and path traversal
- 91.8% of servers had no authentication at all
- 687 tool instances exposed raw shell execution with zero access control
- 41.6% of servers disappeared within three days between measurement runs
That last figure matters more than it looks. Servers that disappear and reappear within three days are being deployed ad hoc, without review, outside any normal release process. They are not being treated like infrastructure. They are being treated like scripts.
Three CVEs That Landed in August
Separate from Deadbugz, three MCP server CVEs dropped in August:
- Path traversal — any authenticated client can read arbitrary files on the server
- Token leak — a settings tool returning cluster tokens in cleartext
- SSRF — classic server-side request forgery, routing requests to cloud metadata endpoints
One of these is CVE-2026-32871 in FastMCP: the _build_url() method substitutes path parameters into URL templates without encoding them, and urllib.parse.urljoin() interprets the resulting ../ sequences as directory traversal. An attacker escapes the intended API prefix entirely and reaches arbitrary backend endpoints.
These aren’t novel attack classes. They are basic vulnerabilities — the kind that would fail a SAST scan — appearing in MCP servers that nobody ran a SAST scan on.
Your IDE Is the Attack Surface
The clients affected by the 2026 MCP vulnerability disclosures include Cursor, VS Code, Claude Code, Gemini CLI, and Windsurf. That covers most of the developer tooling market. A vulnerable MCP server connected to any of these is a path to arbitrary command execution on a developer’s machine — meaning credentials, source code, and whatever cloud access the developer has.
The total exposed instance count from 2026 disclosures sits at approximately 200,000. That is not a niche problem.
What to Do Before Your Next MCP Integration
The mitigations exist. Most teams just haven’t applied them, because MCP integrations are being treated as configuration rather than code. They are code. Treat them accordingly.
- Run an internal curated registry. Developers should only install servers that an administrator has reviewed and approved. One-click installs from a GitHub README are not a supply chain process.
- Isolate every local MCP server in a container or OS-level sandbox with minimal filesystem and network access.
- Enable OAuth 2.1 with PKCE and validate the token audience so you only accept tokens minted for your specific server.
- Allow-list and validate all tool inputs. Block SSRF egress to private IP ranges. Reject
../sequences in any path parameter. - Require human confirmation for any action that is sensitive or irreversible — file writes, credential access, network calls to external services.
- Pin versions and apply patches through normal software supply-chain controls, not manually on developer machines.
The deeper fix is architectural: MCP needs a runtime trust model, not a one-time review gate. The protocol assumes servers are trustworthy after approval. Deadbugz demonstrates exactly why that assumption doesn’t hold. Until the spec evolves, continuous verification — behavior monitoring, anomaly detection on tool call patterns — is the only real defense against rug pull attacks.
If you are running MCP servers in production and have not audited them against the “Exposed by Design” vulnerability classes, you have 68 good reasons to do it this week.
