About the Author
This article was written by Ahmar Imam with over a decade of combined experience in threat intelligence, identity protection, and incident response. Ahmar is a founder of D3C Consulting, where his team monitors emerging attack campaigns daily and works directly with enterprise security teams and individual consumers to mitigate data breach risks.
Reviewed by: Senior Threat Intelligence Analyst | Certified Information Security Professional (CISSP) | Identity Management expert
What Is Mcp Server Security?
MCP stands for Model Context Protocol. It’s the connector that lets AI tools like Claude, Cursor, and GitHub Copilot reach out and take real actions, read a file, run a command, call an app.
MCP server security means checking that connector for weak spots. Think of it like a lock on a door. MCP was built to open doors fast for AI agents. It was not built to make sure only the right people walk through them. That job was left to whoever built the server.
This gap is new, and it’s growing fast. MCP only launched in November 2024. In under two years, it went from a niche protocol to the default way AI agents connect to tools. Security has not kept up.
Why Your Mcp Server Needs A Dedicated Scanner
The Numbers Tell The Story
MCP grew fast. By late 2025, the ecosystem saw over 97 million monthly downloads of its software kits, and more than 10,000 public MCP servers were live. Every major AI tool, Claude, ChatGPT, Cursor, Gemini, Microsoft Copilot, now supports it.
But most servers were never checked for basic safety. Here’s what researchers found:
- 43% of tested MCP servers were vulnerable to command injection (an attack where a hacker sneaks commands into normal-looking input).
- 82% of 2,614 servers checked had file-handling code open to path traversal (an attack that lets someone read files they shouldn’t).
- 38–41% had no login check at all, anyone who found the server could use it.
- 36.7% of over 7,000 servers were open to SSRF, an attack that tricks a server into fetching data from places it shouldn’t.
New security bugs are showing up fast, too. Researchers reported over 30 confirmed vulnerabilities in MCP servers in just the first two months of 2026, and more than 40 by April. One report estimated 200,000 vulnerable servers exposed on the public internet.
Meanwhile, few companies have caught up on the people side of this problem. Only about 23% of organizations have a formal plan for managing AI agent identities. Only 14.4% of AI agents get full security sign-off before going live.
Why A Normal Security Scanner Won’t Catch This
Most security scanners were built to check websites and apps the old way. MCP works differently. Many MCP servers run commands through something called STDIO, which spawns processes on the computer to get things done. That’s powerful, and risky, if the input isn’t checked first.
Anthropic, the company behind MCP, has said that checking this input is up to each server’s developer, not something the protocol handles for you. That leaves a big gap. A normal scanner might tell you a port is open. It won’t tell you that the server behind that port will run any command a hacker sends it.
A scanner built for MCP checks the things that matter here: missing logins, unsafe commands, unsafe file access, leaked secrets, and newer attack types like “tool poisoning,” where a hacker hides bad instructions inside a tool’s description.
Common Vulnerabilities Found In Mcp Servers
Vulnerability | Why it happens | What research found |
No login required | MCP doesn’t force authentication by default | 38–41% of servers tested had none |
Command injection | Servers run commands without checking input first | 43% of tested servers were vulnerable |
Path traversal | File tools don’t block access outside allowed folders | 82% of 2,614 servers checked were at risk |
SSRF (server tricked into fetching bad data) | Tools that fetch URLs don’t limit where they can go | 36.7% of over 7,000 servers checked were vulnerable |
Leaked secrets in config files | API keys get saved in plain text instead of a secrets manager | Over 24,000 exposed secrets found in MCP config files in one 2026 study |
Tool poisoning | AI agents trust tool descriptions by default | Seen in real attacks against the WhatsApp MCP Server and others |
Case Study: The Mcp-Remote Hack That Put 437,000 Developers At Risk
This is the clearest real-world example of what can go wrong. It’s also the first confirmed case of a hacker taking full control of a computer through a remote MCP server.
What Mcp-Remote Does
MCP-Remote is a small but popular tool. It acts as a bridge, letting AI apps like Claude Desktop, VS Code, and Cursor connect to MCP servers that live somewhere else. By mid-2025, it had been downloaded more than 437,000 times. Big companies, Cloudflare, Hugging Face, Auth0, even recommended it in their own setup guides.
What Happened
- July 9, 2025: JFrog’s security research team, led by researcher Or Peles, published a warning about a serious bug in mcp-remote, tracked as CVE-2025-6514. It affected every version from 0.0.5 to 0.1.15.
- Same day: The bug was rated 9.6 out of 10 for severity, about as bad as it gets. A fix shipped right away, in version 0.1.16.
- In the months after: Researchers found the same type of bug being used against other tools, including Letta AI, LangFlow, and Flowise. This wasn’t a one-time fluke. It was a pattern.
Image suggestion, Case study timeline: Simple left-to-right timeline graphic: July 9, 2025 disclosure → same-day fix → later attacks on Letta AI, LangFlow, Flowise. Helps readers follow the story visually and is a strong fit for “what happened” style AI answers. Alt text: “Timeline of the mcp-remote security vulnerability, July 2025” File name: mcp-remote-cve-timeline.png
How The Attack Worked
When mcp-remote connects to a server, that server sends back a web address as part of the login process. The bug: mcp-remote took that address and ran it as a command on the computer, without checking it first.
A hacker could send a fake or unsafe address instead of a real one, and mcp-remote would run it. That’s a full takeover of the computer, not just a data leak.
There were two ways this could happen in the real world:
- A user connects straight to a malicious MCP server.
- A user connects to a real server, but over an unsafe connection (plain HTTP instead of HTTPS). An attacker on the same network steps in the middle and swaps in a bad address instead.
The second path was flagged as the more likely danger inside company networks, where local servers often get trusted without a second thought.
The Damage
A 9.6 severity score means an attacker didn’t need a password or any special access, just a user connecting to the wrong server. Because mcp-remote sat between trusted AI tools and the servers they talked to, and because it had been recommended by name in official guides from major platforms, the risk touched real companies, not just hobby projects.
How It Got Fixed
JFrog followed standard practice: they told the mcp-remote maintainers first, waited for a fix, and published the full details once version 0.1.16 was ready. Their advice was simple: update right away, don’t connect to MCP servers you don’t trust, and always use HTTPS, never plain HTTP.
Unlike a single company fixing a bug in its own app, this fix depended on every team using mcp-remote finding out about the warning and updating on their own. That’s slower, and riskier, than fixing one product in one place.
What Appsec Teams Should Learn From This
- The connector matters, not just the server. This bug lived in a bridge tool, not in an obviously risky place.
- A vendor’s recommendation isn’t a security check. Big platforms suggested mcp-remote in their docs. That built trust in the tool, but it had nothing to do with whether the code was safe.
- This is a pattern, not a one-off. The same type of bug later showed up in other tools. Fixing one product doesn’t fix the underlying design problem.
- Weak defaults make things worse. The attack was easier over plain HTTP. Requiring HTTPS everywhere, even inside your own network, closes off a whole attack path.
How The Scanner Works
- Point it at your server. Give it a URL, a repo, or connect your MCP inventory.
- It runs a full check. The scan looks for missing logins, unsafe commands, exposed files, leaked secrets, and known attack patterns like tool poisoning.
- You get a graded report. Every finding is ranked (critical, high, medium, low) with a clear next step to fix it.
10-Point Checklist To Secure Your Mcp Servers
- List every MCP server you’re running, local and remote, official and third-party.
- Shut down or isolate any server you’re not actively using.
- Require a login on every MCP server. Don’t assume “local” means “safe.”
- Use HTTPS for every MCP connection, even inside your own network.
- Treat every connector tool, like an OAuth bridge, as code that needs its own security review.
- Check and clean any input before it reaches a command line or shell.
- Limit which web addresses your tools are allowed to fetch data from.
- Store API keys in a secrets manager, never in a plain text config file.
- Re-scan every time you update a server or a connector tool.
- Keep watching your tools after approval, don’t just check them once and forget.
Conclusion
MCP didn’t get less safe this year. It just grew faster than the safety checks around it. That’s the real story behind every stat here: tens of thousands of servers with no login, most of them open to basic attacks, and a trusted connector tool that put nearly half a million developers at risk without anyone noticing for months.
The mcp-remote story matters because it wasn’t some random, untested project. It was a tool that major companies recommended by name. And the fix depended on every single team finding out and updating on their own, the kind of quiet, ongoing risk that a one-time security check will always miss.
If you’re running MCP servers, the fastest way to know where you stand is to scan them.
