A number you shouldn't take at face value - and why it holds up anyway
Start with the sourcing, because it matters for how to read this. In the two months before the Anaconda acquisition, Enkrypt AI scanned 25,000 MCP servers with 268,000 tools in total and found more than 143,000 vulnerabilities - 73 percent of servers affected. That figure appeared in the same press release announcing the company's own acquisition. A company demonstrating how dangerous the landscape is, then getting bought two months later for exactly that capability: the setup deserves scepticism by default, regardless of whether the number ultimately checks out.
It does check out - just not solely on the word of the interested party. Equixly's own testing found 43 percent of servers checked vulnerable to command injection and 30 percent to SSRF (server-side request forgery, where a server is tricked into making requests to targets it shouldn't be able to reach). Endor Labs examined 2,614 MCP implementations and found 82 percent using file operations vulnerable to path traversal - a flaw where an attacker uses manipulated file paths to reach areas outside the intended directory. BlueRock Security assessed more than 7,000 servers and found SSRF vulnerabilities in 36.7 percent. An academic study (Hasan et al.) found a tool-poisoning prevalence of roughly 5.5 percent across 1,899 servers. Trend Micro initially discovered 492 MCP servers publicly reachable on the internet with zero authentication or encryption in July 2025; a recount later found the number had grown to 1,467.
Five independent research groups, different methodologies, different samples - and consistently double-digit to high-double-digit percentages of servers with serious vulnerabilities. The specific figure of 143,000 may have been marketing timing. The underlying problem is not.
Why this isn't a new AI risk - it's an old one in a new place
The genuinely notable finding isn't the frequency, it's the nature of the flaws. SSRF, path traversal, missing authentication: these aren't exotic, AI-specific attacks. They're the same basic web and API security mistakes that security training has covered for roughly twenty years - poorly validated input, open endpoints without access control, trusting path parameters that should have been checked. They're not this common in MCP servers because AI agents are inherently less secure than other networked software. They're this common because a new protocol got implemented by a very large number of teams in a short time, under pressure to ship a new feature - and, in the process, repeated the same mistakes the security industry observes with every new, fast-growing interface technology.
That framing isn't downplaying the issue. It's actually the reason the problem is comparatively solvable: these are known failure classes with known countermeasures, not a new category of risk requiring solutions to be invented from scratch. Treating MCP servers like any other network-reachable API - authentication, input validation, access restriction - closes most of the gaps found.
The one attack type that genuinely is new - and stays invisible to old scanners
One category on the list deserves different treatment: tool poisoning. Every MCP tool ships with a description - prose that tells the language model what the tool does and when to use it. That description is itself an attack surface. A manipulated description can carry hidden instructions the model follows without any human ever seeing them - for instance, an instruction to additionally perform some unrelated action every time the tool runs.
The reason this isn't just another recurrence of old mistakes: classic security scanners check code - syntax, known vulnerability patterns, data flows. A tool description is natural-language text, not code, and its effect only unfolds inside the language model interpreting it. A scanner looking for classic patterns fundamentally has nothing to find here - the flaw lives in meaning, not syntax. This is the part of the problem that genuinely needs new inspection methods, not familiar ones.
A real incident, not a thought experiment
How concrete this can get is shown by an already-documented case from the software supply chain. In September 2025, security firm Snyk identified a tampered version of the popular postmark-mcp package. The modified version behaved normally from the outside - processing emails as expected - while additionally BCC'ing a copy of every single processed message to an external address in the background. Anyone who had wired the package into an existing automation wouldn't have noticed the leak, because the actual function kept working normally. That is exactly the pattern security researchers describe for tool poisoning: unremarkable behaviour on the surface, one additional, unauthorised action underneath.
The number of officially documented vulnerabilities also confirms this isn't a handful of lab findings. JFrog's security team disclosed a flaw in July 2025 that, by its own account, affected over 437,000 environments. Check Point separately documented a vulnerability dubbed 'MCPoison'. In a single 60-day window in early 2026 alone, more than 30 further CVEs were reported against MCP implementations, roughly 43 percent of them command-injection patterns - the same failure type Equixly found in its own scans.
What the Anaconda acquisition itself reveals about the market
Separate from the individual figure, the acquisition itself is a signal. Anaconda is folding Enkrypt's tooling - pre-deployment red-teaming across more than 300 attack categories, runtime guardrails, compliance automation for NIST frameworks and the EU AI Act - directly into its platform. That's telling: MCP security is no longer being treated as a specialist topic for security researchers, but as a standard component a platform vendor has to ship to be usable in regulated industries at all. For your own assessment, that means: once platform vendors are already building this into their compliance automation, it isn't a niche risk you can defer.
What this means in practice
The value of this analysis isn't warning you off MCP - the protocol became the standard for good reason, because it solves the structured problem of connecting AI agents to your own systems that every integration previously had to solve individually. The point is to treat MCP servers with the same care as any other network-reachable interface in your organisation - not as a configuration detail you set up once and forget.
- Inventory: which MCP servers are actually in use across the company - including ones individual teams set up without central sign-off? At most companies this list is longer than IT or security leadership expects.
- Classic hardening first: authentication on every server, input validation, no publicly reachable endpoints without access control. Per the studies cited above, this closes most of the real-world gaps found.
- Treat tool descriptions like code: before putting an MCP tool into production, check what it actually claims to do in its description - and repeat that check on updates to a package already deployed, not just at first install.
- Vet provenance: apply the same supply-chain caution to externally sourced MCP packages (e.g. from public registries) as to any other third-party dependency - the Postmark case shows this exact vector has already been exploited.
And in fairness about our own sourcing: this analysis doesn't rely on a single, interest-driven figure from one vendor, but on a consistent picture across six independent studies. That independence is exactly what turns a press release into a finding worth acting on.