OX Security uncovers critical RCE, API theft, and file read vulnerabilities in popular MCP tools affecting 140k+ GitHub stars.
CVE-2025-65719 and CVE-2025-69443
TL;DR: The OX Research team discovered three vulnerabilities — two in widely used open-source MCPs and one in Archon OS, an open-source AI management platform. Two were assigned CVEs: CVE-2025-65719 and CVE-2025-69443. A third was rejected by Microsoft as working as intended.
Collectively representing over 140k GitHub stars and 60k DockerHub downloads, these vulnerabilities expose organizations to data exfiltration, credential theft, and lateral movement – discovered as a direct extension of OX’s broader MCP security research.
Potential Damage: Data exfiltration, Lateral movement, Credentials & API keys theft exposing sensitive data.
Research Findings
| CVE ID | Extension Name | Popularity | Vulnerability | Affected Versions | Link |
| CVE-2025-65719 | kubectl-mcp-server | 10k DockerHub downloads | Arbitrary code execution on a victim system via user interaction with a crafted HTML page | > v1.2.0 | GitHub |
| CVE-2025-69443 | Archon OS | 20.9k Stars | Unauthenticated API key theft via CORS bypass. | All versions | GitHub |
| No CVE issued | MarkItDown | 50k DockerHub downloads 121k Stars | Arbitrary local file read vulnerability. | All versions | GitHub |
Read our full technical analysis:
Why It Matters
These findings extend OX Security’s broader MCP research initiative, which uncovered a systemic, design-level vulnerability in Anthropic’s MCP STDIO implementation — a flaw that propagated silently through downstream AI agent frameworks, developer IDEs, and MCP marketplaces, exposing an estimated 150 million downloads to risk.
That research, published as The Mother of All AI Supply Chains, put a name to something the industry had been circling without fully articulating: the MCP protocol, by design, creates a trusted execution surface with no authentication, no sandboxing, and no blast radius awareness — and the tools built on top of it are inheriting that risk at scale. The vulnerabilities documented here are a direct extension of that picture.
MCPs bridge the communication gap between AI and APIs — and that connectivity is exactly what makes them a target. A single compromised MCP in your stack doesn’t need to be a complete attack vector on its own. It can serve as a foothold: elevating privileges, harvesting API keys and session cookies, poisoning LLM context, and operating largely undetected while threat actors move laterally through your environment.
The integration layer is not a secondary concern. It is the attack surface.
Recommendations
- Avoid opening untrusted HTML while localhost servers are running.
- Install only trusted MCPs from official vendors and marketplaces.
- Block any public IP access to your local services and MCPs
- Execute MCPs only inside a closed permissions scope.
- Check if the open source tools you are using conduct penetration testing and are following security’s best practices.
General Best Practices for protecting your MCPs and AI Agents:
- Enforce the Principle of Least Privilege Execute MCPs and AI agents only within closed, containerized environments or restricted permission scopes. Never grant an MCP broad access to your entire file system; isolate it to specific directories to prevent arbitrary file reads or system-wide compromises.
- Harden Local Network Entry Points Block all public IP access to your local services and use a strictly configured firewall. Ensuring that localhost servers are truly local prevents attackers from using CORS bypasses or DNS rebinding to turn your development machine into a gateway for remote command execution.
- Implement Strict API Key Governance Never hard-code or paste sensitive API keys into open-source configurations. Utilize environment variables or dedicated secret management tools, and ensure every key is scoped with IP restrictions and the absolute minimum permissions required for the task.
Responsible Disclosure
kubectl-mcp-server
We contacted the Kubectl MCP Server maintainers on Nov 9, 2025. Maintainer responded on Jan 28, 2026 that the vulnerability is now patched.
Archon OS
We contacted the Archon team via GitHub on Nov 24 and Dec 22, 2025. They dismissed the issue, responding:
“This is meant to just be a local app right now, I am aware of these things once we support deployments!”
MarkItDown MCP
We contacted Microsoft Security Response Center (MSRC) on 8-Dec-2025. Microsoft responded, sending to the project’s documentation, adding that: “this behavior is working as designed and does not represent a security vulnerability. Markitdown runs with the same privileges as the user who starts the process – it does not elevate permissions at any stage.
Authentication is not built into the service, and this is clearly documented. The recommended (and default) configuration binds the service to 127.0.0.1, ensuring that only local processes can connect”.
Conclusions: systemic misunderstanding
The vulnerabilities discovered in these widely adopted MCPs and AI Agents – collectively downloaded and starred by hundreds of thousands of developers – expose a critical blind spot in the rapidly evolving AI infrastructure, while the integration layer remains a largely unprotected gateway.
The dismissive response from some maintainers, citing that these tools are “meant to be local,” underscores a systemic misunderstanding of the modern developer’s environment, similar to what we’ve seen in our Massive Security Blind Spot in IDE Extensions research, and in our MCP research – open source maintainers are shifting responsibility for their tool’s security management onto users.
Security must be integrated at the integration layer – not treated as an afterthought.
