An Open-Source Tool Scanned 14 MCP Servers. 100% Had Critical Findings.
MCPwn hit every server it scanned. OX Security disclosed a systemic STDIO flaw across 200,000 instances. Anthropic declined to patch. Here's what the receipts actually say.
Two weeks ago I wrote about how the industry built agents and skipped the foundations. The security layer came after the deployment. Most people nodded and moved on.
This is what that looks like with receipts.
What researchers found when they actually scanned MCP servers
MCPwn is an open-source security scanner built specifically for MCP server configurations. They ran it against 14 servers and published the supply chain analysis last week. Before that, they scanned 12 popular servers in April and found 58 security findings across all 12 repositories. 100% hit rate.
The numbers from the 14-server supply chain scan:
- CVE-2026-33032, CVSS 9.8, actively exploited. Full nginx server takeover in two HTTP requests with no authentication. 2,600+ exposed instances.
- mcp-atlassian had two CVEs chained: SSRF plus arbitrary file write. Two requests, unauthenticated root access. The package has 334,000 downloads per week and one maintainer with a commitment score of 42 out of 100.
- mcp-remote OAuth connector had OS command injection via OAuth discovery fields. 558,000+ downloads. Supply chain depth of 11 nodes, 5 critical.
- Flowise had authenticated RCE traced back to
google-auth-libraryin the critical dependency path. That package has 44 million downloads per week and one maintainer.
The pattern MCPwn found across all 14 servers: every exploited server scored below 55. Every exploited server had a single maintainer or fewer than three.
This is not a set of edge cases. A separate scan of 32 community MCP servers found 97% had security findings. 75% had critical vulnerabilities. A 700-server ecosystem scan from March found the same pattern at scale: unmaintained packages, hardcoded credentials, zero CI security tooling across the board.
The supply chain problem nobody is talking about
Individual CVEs are fixable. The supply chain structure is not.
When a widely-used MCP server has a dependency tree 11 nodes deep with 5 critical nodes, and one of those critical nodes is maintained by a single person handling 44 million downloads per week, you do not have a bug. You have a trust model that was never designed for production systems handling credentials, filesystem access, and live API calls.
Most developers installing an MCP server are looking at the top-level package. They are not auditing the full dependency chain. Nobody told them to. The tooling to do it easily did not exist until MCPwn built it.
The packages in these dependency trees are real infrastructure. They are being pulled into agents that have SSH keys, database credentials, and write access to production codebases. The attack surface is not theoretical. Someone already proved it.
What it looks like when it goes wrong
In March 2026, a security researcher hacked McKinsey’s internal AI platform with no credentials and no insider knowledge. Full read/write production database access in two hours. The entry point was an MCP integration.
No zero-day. No advanced persistent threat. An exposed MCP server with lity MCPwn is now finding at scale.
The architectural problem Anthropic won’t patch
OX Security published a full advisory on April 14 documenting a systemic flaw in MCP’s STDIO architecture. Not a single server bug. The protocol itself.
STDIO command injection enables RCE across an estimated 200,000 exposed instances and 150 million downloads. They identified four distinct exploitation families: unauthenticated UI injection, hardening bypasses in protected environments like Flowise, zero-click prompt injection in Windsurf and Cursor, and registry poisoning. They successfully poisoned 9 of 11 MCP registries with a test payload to prove the vector was real.
They filed 30+ responsible disclosures. 10+ high and critical CVEs against individual projects.
Anthropic’s response: they declined to patch the protocol architecture. STDIO execution is expected behavior. Sanitization is the developer’s responsibility.
That sentence changes everything about how you should think about using MCP in production. The organization that designed the protocol, reviewed the research, and saw the exploitation results decided the root cause stays in. Every fix from here is a patch on top of an unpatched foundation.
What to actually check before shipping an MCP integration
If you are building with MCP servers right now, here is what the research says to verify:
- Run MCPwn against your configuration before it ships. It is open source and takes minutes.
- Check maintainer count and commit score on every direct dependency. Single maintainers on high-download packages are the specific failure mode MCPwn found in every exploited server.
- Audit dependency chain depth. Anything beyond 5 nodes with no security scanning in CI is a liability you have not priced in.
- Do not assume “widely used” means “audited.” The 558,000-download OAuth connector had command injection in a field that processes external input. Downloads are not a proxy for security review.
- Scope MCP server permissions to the minimum needed. Filesystem access, credential stores, and production API keys should not be in the same trust boundary as an MCP server with an unreviewed dependency tree.
The broader picture has not changed from what I wrote two weeks ago. The industry shipped the capability first and is finding the infrastructure gaps now. MCP is where that gap is most visible rightnow.
The protocol is not going away. The attack surface will keep growing. The people who audit before they ship will be in a different position than the ones who find out the hard way.
Written by Nirav Joshi · Fullstack and Blockchain Developer
Newsletter
Want the next post like this?
Subscribe for occasional emails when I publish something worth your time.