DEV Community

Eastern Dev
Eastern Dev

Posted on

Your Enterprise Deployed MCP Servers. Has Anyone Audited Them?

#ai #enterprise #security #mcp

Your Enterprise Deployed MCP Servers. Has Anyone Audited Them?

38% of production MCP servers have no authentication. 43% are vulnerable to command execution. Your AI agents are calling tools that nobody has verified are safe.

The State of MCP Security in July 2026

Model Context Protocol (MCP) has crossed from experiment to critical infrastructure:

  • 78% of enterprise AI teams have MCP servers in production (source)
  • 28% of Fortune 500 companies run MCP servers
  • The official registry lists thousands of servers; Smithery alone has 7,000+ installable servers
  • MCP SDK downloads: 400M+ per month

But here's what the adoption numbers don't tell you:

  • In the first 60 days of 2026, 30+ CVEs were reported against MCP deployments (source)
  • Adversa AI scanned 500+ MCP servers in March 2026: 38% had no authentication on critical endpoints, 43% were vulnerable to command execution
  • Microsoft's Azure MCP Server had a CVSS 8.8 SSRF (CVE-2026-26118) that leaked managed identity tokens

If your company has MCP servers in production, the odds are high that at least one of them has a vulnerability that could give an attacker access to your internal systems, cloud credentials, or customer data.

What We Found: 10 Real Vulnerabilities in 24 MCP Server Projects

We built a runtime verification framework called CCS (Correctover Classification Standard) — a 6-dimensional verification model for AI agent tool calls — and used it to systematically audit 24 MCP server projects.

Here's what we found in the ones that had vulnerabilities:

Server-Level Remote Code Execution

Firecrawl (a popular web scraping MCP server): eval() was called directly on user-supplied JavaScript in the scraping pipeline. One crafted request = full remote code execution on the server. CVSS 10.0. (GitHub Issue #4190)

Cloudflare MCP Server: User input passed directly to exec() with zero sanitization. One POST to /exec = arbitrary shell command. CVSS 9.8. Reported via HackerOne.

Cloud Credential Theft

Microsoft markitdown: convert_to_markdown(uri) accepts any URL including http://169.254.169.254 — the cloud metadata endpoint that returns IAM credentials. CVSS 7.5. Reported to MSRC.

Neon MCP Server: run_sql tool accepts arbitrary SQL without statement-level filtering. An AI agent could DROP TABLE, export all data, or create new admin users. CVSS 7.8. Reported to security@neon.tech.

Authentication Gaps

Microsoft markitdown: HTTP mode runs without authentication on non-localhost. Any client on the same network can invoke all tools. CVSS 7.2.

Credential Exposure

MongoDB MCP: Database credentials passed via CLI arguments, visible in ps output to any user on the system. CVSS 5.3.

Neon MCP Server: Connection strings with passwords returned in plaintext responses. CVSS 5.4.

Token Leakage

Apify: API token passed via URL query parameter — exposed in server logs, browser history, and HTTP Referer headers. CVSS 6.5.

The 14 That Were Clean

Not everything we scanned was vulnerable. 14 out of 24 projects had zero confirmed vulnerabilities, including high-profile servers like playwright-mcp (35.3K stars), github-mcp-server, and others.

This isn't a "everything is broken" story. It's a "we now have a systematic way to find what's actually broken" story.

Why This Isn't Just Another Bug Bounty Report

Every vulnerability we found maps to one of CCS's 6 verification dimensions:

Attack Pattern CCS Dimension What It Means
exec()/eval() on tool parameters Structure + Schema Tool call arguments are not validated before execution
Missing authentication Identity No verification of who is making the request
SSRF via unchecked URIs Integrity Input boundaries are not enforced
Credentials in plaintext/logs Cost + Identity Secrets are not protected in transit or at rest

The point is not that we found 10 bugs. The point is that the same verification methodology can be applied to YOUR MCP servers — and will find the same structural patterns.

Independent Validation: Palo Alto Networks Cited CCS in Their Code

On July 29, 2026, Palo Alto Networks' AI Research Lab pushed commit a2e757d to their fork of Microsoft's Semantic Kernel. The commit explicitly cites our CCS framework:

"Records the CCS runtime-verification framework [...] as independent prior public work reaching the same fail-closed and argument-bound-approval conclusions"

When a $20B cybersecurity company's research lab independently cites your formal specification in their source code, that's not marketing. That's technical validation.

CCS was published on Zenodo: DOI: 10.5281/zenodo.21271910 (2026-07-09).

What This Means for Your Enterprise

If your company is deploying MCP servers — whether you built them yourself, adopted them from vendors, or integrated them through platforms like Claude, Copilot, or Cursor — here's what you need to check:

1. Tool Execution Safety

Does every tool handler treat its arguments as data, never as instructions? Check for exec(), eval(), os.system(), and subprocess.run(shell=True) in any code path reachable from a tool call parameter.

2. Authentication

Does every MCP server endpoint require authentication? Not just the "important" ones — every endpoint. Adversa AI found 38% of production servers with no auth at all.

3. Outbound Trust Boundaries

Can your MCP server reach the cloud metadata endpoint (169.254.169.254)? Can it make arbitrary outbound HTTP requests? If yes, an attacker can steal your cloud credentials.

4. Credential Handling

Are database passwords, API keys, or connection strings visible in process listings, logs, or response bodies? Every one of these is a potential data breach.

5. Runtime Verification

Is there a verification boundary between "what the LLM requested" and "what the system executes"? If your agent framework just passes through tool calls without validation, you have no safety net.

6. Manifest Integrity

Has anyone checked whether the tools your MCP server exposes today are the same tools you approved last week? "Rug-pull" attacks — where a server changes its tool definitions post-registration — are a real threat.

What We Offer

Correctover provides runtime verification audits for enterprise MCP deployments. We don't sell a gateway or a proxy. We verify that your agent tool calls are actually safe at the point of execution.

What an audit looks like:

  1. We scan your MCP server codebase using CCS's 6-dimensional verification framework
  2. We identify structural vulnerabilities (command injection, auth gaps, credential exposure, SSRF)
  3. We deliver a prioritized report with CVSS scores, CCS classification, and remediation guidance
  4. Optional: ongoing runtime verification integration with your agent infrastructure

What makes this different from a penetration test:

  • A pen test checks one point in time. CCS verification runs continuously.
  • A pen test finds specific bugs. CCS finds structural patterns — so you can prevent the next 10 bugs, not just fix the current one.
  • CCS is a published standard with 16 DOI-registered specifications, cited by Palo Alto Networks in their production code.

Current availability:
We're taking on a limited number of enterprise audit engagements in Q3 2026. If you're deploying MCP servers in production and want an independent security assessment, reach out.

Evidence & References

Guigui Wang is the founder of Correctover, building runtime verification infrastructure for AI agent systems.
Framework: correctover.com | Contact: wangguigui@correctover.com

Guigui Wang | Correctover — Runtime Verification for Agent Systems

Top comments (0)