A security team spent five months quietly hacking some of the biggest names in AI. They broke into the production servers of six real companies with real paying customers. Took over thousands of servers across 200+ popular open-source projects on GitHub. Uploaded fake malware to 9 out of 11 app stores that developers use to install AI tools, and nobody caught it.
Then they traced all of it back to one place. Anthropic's code.
They told Anthropic. Anthropic said two words.
By design.
OX Security published the full research a few days ago. They called it "The Mother of All AI Supply Chains." And those two words.. by design.. is important.
Because this isn't a hacker finding a bug. It's a hacker finding a door. A door that was put there on purpose, left unlocked on purpose, and the builder saying it's working exactly as intended.
So what is MCP?
MCP stands for Model Context Protocol. Anthropic built it in November 2024. And the idea behind it was genuinely good.
LLMs are powerful but trapped. They can't talk to your databases, your files, your APIs on their own. Every developer was writing custom code for every integration. It was hectic.
MCP was Anthropic's answer. One universal protocol. Plug and play. Write the connector once, use it everywhere.
And it took off. The Python SDK alone crossed 73 million downloads. FastMCP did 22 million. LiteLLM did 57 million. Tens of thousands of repositories depend on it. Cursor, VS Code, Windsurf, Claude Code, Gemini-CLI.. every AI coding tool you've heard of supports it.
Basically, it's everywhere now. If you've used an AI coding tool in the last year, you've used MCP whether you knew it or not.
And last November, a team of security researchers at OX started looking at it.
Here's what they found.
When an MCP adapter wants to talk to a local server, it runs a command. That command is supposed to start the server. If it works, great. If it doesn't, you get an error.
Simple enough.
But, even when the server fails to start.. the command has already run.
That's the whole vulnerability.
If someone hands the adapter a command like "touch /tmp/this_server_was_pwned", no server starts. You get an error. But the file already exists. The command already executed. Damage done.
It's the order of operations. The adapter runs the command first, then checks if a valid server came back. By the time it knows something's wrong, the damage is already done.
And this same logic exists in every MCP SDK Anthropic ships. Python. TypeScript. Java. Kotlin. C#. Go. Ruby. Swift. PHP. Rust.
All ten of them.
How bad is this really?
Really bad.
The OX team found 30+ critical vulnerabilities across different projects. Got 10+ CVEs rated Critical or High. They ran live command execution on Letta AI's production servers. On LangFlow's. On four others.
They bypassed Flowise's input filter in a single step using an npx flag. And Flowise had actually tried to defend against this one. Their defense didn't hold.
They scanned the public internet. Found 7,374 vulnerable MCP servers sitting exposed. Estimated 200,000+ more are likely exposed but not indexed yet.
Then they uploaded a proof-of-concept malicious MCP to 11 popular marketplaces just to see what would happen. 9 accepted it. No review. No checks.
Every vulnerability they found traces back to the same root. The "command runs even when it fails" behavior baked into Anthropic's protocol.
Cursor, VS Code, Windsurf, Claude Code, Gemini-CLI.. all of them let AI coding agents modify your local MCP config file. Which means.. if you ask your agent to fetch some docs from a website, and that website has a hidden prompt injection tucked inside.. the agent can silently add a new MCP server to your config. That server runs whatever command the attacker put in. On your machine.

Arnold Schwarzenegger has a newsletter.
Yeah. That Arnold Schwarzenegger.
So do Codie Sanchez, Scott Galloway, Colin & Samir, Shaan Puri, and Jay Shetty. And none of them are doing it for fun. They're doing it because a list you own compounds in ways that social media never will.
beehiiv is where they built it. You can start yours for 30% off your first 3 months with code PLATFORM30. Start building today.
The 'by design' part
When the researchers reported all of this to Anthropic, here's what Anthropic said.
"This is an explicit part of how stdio MCP servers work and we believe that this design does represent a secure default."
LangChain said: application author's responsibility to sanitize. FastMCP said: stdio spawning a subprocess is in the spec, not a vuln. Google said: known issue, no fix planned. Microsoft said: works as designed, trust your workspace.
Five different vendors. Same answer. Different wording.
Because technically? They're right.
The MCP spec says STDIO transport spawns a local subprocess that runs a command. That's what it does. If a developer wires their app to let random user input become that command without sanitizing it first.. yeah, that's a developer mistake. Classic one.
But there's a second thing going on here.
Anthropic isn't just putting a spec document online and walking away. They wrote the actual SDK. In ten languages. And that SDK has been downloaded over 150 million times. Most developers aren't reading the spec and implementing MCP from scratch. They're doing pip install and calling the function the docs tell them to call.
And that function runs whatever command you pass it. That's the default.
The researchers found 30+ projects downstream where this blew up. These are real teams shipping real products. They used the SDK the way it's documented, and their servers got popped.
The researchers also told Anthropic how to fix it. They had actual proposals, not just complaints. One was a manifest model where the adapter only runs commands that were pre-declared somewhere safe. Another was a basic allowlist that blocks stuff like sh and bash by default. There was also an "allow_unsafe_local_execution" flag idea, where you'd have to explicitly opt in to the dangerous behavior. And a signing system for the marketplaces so randoms can't just upload malware.
Any one of these, done once inside Anthropic's SDK, would have quietly fixed every downstream project on the planet. Nobody would have had to patch anything.
Anthropic declined.
Anthropic owns a huge chunk of the AI stack right now. They build the model. They ship the protocol everyone connects through. They build Claude Code. They write the safety posts.
I'm not complaining about that. I'd rather it be them than a random startup that'll vanish in a year.
But owning the stack isn't just about getting to build it. What happens on it is yours too.
Right now, that burden sits on every developer wiring MCP into their product. Every indie dev shipping a side project over the weekend. Every startup that trusted the defaults. And downstream of them, every end user whose API keys and chat histories and database credentials are sitting behind an adapter that will happily run any command handed to it.
The fix exists. The disclosure was clean. The researchers waited five months before going public.
The protocol still ships the same way today.
What do you think? When infrastructure gets this big, this fast, and sits this deep in everything AI touches.. who should actually be on the hook?
If you made it this far, you're not a casual reader. You actually think about this stuff.
So here's my ask. If this article made you think, even a little, share it with one person. Just one. Someone who's in the AI space. Someone who reads. Someone who would actually sit with these ideas instead of scrolling past them.
That's how this newsletter grows. Not through ads or algorithms. Through you sending it to someone and saying "read this."



