The State of MCP Security 2026: What 24,008 Exposed Secrets and Eight Public Incidents Tell Us About a Maturing Threat Surface
PipeLab's State of MCP Security 2026 is the first comprehensive defense-coverage grading for the MCP ecosystem. 24,008 exposed secrets. 82% path-traversal vulnerability rate. Eight named in-the-wild incidents. The numbers describe a category that has outgrown its own tooling.
PipeLab published the first comprehensive State of MCP Security report at the end of April 2026. The report is the first attempt to do for MCP what the Verizon DBIR does for breaches generally and what Snyk’s State of Open Source Security does for software supply chain: a defense-coverage grading anchored in incident counts, exposure statistics, and a named vulnerability framework.
Reports of this kind serve a specific function. They convert a category that has been described in narrative form — individual disclosures, vendor blog posts, conference talks — into a corpus that can be benchmarked, compared, and tracked over time. The first such report for any ecosystem is also the moment the ecosystem can stop arguing about whether the threat is real and start arguing about which defenses actually cover it. PipeLab’s report performs this function for MCP.
The headline numbers are stark, and they are useful as a baseline. The mechanics behind them — how the report measures defense coverage, what categories of attack are accounted for, where the existing tooling falls short — are the part of the report worth reading carefully.
The Numbers
The exposure statistics describe an ecosystem that has been deployed faster than it has been instrumented. PipeLab scanned public GitHub repositories for MCP configurations and found 24,008 unique secrets exposed in the configurations themselves. Of those, 2,117 were still valid at the time of the scan — keys that had not been rotated, not been revoked, and not been moved out of the configuration since they were committed.
The implementation-level statistics are similarly direct. Eighty-two percent of analyzed MCP server implementations were vulnerable to path traversal. Sixty-seven percent were susceptible to code injection in some form. The path traversal number is not a random sampling artifact; it appears in the report because path traversal has been the most common pattern in the in-the-wild MCP CVEs of the past twelve months. The statistic measures how systematically the pattern recurs across the ecosystem.
The incident timeline gives the same picture in narrative form. Eight major in-the-wild events between April 2025 and early 2026, all named, all linked to specific code or product:
The Invariant Labs tool poisoning disclosure in April 2025 established that hidden instructions embedded in tool descriptions could enter the agent’s trusted context and influence behavior without the user’s awareness. The same month produced the WhatsApp MCP rug-pull demonstration, which showed that tool definitions could be modified after admission, causing the agent to call tools with semantics different from the ones it had been authorized for. In May 2025, GitHub MCP prompt injection research demonstrated that a malicious GitHub issue could hijack a widely-used GitHub MCP server through the issue’s description field.
In August 2025, the MCPoison vulnerability in the Cursor IDE (CVE-2025-54136) showed that a persistent code execution path existed through unvalidated MCP server configurations — code that ran every time the IDE started, with whatever capabilities the host shell had. In September 2025, the postmark-mcp npm backdoor became the first confirmed in-the-wild malicious MCP server distributed through a package registry; it reached approximately 300 organizations before disclosure and silently exfiltrated emails for the duration of its deployment.
Early 2026 produced a three-CVE chain in the Anthropic mcp-server-git package — path traversal plus argument injection chained for full RCE (CVE-2025-68143, 68144, 68145). The same period saw filesystem MCP escapes in the reference implementations (CVE-2025-53109/10) and a wave of compromised client tooling and developer libraries (MCPJam, mcp-remote). And in April 2026, the OX Security STDIO research established that the standard MCP transport mechanism executes operating-system commands before handshake validation across every Anthropic MCP SDK — a finding Anthropic confirmed and described as expected behavior.
Each entry in this list is a separate research effort, a separate disclosure, and a separate set of CVE assignments. Cumulatively, they describe a year in which the MCP threat surface was discovered, demonstrated, and weaponized in roughly equal measure. The report’s defense-coverage grading is the section that takes the next step: given this threat surface, what does today’s tooling cover?
Three Defense Camps
PipeLab’s grading separates the existing MCP defense tooling into three categories and asks how much of the OWASP MCP Top 10 each one addresses.
The first camp is network allowlisting. Tools in this category — gh-aw-firewall, iron-proxy, and similar — operate at the network layer. They block agents from making outbound connections to destinations that have not been explicitly approved. The architecture is well-understood; it is the same architecture that has secured enterprise egress for two decades. The limitation that PipeLab calls out is content: a network allowlist cannot inspect what is being sent to or received from an approved destination. A tool poisoning attack that arrives through a permitted MCP server is invisible to the network layer.
The second camp is MCP gateways. This is where the bulk of recent enterprise tooling has clustered. Docker MCP Gateway, Runlayer, the various commercial entrants — they centralize the routing of MCP traffic, add authentication, and enforce policies on the traffic they see. The defense improvement over network allowlisting is significant: the gateway speaks MCP, not just HTTP, and can apply method-level controls on tool discovery, tool invocation, and prompt access. The limitation that PipeLab identifies is scope: gateways protect the servers that have been configured into them. Servers that have not been configured into the gateway — because they were added by a developer, or because they were installed as a transitive dependency of another tool — are outside the gateway’s coverage.
The third camp is runtime inspection. Pipelock, Cisco’s mcp-scanner, Snyk’s recently announced agent-scan, and Invariant’s mcp-scan all sit in this category. They inspect MCP servers and their tool descriptions for poisoning, hidden instructions, suspicious patterns, and known-bad signatures. The defense value is real — these scanners catch what a gateway alone cannot — but the deployment shape is detection rather than prevention. They tell the operator that something is wrong; they do not, by themselves, stop the agent from acting on it.
PipeLab’s grading produces an explicit conclusion: no single defense tool in any of the three camps covers all OWASP MCP Top 10 categories effectively. The implication is not that any individual tool is failing — most of them do their named job competently — but that the threat surface is broader than the assumptions any one tool was built against. A complete defense requires architectural coverage spanning multiple camps.
The OWASP MCP Top 10 as the Reference Frame
PipeLab anchors its grading against the OWASP MCP Top 10, which is itself a 2026 development worth a paragraph of its own. The Top 10 (currently in beta, led by Vandana Verma Sehgal and hosted on the OWASP project page) is the first formal vulnerability framework specifically scoped to MCP. The categories are:
| Risk | Where it lives | |
|---|---|---|
| MCP01 | Token Mismanagement & Secret Exposure | Configuration, deployment |
| MCP02 | Privilege Escalation via Scope Creep | Tool design, runtime |
| MCP03 | Tool Poisoning | Tool description, manifest |
| MCP04 | Software Supply Chain Attacks | Distribution, registry |
| MCP05 | Command Injection & Execution | Server implementation |
| MCP06 | Prompt Injection via Contextual Payloads | Content layer |
| MCP07 | Insufficient Authentication & Authorization | Transport, server |
| MCP08 | Lack of Audit and Telemetry | Observability layer |
| MCP09 | Shadow MCP Servers | Inventory, admission |
| MCP10 | Context Injection & Over-Sharing | Memory, context |
The Top 10’s value is not that it identifies novel risks — every entry on the list has been seen in the wild — but that it normalizes the vocabulary. A vendor claiming defense coverage can now be measured against a shared reference: which categories does this tool actually address? PipeLab’s defense-camp grading is the first systematic application of that reference, and the report’s strongest contribution is making the gaps legible.
A separate dev.to analysis published the same month (Kenimo49, “38% of MCP Servers Have No Auth”) provides the corroborating measurement at the server level. Of more than 500 MCP servers scanned, 38% had no authentication of any kind — no token, no OAuth, no identity check. CVE-2026-30623 reached CVSS 9.6, the highest severity in the current MCP CVE corpus. A 142x token-amplification denial-of-wallet attack was demonstrated against MCP servers that did not bound their context windows. Each of these findings maps to a specific OWASP MCP Top 10 category, and each is consistent with PipeLab’s broader picture: the ecosystem has shipped servers faster than it has reviewed them.
What “Servers Published Faster Than Reviewed” Means Architecturally
The structural root cause that PipeLab’s report identifies, in one phrase, is that MCP servers are published faster than they are reviewed. This is the supply-chain version of the same problem that produced the postmark-mcp incident, the path traversal CVE wave, and the OX Security STDIO findings. The package registries, the GitHub repositories, and the ecosystem-level marketplaces all admit servers at a rate that exceeds the rate at which any review process can keep up.
The classical answer to this problem in software supply chain is signed manifests, reproducible builds, and distribution-layer attestation. Those are necessary, and the MCP ecosystem will eventually develop them. They are not sufficient on their own, because the agent that consumes the server still has to make a decision about whether to use it — and the agent’s environment is the place where the consequences of that decision propagate.
The architectural gap that the report keeps circling, without quite naming it as such, is the absence of a default-deny posture at the agent’s boundary. The standard deployment shape across the ecosystem today is that an MCP server, once installed, can serve tool calls. The act of installation is the implicit admission. There is no default state in which the server is present but cannot be invoked, awaiting human review.
A default-deny posture changes the shape of the supply-chain problem. It does not stop bad servers from being published. It does not stop them from being installed. What it does is decouple admission from installation: the server can be present without being callable, and the question of whether to make it callable is a separate human decision that occurs after a review of the manifest, the tool descriptions, and the server’s declared scope. The eight in-the-wild incidents PipeLab catalogues all share the property that they reached production action because installation alone authorized invocation. Decoupling those two events is the architectural change that closes the gap.
This is also the property that satisfies the audit requirements that the same report gestures toward. PipeLab’s recommended 2026 baseline includes “centralized audit logging with credential redaction” — language consistent with the EU AI Act Article 12 logging requirement that takes effect August 2, 2026. An audit log that records every admission decision, every quarantine block, and every approved invocation is the natural complement to a default-deny posture. The two together are the supply-chain answer.
Where the Numbers Point
The most useful part of any State-of report is the part that becomes a baseline. The 24,008-secret figure is a baseline. The 82% path-traversal rate is a baseline. The eight named incidents are the start of a curated incident corpus. A year from now, the same report will be able to say whether the numbers improved, whether the incident count rose or fell, and whether the defense camps consolidated their coverage of the OWASP Top 10.
What the current numbers describe is a category that has the threat surface of mature infrastructure software and the defense posture of a category that is still six months from maturity. The threat surface is not exotic. Path traversal, injection, hardcoded credentials, malicious packages — these are problems with thirty-year-old playbooks in the rest of the software industry. What is novel is the agent layer that sits on top of the surface and acts on it autonomously, with capability scopes that no security review has bounded.
The closing of the gap between threat surface and defense posture is what 2026 is about for MCP. PipeLab’s report is the first measurement of where the gap currently is. The next year of work is what closes it.