Security Audit Finds RCE Risks in 6.2% of MCP Servers

6.2% of production MCP servers expose direct Remote Code Execution vectors to LLMs. Here’s how we found them.

We spent the last two decades teaching developers to sanitize database inputs. We printed posters about “Little Bobby Tables” and built massive SAST industries to catch SQL injections before they hit production.

Fast forward to 2026. We are now building Agentic AI workflows using the Model Context Protocol (MCP). By exposing local filesystems, databases, and APIs to AI agents, we are effectively giving Large Language Models (LLMs) the “hands” to execute actions in the real world.

But in our rush to build autonomous agents, are we forgetting the fundamental rules of Application Security?

To answer this, we ran an automated static analysis audit using open-source scanner, Veritensor, across the official punkpeye/awesome-mcp-servers directory. We specifically looked for missing Human-in-the-Loop (HitL) confirmations, dangerous OS/Code execution patterns, and the “Lethal Trifecta” of Agentic AI (Private Data + Untrusted Input + Exfiltration).

The results are concerning. Out of 2,023 successfully cloned MCP servers, 6.2% (125 repositories) contain direct pathways for Remote Code Execution (RCE), unauthorized database mutations, or data exfiltration.

:::tip
The full anonymized dataset of these findings is available on GitHub.

:::

Here is a deep dive into the current threat landscape of Agentic AI tools, backed by data.

The 2026 MCP Security Landscape

During the audit, Veritensor extracted AST and configuration data from the repositories, identifying a total of 10,994 unique AI tools exposed to LLMs.

🔬 Risk & Vulnerability Metrics

Vulnerability Prevalence: 6.2% (125 out of 2,023 clones contain at least one security risk).
Tool Blast Radius: 3.9% (427 out of 10,994 exposed AI tools lack proper safety rails).
Total Findings: 500 (Individual AST node matches indicating severe architectural flaws).

📈 Severity Breakdown

🔴 CRITICAL (200): Immediate RCE, Lethal Trifecta configs, and Hardcoded Secrets.
🟠 HIGH (167): Unrestricted File Writes and DB Mutations without confirmation.
🟡 MEDIUM (41): Potential Data Exfiltration vectors.
🔵 LOW (92): Environment Secret Access.

Top Threats Breakdown

Instead of abstract risks, here is exactly what developers are exposing to LLMs:

The 3 Architectural Failures in MCP Servers

Our analysis revealed that developers are treating LLMs as trusted users rather than untrusted inputs. Here are the three most common architectural failures discovered in the wild.

1. Unfettered OS Command Execution (The `kubectl` Problem)

The most alarming trend is the direct exposure of the subprocess module to the LLM without any confirmation gates.

The Reality: A Kubernetes MCP server that wraps kubectl is not inherently wrong—it’s incredibly useful. However, exposing tools like kubectl_apply, delete_resource, and exec_in_pod to an LLM without a confirmation gate means a single prompt injection can delete production deployments. Across dozens of production-grade infrastructure MCPs, tools are executing subprocess.run() directly based on agent input.

The Threat: If an attacker performs an Indirect Prompt Injection via an uploaded document (e.g., a PDF processed by the agent), they can instruct the LLM to invoke these tools with malicious arguments. Without a Human-in-the-Loop (HitL) require_confirmation flag, the agent will silently execute arbitrary shell commands on the host machine.

2. Unrestricted Database Mutations

We found numerous servers designed to act as SQL or NoSQL interfaces (e.g., PostgreSQL explorers, cloud database connectors).

The Threat: These servers expose tools like execute_sql, drop_database, and create_table using raw cursor.execute() calls. While reading data is generally safe, allowing an autonomous agent to execute DROP or UPDATE queries without human approval is a recipe for disaster. A hallucinating model or a poisoned prompt can irrevocably destroy production databases in seconds.

3. Environment Secret Access

We detected 92 occurrences where tools read sensitive environment variables (e.g., via os.environ.get()).

The Threat: While these variables aren’t always returned directly to the user, they are loaded into the tool’s execution memory. If an agent is directed to dump its context or error logs via a prompt injection (a common jailbreak technique), it can easily leak AWS keys, database credentials, or API tokens directly to the attacker.

How to Secure Your MCP Servers

The era of “wrapper scripts” is over. If you are deploying MCP servers in a corporate environment, you must adopt an Agentic DevSecOps posture.

Enforce Human-in-the-Loop (HitL): Never expose subprocess, os.system, shutil.rmtree, or SQL mutation tools directly to the agent. Always implement a confirmation interceptor that requires human approval before execution.
Scrub Your Environment Variables: Pass only the strictly necessary credentials to the MCP server, and never allow tools to blindly read the entire os.environ dictionary.
Implement Static Analysis for Agents: Traditional SAST tools look for SQL injections in your code. You need tools that look for over-privileged tools in your AI configuration.

Check Your Own Server in 60 Seconds

We built Veritensor—an open-source AI artifact scanner—specifically to catch these exact agentic vulnerabilities (AST parsing for missing confirmation gates, Lethal Trifecta detection).

You don’t need to send your code anywhere. You can audit your MCP server locally right now:

# 1. Install the scanner
pip install veritensor

# 2. Scan your MCP server directory (AST parsing for code risks)
veritensor scan ./your_mcp_server_directory/

# 3. Audit your Claude Desktop config (Permission & Trifecta analysis)
veritensor scan ./claude_desktop_config.json

If the scanner returns a CRITICAL or HIGH alert, you have tools exposed without confirmation gates.

As we move from RAG to Autonomous Agents, the blast radius of a compromised LLM expands from data leakage to infrastructure takeover. It’s time we start securing the tools we give them.