MCP, the Model Context Protocol, is how AI tools like Claude, Cursor, and Windsurf connect to everything else. Want your coding assistant to read your database, open tickets, or deploy to the cloud? You install an MCP server for it.
That's great for productivity. It also means every MCP server you add is a piece of someone else's code running on your machine, or your server, with whatever access you gave it. If that sounds like the npm problem all over again, it's because it is.
The flaw in the plumbing
In April, OX Security published research on how MCP's local (STDIO) mode starts servers. It launches a command. If user input can reach that configuration, an attacker can make it launch their command instead.
OX says this affects the official MCP SDKs in Python, TypeScript, Java, and Rust, with more than 150 million downloads and up to 200,000 vulnerable instances. Those are OX's estimates. The research led to CVEs in about ten tools, including LiteLLM, Windsurf, Flowise, and DocsGPT.
According to OX and The Hacker News, Anthropic declined to change the protocol and called the behavior "expected." Its position is that sanitizing input is the developer's job. You can argue about whether that's fair. Either way, the practical result is the same: the safety of every MCP setup depends on whoever built it getting that right.
Servers with no lock on the door
MCP servers can also run over the network instead of locally. Last year Trend Micro went looking and found 492 MCP servers on the internet with no client authentication and no encryption. Together they exposed 1,402 tools, and more than 90% of those tools gave direct read access to the data behind them. At least 8 could manage cloud resources directly.
So for those servers, anyone who found them could ask, in plain English, for whatever data was connected.
And when someone forgets one endpoint
The cleanest example this year is CVE-2026-33032 in nginx-ui, a web tool for managing nginx. Its MCP integration had two endpoints. One checked for a login. The other only checked an IP allowlist, and the default allowlist was empty, which the code treated as "allow everyone."
The result, rated CVSS 9.8: anyone could rewrite nginx configs and restart the server. It was fixed in version 2.3.4 in March, and it's been exploited in the wild. Researchers counted about 2,600 instances reachable from the internet.
Nobody set out to build a backdoor. Someone bolted on an AI feature and missed one line of auth. That's how most of these happen.
How to use MCP sanely
- Know what's installed. Check the MCP config in every AI tool your team uses. You may be surprised how many servers are in there.
- Only install from sources you trust. Treat an MCP server like any dependency. Who maintains it? Is it still updated? Pin the version.
- Give it the smallest key that works. Read-only database user. Scoped API token. Not your admin credentials, and definitely not production if you only need staging.
- Don't put MCP servers on the network without auth. If it doesn't need to be remote, run it locally. If it does, put real authentication and TLS in front of it.
- Never let outside input reach the config. If you're building a product that lets users add MCP servers, that config is a command line. Treat it like one.
- Update the tools that use MCP. Most of the CVEs above have patches. They only help if you install them.
The bottom line
MCP isn't going away, and it shouldn't. It's useful. But we spent ten years learning that installing random packages with full access is a bad idea, and it would be nice not to spend another ten learning it again for AI tools.
If you've shipped an AI feature in your app, especially one that connects to tools or data, it's worth having someone try to break it. Start with the free scan, then get a pen test that covers the AI parts too.