Vulnerability in Anthropic’s MCP allows remote code execution and threatens AI supply chain
A critical vulnerability in the Model Context Protocol (MCP) is putting the entire artificial intelligence supply chain at risk — and the worst part is that the problem didn’t come from a careless programming error, but from a deliberate design decision.
Researchers at OX Security identified the flaw directly in Anthropic’s official SDK — the company behind Claude. That means the problem isn’t in some third-party plugin or a poorly done configuration by a developer. It’s in the base code that everyone uses as a reference. 😬
And the numbers are a bit scary:
- More than 7,000 public servers exposed
- More than 150 million downloads affected
- Well-known projects like LiteLLM, LangChain, LangFlow, Flowise, LettaAI, and LangBot on the list of impacted tools
The flaw enables remote code execution (RCE) on any system running a vulnerable MCP implementation, giving attackers direct access to sensitive data, API keys, conversation histories, and internal databases.
It’s no exaggeration to say this is one of the most concerning scenarios for anyone working in cybersecurity within AI environments right now.
And Anthropic’s response to all of this? Well, it surprised a lot of people — and not in the way you’d expect. 👇
What MCP is and why it matters so much
The Model Context Protocol is essentially the glue that connects artificial intelligence models to external tools, databases, APIs, and enterprise systems. Think of it this way: if the language model is the brain, MCP is the nervous system that lets that brain interact with the world around it.
It was created by Anthropic to standardize how AI assistants communicate with external resources, and it quickly became one of the most widely adopted standards in the AI development ecosystem. The idea was solid — having a single, well-documented protocol maintained by a reputable company in the space.
Receive the best innovation content in your email.
All the news, tips, trends, and resources you're looking for, delivered to your inbox.
By subscribing to the newsletter, you agree to receive communications from Método Viral. We are committed to always protecting and respecting your privacy.
The problem is that the more a standard spreads, the bigger the impact when something goes wrong with it. And that’s exactly what happened here. The massive adoption of the Model Context Protocol by projects like LiteLLM, LangChain, LangFlow, and Flowise turned a single flaw into a problem of massive scale. Each of these projects has its own user bases, its own production environments, and its own integrations with critical systems. When they all drink from the same compromised well, the blast radius multiplies exponentially.
Another important point is understanding that MCP is not some obscure or experimental technology. It’s already running in real production environments, in companies of all sizes, connected to systems holding sensitive customer data, contracts, intellectual property, and much more. The flaw identified by OX Security, therefore, is not a theoretical or lab-only problem. It’s an active vulnerability, with a real attack vector, in systems that are operating right now as you read this.
How the vulnerability works in practice
Now let’s get to the good stuff: the technical mechanism behind this flaw. The problem lies in the insecure defaults of how MCP configuration works through the STDIO (standard input/output) transport interface. In more accessible terms, Anthropic’s protocol offers a direct configuration path to command execution via the STDIO interface across all of its implementations, regardless of the programming language used — whether Python, TypeScript, Java, or Rust.
In simplified terms, this code was designed to start a local STDIO server and hand communication control back to the language model. But in practice, as researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar from OX Security explained, it ends up allowing anyone to execute any arbitrary command on the operating system. If the command successfully creates a STDIO server, it returns normally. If it receives a different command, it returns an error — but only after the command has already been executed. In other words, the damage is done before any error message even shows up.
This means that without needing credentials, without needing to be inside the company’s network, and without leaving obvious traces, a malicious actor can gain access to the application’s execution environment.
What makes this even more serious is the type of data that gets exposed. Applications using the Model Context Protocol are typically connected to rich information sources. API keys for other services, authentication tokens, user conversation histories, connections to internal databases — all of this becomes potentially accessible the moment an attacker can execute code on the server. There’s no need to even perform lateral movement within the corporate network. The very nature of MCP, which was designed to give the model broad access to external resources, ends up acting as an amplifier for the damage caused by exploiting the flaw.
The vulnerabilities discovered and the projects affected
The OX Security investigation revealed 10 specific vulnerabilities, spread across widely used projects in the AI community. All of them fall into four major attack categories:
- Authenticated and unauthenticated command injection via MCP STDIO
- Unauthenticated command injection via direct STDIO configuration, with bypass of protection mechanisms
- Unauthenticated command injection via MCP configuration editing through zero-click prompt injection
- Unauthenticated command injection through MCP marketplaces via network requests that trigger hidden STDIO configurations
The registered CVEs (vulnerability identifiers) include flaws in some pretty well-known projects:
- CVE-2025-65720 — GPT Researcher
- CVE-2026-30623 — LiteLLM (already patched)
- CVE-2026-30624 — Agent Zero
- CVE-2026-30618 — Fay Framework
- CVE-2026-33224 — Bisheng (already patched)
- CVE-2026-30617 — Langchain-Chatchat
- CVE-2026-33224 — Jaaz
- CVE-2026-30625 — Upsonic
- CVE-2026-30615 — Windsurf
- CVE-2026-26015 — DocsGPT (already patched)
- CVE-2026-40933 — Flowise
One detail that stands out is that vulnerabilities based on the same core issue had already been independently reported over the past year. Among them are flaws in MCP Inspector (CVE-2025-49596), LibreChat (CVE-2026-22252), WeKnora (CVE-2026-22688), @akoskm/create-mcp-server-stdio (CVE-2025-54994), and even Cursor (CVE-2025-54136). This shows that the problematic pattern had been showing warning signs for a while, but nobody connected the dots until now. 👀
Anthropic’s response and what it reveals about the AI ecosystem
This is where the story gets really divisive within the cybersecurity community. When notified about the vulnerability, Anthropic refused to modify the protocol’s architecture. The company classified the behavior as expected — meaning, in Anthropic’s view, MCP is working exactly as it was designed to work.
That stance sparked quite a bit of debate. While some of the affected project vendors have already released fixes for their specific implementations, the flaw remains present in Anthropic’s reference implementation of MCP. In practice, this means developers building new applications using the official SDK continue to inherit the code execution risks without even knowing it.
This situation raises an important discussion about the maturity of the artificial intelligence ecosystem when it comes to cybersecurity practices. AI tool development has advanced at an impressive pace over the past few years, and projects like MCP are a reflection of that. But speed and security often move in opposite directions when there aren’t robust architecture review processes in place before a technology is released for mass adoption.
The vulnerability identified is not the result of an accidental bug but rather a design decision that didn’t adequately account for possible attack vectors in hostile environments. This points to a structural problem that goes beyond MCP and affects how the AI industry thinks — or fails to think — about security from the very beginning of the development cycle.
Why this is a supply chain event and not just another CVE
OX Security made a point of emphasizing something that deserves attention: this is not simply another isolated vulnerability. It’s a supply chain event.
As the researchers themselves put it: a single architectural decision, made once, silently propagated to every supported language, every downstream library, and every project that trusted the protocol was what it appeared to be.
This cascading effect is exactly what transforms a technical flaw into a systemic problem. When an official SDK, maintained by one of the biggest AI companies in the world, carries a design vulnerability that allows remote code execution, every developer who imports that SDK into their project is unknowingly importing the risk as well. And when those projects are in turn used as dependencies by other projects, the problem multiplies exponentially — creating a web of exposure that becomes increasingly difficult to track and remediate.
The OX Security researchers were blunt in their conclusion: shifting responsibility to implementers does not shift the risk. It merely obscures who created it. That sentence sums up the tension that exists today in the artificial intelligence ecosystem when the topic is security accountability.
What to do to protect yourself
For security teams working at companies that have adopted solutions based on the Model Context Protocol, the practical message is clear. The researchers recommend a series of measures that can help mitigate risks while a definitive architectural fix is still pending:
- Block public IP access to sensitive services connected to MCP
- Monitor MCP tool invocations in real time to detect anomalous behavior
- Run MCP-enabled services in a sandbox, isolating them from the rest of the infrastructure
- Treat any external MCP configuration input as untrusted, applying strict validation
- Install MCP servers only from verified sources and maintain tight control over updates
Beyond these immediate defensive measures, it’s worth checking which version of the SDK is in use across each project and verifying whether the specific projects your organization relies on — like LangChain, LiteLLM, LangFlow, Flowise, or any others — have already released patches for the listed vulnerabilities. Three of the affected projects (LiteLLM, Bisheng, and DocsGPT) have already shipped fixes, but the rest remain vulnerable at the time of this analysis’s publication.
Remote code execution is historically one of the vulnerability classes with the greatest potential for real-world damage — and when it shows up in an infrastructure layer as central as MCP, the response effort needs to be proportional to the exposure. 🔒
The takeaway for the AI industry
This discovery by OX Security serves as an important reminder for the entire artificial intelligence ecosystem. The race to ship new protocols, tools, and integrations cannot steamroll the cybersecurity fundamentals that the software industry spent decades building. When a company with the weight and influence of Anthropic defines a standard that gets adopted by thousands of projects and millions of users, the responsibility for that standard’s architectural security cannot be delegated to whoever is at the end of the chain.
Developers building applications with AI need to stay alert to these risks and incorporate security practices from the very start of their projects. And the companies maintaining widely adopted protocols need to treat design vulnerabilities with the same seriousness they treat functional bugs — especially when the attack vector is as powerful as remote code execution.
The world of artificial intelligence is evolving way too fast for security to be treated as a second-tier concern. And this MCP vulnerability is concrete proof that the consequences of ignoring that principle can literally affect millions of systems around the globe.
