The MCP Security Audit Nobody Wanted to Read (82% Path Traversal)

There's a number in this series I've been saving, because it's the one that undercuts the celebration in every other article: a 2026 security audit of more than 2,600 MCP servers found 82% vulnerable to path traversal and 67% vulnerable to code injection. It got serious enough attention that it drew a U.S. government security advisory. Read against the registry growth, the download counts, and the Linux Foundation governance handoff, this is the article that says: yes, and also, most of what got built is dangerous.

Both numbers deserve to be sat with rather than skimmed past. Path traversal means a server can be tricked into reading or writing files outside the directory it was supposed to be confined to — a classic, decades-old vulnerability class that a competent security review catches immediately. Code injection means a server can be tricked into executing arbitrary code supplied by an untrusted input. These aren't exotic, protocol-specific flaws unique to MCP's design. They're the oldest mistakes in software security, and finding them in the majority of a 2,600-server sample says something uncomfortable about how that sample got built.

Why this happened, and why it wasn't really a surprise

MCP servers are, structurally, a security-sensitive category of software by design: they exist specifically to give an AI model the ability to take actions — read files, call APIs, run commands, touch databases. That's the entire value proposition of a tool server. It also means every MCP server is, by construction, a piece of software whose job is to accept instructions from an untrusted-ish source (a model interpreting user intent) and turn them into real-world side effects. That's precisely the profile of software that needs rigorous input validation, sandboxing, and least-privilege design from day one.

Now overlay that requirement onto how the registry actually grew, covered in more depth in this series' registry piece: thousands of servers built fast, by individual developers or small teams, published to a low-friction public registry, often as weekend projects or quick wrappers around an existing API. A protocol whose core function requires security discipline grew fastest in exactly the population least likely to have security review built into its process. That combination doesn't need malice to produce an 82% vulnerability rate. It just needs speed without process, at scale.

What this says about the registry's trust model

This is the uncomfortable follow-on to the registry piece in this series: registry presence was never a security signal, and the audit numbers prove it in the starkest possible terms. Nearly 10,000 servers, more than 950 of them serious business-application tooling — and a sample of 2,600-plus showing the majority carrying two of the most basic vulnerability classes in the book. A registry that verifies "this server implements the MCP spec correctly" is answering a completely different question than "this server is safe to grant filesystem or code-execution access to." MCP's registry, as of this audit, was really only answering the first one.

That's not a unique failure of MCP's governance — most package registries across the software industry have the same limitation, npm and PyPI included, and have dealt with their own long histories of malicious or careless packages slipping through. It's still worth naming plainly rather than letting the impressive adoption numbers paper over it.

What a safe MCP server actually looks like

The fix isn't complicated in principle, even though it's tedious in practice — which is exactly why it gets skipped under time pressure. A safe server validates and canonicalizes every file path before touching the filesystem, rejecting anything that resolves outside an explicit allowed directory, rather than trusting a path string handed to it by a model. A safe server never passes model-supplied input directly into an interpreter, shell command, or eval-equivalent without strict allowlisting of what's permitted — the exact discipline that prevents code injection, and the exact discipline that a rushed weekend build is most likely to skip. A safe server runs with the minimum permissions its actual function requires, so that even a successful exploit is contained rather than catastrophic. None of this is novel security engineering. It's the same checklist that's applied to any software accepting untrusted input and taking real actions — MCP servers just make the stakes of skipping it unusually direct, because the whole point of the server is to let an AI act.

Why this matters more, not less, given how fast MCP grew

It would be easy to read this audit as evidence against everything else in this series — that the adoption story is hollow because the ecosystem is insecure. I'd push back on that framing. Fast growth in a security-sensitive category reliably produces exactly this kind of audit result; it happened with early web frameworks, early npm packages, early cloud IAM configurations, and early mobile app permissions models. The pattern isn't unique to MCP. What matters is what happens next: whether the ecosystem treats an audit like this as a wake-up call that changes how servers get built and vetted, or as a headline that gets cited once and forgotten.

The Agentic AI Foundation's stateless rewrite, covered elsewhere in this series, shows a governance body willing to make real architectural changes in response to operational pain. A security-hardening push — better default scaffolding in the SDKs, a trust-tier system in the registry, security review as a gate for the business-application category — would be the equivalent move on the security side. It hasn't fully happened yet as of this writing. Whether it does is arguably a bigger determinant of MCP's next year than any download or registry number in this series.

Why a government advisory changes the conversation

The audit's findings didn't stay contained to a security researcher's report — they were significant enough to draw a U.S. government advisory on MCP security, the kind of attention that only accumulates around a technology already assumed to be load-bearing infrastructure rather than a niche developer curiosity. That's worth sitting with as its own signal, separate from the vulnerability percentages themselves. Government security advisories aren't issued reactively for protocols nobody depends on; they're issued when enough critical infrastructure, government contractors, or regulated industries are plausibly exposed that the risk crosses a threshold worth a formal warning.

Read that way, the advisory is almost a backhanded compliment to everything else in this series — MCP's adoption numbers, the registry's growth toward 9,652 servers, and the 950-plus business-application wave all had to be real and significant enough for a security failure inside the ecosystem to become a matter of national infrastructure concern rather than a niche GitHub issue. The uncomfortable version of that compliment is that the same growth that made MCP worth government attention is also what makes an unresolved 82% vulnerability rate genuinely dangerous rather than merely embarrassing.

The practical takeaway

If you're a builder rather than a spectator, this audit is the single most actionable piece of research in the whole series: assume any MCP server you didn't build or formally review is running with these odds against it until proven otherwise. That assumption should shape everything about which servers you're willing to grant real permissions to — which is exactly the subject of the next article in this series.

Part of the "MCP One Year In" series on aiskill.market.