Cybersecurity researchers have discovered a critical “by design” weakness in the Model Context Protocol (MCP) architecture that could pave the way for remote code execution (RCE) and, consequently, trigger a cascading effect across the artificial intelligence (AI) supply chain.
“This flaw enables Arbitrary Command Execution (RCE) on any system running a vulnerable MCP implementation, granting attackers direct access to sensitive user data, internal databases, API keys, and chat histories,” OX Security researchers Moshe Siman Tov Bustan, Mustafa Naamnih, Nir Zadok, and Roni Bar said in an analysis published last week.
Systemic Vulnerability Across MCP SDK
Moreover, the cybersecurity company confirmed that the systemic vulnerability exists within Anthropic’s official MCP software development kit (SDK) across all supported languages, including Python, TypeScript, Java, and Rust. Overall, the issue impacts more than 7,000 publicly accessible servers and software packages, totaling over 150 million downloads.
At the core of the issue, unsafe defaults in MCP configuration—specifically over the STDIO (standard input/output) transport interface—enable attackers to exploit the system. As a result, researchers identified 10 vulnerabilities across widely used projects such as LiteLLM, LangChain, LangFlow, Flowise, LettaAI, and LangBot:
- CVE-2025-65720 (GPT Researcher)
- CVE-2026-30623 (LiteLLM) – Patched
- CVE-2026-30624 (Agent Zero)
- CVE-2026-30618 (Fay Framework)
- CVE-2026-33224 (Bisheng) – Patched
- CVE-2026-30617 (Langchain-Chatchat)
- CVE-2026-33224 (Jaaz)
- CVE-2026-30625 (Upsonic)
- CVE-2026-30615 (Windsurf)
- CVE-2026-26015 (DocsGPT) – Patched
- CVE-2026-40933 (Flowise)
Four Exploitation Vectors Identified
These vulnerabilities fall into four major categories, each enabling remote command execution on the server:
- Unauthenticated and authenticated command injection via MCP STDIO
- Unauthenticated command injection via direct STDIO configuration with hardening bypass
- Unauthenticated command injection via MCP configuration edits through zero-click prompt injection
- Unauthenticated command injection through MCP marketplaces via network requests, triggering hidden STDIO configurations
“Anthropic’s Model Context Protocol gives a direct configuration-to-command execution via their STDIO interface on all of their implementations, regardless of programming language,” the researchers explained.
“As this code was meant to be used in order to start a local STDIO server, and give a handle of the STDIO back to the LLM. But in practice it actually lets anyone run any arbitrary OS command, if the command successfully creates an STDIO server it will return the handle, but when given a different command, it returns an error after the command is executed.”
Interestingly, researchers have reported similar vulnerabilities over the past year, all rooted in the same core issue. These include:
- CVE-2025-49596 (MCP Inspector)
- CVE-2026-22252 (LibreChat)
- CVE-2026-22688 (WeKnora)
- CVE-2025-54994 (@akoskm/create-mcp-server-stdio)
- CVE-2025-54136 (Cursor)
However, Anthropic has declined to modify the protocol’s architecture, citing the behavior as “expected.” While some vendors have issued patches, the core shortcoming remains unresolved in the MCP reference implementation. Consequently, developers continue to inherit significant code execution risks.
Mitigation Strategies for Developers
Therefore, these findings highlight how AI-powered integrations expand the attack surface. To mitigate the threat, experts recommend:
- Blocking public IP access to sensitive services
- Monitoring MCP tool invocations
- Running MCP-enabled services in a sandboxed environment
- Treating external MCP configuration inputs as untrusted
- Installing MCP servers only from verified sources
“What made this a supply chain event rather than a single CVE is that one architectural decision, made once, propagated silently into every language, every downstream library, and every project that trusted the protocol to be what it appeared to be,” OX Security said. “Shifting responsibility to implementers does not transfer the risk. It just obscures who created it.”
Source: TheHackerNews
Read more at Impreza News
