Your AI Agent Stack May Have These 16 Vulnerability Patterns

On July 16, 2026, Workato launched its Enterprise MCP Registry: a catalog of more than 60 production-grade MCP servers wrapped in governance controls — centralized audit trails, SOC 2 posture, and per-user identity propagation. The company's CPO framed it bluntly at launch: "protocol alone can't run your business, you need a platform."

The framing is correct, and the market is responding to a real gap. The Model Context Protocol (MCP) standardizes how AI agents discover and call tools, but it does not — and cannot — secure them. A protocol defines a wire format; it does not define trust. After three months of auditing the MCP ecosystem, our team believes the gap is not hypothetical. Here is what we found across 37 MCP repositories and 24 standalone servers, the 16 vulnerability patterns that keep recurring, and the governance checklist we give enterprise security teams.

The data: 37 repositories, 144 advisories, 75 high or critical

We ran three complementary exercises in July 2026.

1. A GitHub Security Advisory audit of 37 MCP repositories — official SDKs (Python, TypeScript, Go, Java), vendor servers (AWS, GitHub, Cloudflare, n8n, Activepieces, OpenMetadata, nginx-ui, siyuan) and ecosystem projects. Total: 144 advisories, of which 75 were rated high or critical. Nineteen of the 37 repositories had zero published GHSA entries at scan time — an audit gap worth noting, because the CVSS 10.0 RCE we confirmed (Firecrawl) shipped in a repository that was still on the zero-GHSA list when we scanned it.

2. A blind test against 24 standalone MCP servers — 5,911 files across projects ranging from 10 to 2,781 stars — produced 94 candidate findings (37 critical, 44 high, 13 medium). Manual review confirmed one exploitable command injection (AgenticX), flagged two as context-dependent, and found that 53 of the 94 (56.4%) were false positives. That false-positive rate matters directly for any team evaluating a scanner; we unpack it in the section on traditional SAST.

3. A cross-project pattern study — 16 systemic vulnerability patterns validated against 6 MCP server implementations. The headline: path traversal appeared in all 6 of 6 targets (100%). Wildcard 0.0.0.0 binding appeared in 4 of 6 (67%); hardcoded secrets in 3 of 6 (50%). Of the 16 patterns, 8 registered at least one hit across the sample.

Four findings from this work have been confirmed and disclosed:

• Firecrawl MCP — eval-based remote code execution, CVSS 10.0 (GitHub Issue #4190)
• Cloudflare MCP — command injection via container_exec, CVSS 9.3 (HackerOne)
• AgenticX — sandbox command injection, HIGH (CVE filed)
• Supabase MCP — wildcard 0.0.0.0 bind, advisory QTVA-2026-10862645

None of these are theoretical.

Risk #1 — Firecrawl MCP: eval-based RCE, CVSS 10.0

The scenario. Firecrawl MCP is widely used to ingest web content into RAG pipelines and knowledge bases. A prompt injection hidden in a crawled page can drive the ingestion side to evaluate attacker-controlled code.

The attack chain. Attacker publishes a page containing an embedded instruction → the crawler fetches it → the injected instruction steers the agent toward a tool_call that reaches the vulnerable eval path → arbitrary code executes on the machine running the crawler, which is the same process holding your vector-database credentials and pipeline secrets.

Who is exposed. Any team running Firecrawl MCP for scraping, RAG collection, SEO, or content pipelines.

Governance action. Treat every crawled page as untrusted input. Run ingestion in an isolated container with no mounted secrets, pin and review the MCP server version, and add a content-policy layer that strips embedded instructions before they reach the model.

Risk #2 — Cloudflare MCP: unsanitized command execution, CVSS 9.3

The scenario. The container_exec tool in cloudflare/mcp-server-cloudflare passes arguments straight to Node's exec(). In apps/sandbox-container/container/sandbox.container.app.ts (line 140):

const proc = exec(execParams.args)   // args is z.string(), no allowlist

The schema defines ExecParams.args as a free-form z.string() with no validation, and the /exec endpoint carries no auth middleware.

The attack chain. LLM agent → MCP container_exec → http://host:${PORT}/exec → exec(args) runs an arbitrary shell command. Combined with the container's file read/write routes, this is data exfiltration, not just sandbox escape.

Who is exposed. Teams deploying Cloudflare MCP on Workers / Durable Objects / R2, plus the developer machines and CI pipelines that run it.

Governance action. Replace exec() with spawn()/execFile() and shell: false; enforce a command allowlist; authenticate the exec route. Add a CI gate that fails on child_process.exec( with non-literal arguments.

Risk #3 — Dify: pickle deserialization plus 41 SQL-injection candidates

The scenario. Dify persists document embeddings with Python pickle in api/models/dataset.py:

return cast(list[float], pickle.loads(self.embedding))

Anyone with database access can replace an embedding field with a malicious pickle payload that executes code at deserialization. Separately, the vector-database plugins (pgvector, Oracle, AnalyticDB) build SQL by f-string concatenation — 41 injection candidates across the plugin set.

The attack chain. Compromised database (or a supply-chain path into it) → attacker writes a crafted pickle into an embedding field → a normal document lookup triggers deserialization → code execution inside the Dify API container.

Who is exposed. Self-hosted or enterprise Dify deployments running knowledge bases, customer-service agents, or low-code LLM apps.

Governance action. Replace pickle with a safe serialization format (json or numpy .npy); audit vector-DB plugin inputs for user-controlled identifiers; keep database credentials least-privilege.

Risk #4 — n8n: sandbox escapes and a privilege-escalation chain

The scenario. n8n's 2026 advisory set (20 advisories, 12 high or critical) includes an expression-sandbox escape via arrow-function bodies that reaches command execution, an authenticated code execution in the Git node, an account takeover via an unverified email claim in token-exchange embed login, and SSO instance-role provisioning that escalates to instance owner.

The attack chain. In a shared multi-user workspace, an expression in a workflow triggers the sandbox escape → arbitrary commands in the task runner → access to the credentials and LLM keys stored in the same platform. The advisory set also covers credential exfiltration via inline sub-workflow JSON from the shared-workflow editor.

Who is exposed. Any organization running n8n workflows — and especially shared multi-user workspaces.

Governance action. Keep n8n patched weekly; restrict who can edit shared workflows; isolate the task runner; treat credentials stored inside n8n as high-value assets for audit logging.

Risk #5 — Tools without a read-only guard: Stripe and Docker

The scenario. Two targets in our pattern study — stripe/ai and QuantGeekDev/docker-mcp — expose tools that can perform destructive operations with no read-only boundary. We verified three instances in stripe/ai (exploitability 65) and the same pattern in Docker's create/stop/remove/exec operations. In the MCP model, a readOnlyHint declaration is advisory: nothing at runtime enforces it.

The attack chain. A prompt injection reaches an agent wired to Stripe MCP → the agent calls a payment or subscription tool that is declared read-only but is not enforced → a real refund or subscription change executes. For Docker MCP, an agent can create, stop, or remove containers — or run arbitrary commands inside them. Docker MCP also had the highest systemic-issue density in our sample (89% of findings systemic) with only 4 source files.

Who is exposed. Payment integrators and Fintech teams routing LLM agents to Stripe; DevOps/MLOps teams letting agents manage containers.

Governance action. Enforce read-only boundaries at runtime, not just in declarations. For Stripe: restrict MCP to read-only operations unless a human approval step is in the loop. For Docker: do not expose container-management tools to shared agents; require explicit scoping.

Why traditional SAST is not enough

The blind-test results illustrate this directly. Our scanner flagged 94 candidate vulnerabilities across 24 projects in minutes. Manual review confirmed 1 and found 53 false positives — a 56.4% false-positive rate, and roughly 40% precision on critical/high findings before manual review. The false positives were not random: PyTorch's model.eval() misread as Python eval() (8.5% of findings); dictionary-key constants misread as hardcoded secrets (21.3%); SQL string-building misread as SQL injection (7.4%); Alembic migration DDL misread as injection (10.6%).

A scanner that ships a 56% false-positive rate across 5,911 files is not a governance platform — it is noise. For an enterprise security team, the pipeline that works is three-stage: (1) L1 syntax-pattern matching for breadth; (2) L2 contextual and semantic filtering to separate real sinks from safe patterns; (3) manual PoC verification on anything that survives. That is the difference between a report and a decision.

A governance checklist for your AI stack

1. Inventory. Enumerate every MCP server and agent tool in production — official SDKs, vendor servers, and especially the 19 zero-GHSA repositories nobody has audited yet.
2. Runtime verification. Static scanning finds patterns; runtime verification proves exploitability. Red-team your highest-privilege tool calls.
3. Enforce read-only at runtime. readOnlyHint is a declaration, not a control. Enforce it, and put destructive tools behind human approval.
4. Treat tool arguments as untrusted input. The fix patterns are boring and proven: execFile over exec, allowlists over regex, parameterized queries over f-strings, shlex.quote on every path interpolation.
5. Map to SOC 2 and audit requirements. Per-user identity propagation instead of shared service credentials, tool-level RBAC, and a centralized audit trail that records who initiated an action, which agent executed it, which systems it touched, and how it was fulfilled.
6. Make it continuous. New MCP servers ship weekly. Governance is a cadence, not a project.

Get a snapshot of your stack

The MCP ecosystem has a hygiene problem that compounds fast: a protocol designed for tool access, adopted at enterprise speed, shipped without the platform layer around it. Workato's registry launch is the market acknowledging that gap. Our audits are the evidence for why it matters.

We verify AI-stack security end to end — from 16 pattern classes down to a confirmed CVSS 10.0 exploit. If you want a starting point, request a free technical-stack snapshot at correctover.com/audit.html and we will send a 48-hour PDF covering your exposed MCP surface, the patterns that apply to your stack, and a fix-priority list.

---

This research was produced by the Correctover security team from our MCP ecosystem audit program (37-repo GHSA audit, 24-server blind test, 16-pattern cross-project study). For an enterprise AI security audit engagement, contact us via correctover.com/audit.html.