Everyone's excited about MCP — the Model Context Protocol that lets AI agents talk to external services. Anthropic launched it. Every major AI lab adopted it. There are now thousands of MCP servers connecting agents to databases, APIs, financial platforms, and cloud infrastructure.
Nobody's talking about the fact that MCP has accumulated 30 CVEs — and the pace is accelerating.
| Metric | Value |
|---|---|
| Total MCP CVEs | 30 |
| Servers with zero auth | 36% |
| Attack surface layers | 3 |
| Since latest CVE | 1 day |
The Latest: CVE-2026-27896 — Case-Insensitive JSON Parsing Bypass
Yesterday — literally yesterday — CVE-2026-27896 was published. It affects the official MCP Go SDK.
The vulnerability: the Go SDK's JSON parser handles field names case-insensitively. An attacker can craft a malicious MCP response with field names like "Method" instead of "method", or "PARAMS" instead of "params". The SDK accepts these silently, potentially bypassing validation logic that checks for exact field names.
This is the kind of bug that sounds benign until you realize it means any security check that validates MCP message structure by field name can be bypassed. If your firewall checks for "method": "tools/call" but the attacker sends "Method": "tools/call", the message passes validation but still gets processed by the SDK.
⚠️ This affects any Go-based MCP implementation. If you're running MCP servers or clients built with the official Go SDK, you're vulnerable. The fix requires updating to a patched SDK version that enforces case-sensitive JSON parsing.
The 3-Layer MCP Attack Surface
What makes MCP security uniquely dangerous is that the attack surface spans three distinct layers. A vulnerability in any layer compromises the entire chain.
Layer 1: 🖥️ MCP Server Layer
The MCP servers themselves — QuickBooks, Stripe, database connectors, file system bridges. This is where the 36% no-auth stat comes from. Over a third of scanned MCP servers accept connections from any client without authentication.
Attack vectors: Unauthenticated access, insufficient authorization (any connected client can call any tool), missing input validation, SSRF through tool parameters, data exfiltration through tool responses.
Real CVEs: Multiple CVEs target server-side validation failures, allowing crafted tool calls to bypass intended restrictions or access unauthorized data.
Layer 2: 📦 SDK Layer
The protocol implementation libraries — the official TypeScript, Python, and Go SDKs that parse MCP messages. CVE-2026-27896 lives here. So do parsing bugs, serialization mismatches, and type confusion vulnerabilities.
Attack vectors: Case-insensitive parsing bypasses (CVE-2026-27896), malformed message handling, type confusion between SDK implementations, deserialization of untrusted data, protocol version mismatches.
Why it's dangerous: SDK bugs affect every application built on that SDK. One CVE in the Go SDK means every Go-based MCP server and client is vulnerable.
Layer 3: 🏠 Host Layer
The machine running the MCP client — your laptop, your server, your AI agent's runtime. MCP tool calls execute with the permissions of the host process. If the agent can call create_invoice on QuickBooks, it can also call delete_all_invoices unless something stops it.
Attack vectors: Unrestricted tool access (no allowlist), write operations through prompt injection, sensitive data leakage through tool responses, lateral movement via MCP server chains, credential theft from tool configurations.
The gap: Most MCP implementations have zero controls at this layer. The agent decides what to call. Nothing validates whether it should.
The CVE Timeline: It's Getting Worse
MCP launched in late 2024. The first CVEs appeared in early 2025. The pace has accelerated dramatically:
| Period | CVEs | Notable |
|---|---|---|
| 2025 Q1-Q2 | ~5 | Initial discovery phase — auth, SSRF basics |
| 2025 Q3-Q4 | ~10 | SDK-level bugs emerge, cross-implementation issues |
| 2026 Q1 (so far) | ~15 | Acceleration — CVE-2026-27896 (Go SDK bypass), server auth failures |
| Total | 30 | Spanning all 3 layers |
Half of all MCP CVEs have been published in the last 3 months. The protocol is being stress-tested in production, and the cracks are showing.
36% of MCP Servers Have Zero Authentication
Let that number sink in. Over a third of MCP servers in the wild accept any connection without verifying the client's identity.
This means:
- Any AI agent that discovers the server endpoint can connect
- Any tool call is accepted — including write operations
- There's no audit trail of who called what
- Prompt injection in one agent can pivot to unauthenticated MCP servers
For financial MCP servers — QuickBooks, Stripe, Xero — this is catastrophic. An agent compromised through prompt injection can directly invoke financial operations on unauthenticated servers.
McpFirewall: What We Built to Fix This
ClawMoat's McpFirewall sits at Layer 3 — between your AI agent and MCP servers. It intercepts every tool call before it reaches the server, enforcing security policies that MCP itself doesn't provide.
Here's what it does:
Read-Only Enforcement (29 Write Patterns)
Most organizations aren't ready for AI agents to write to financial systems. McpFirewall blocks write operations by matching against 29 patterns:
const { McpFirewall } = require('clawmoat/finance/mcp-firewall');
const firewall = new McpFirewall({
mode: 'read-only',
onBlock: (event) => {
console.log(`Blocked ${event.tool} on ${event.server}: ${event.reason}`);
}
});
// Agent tries to create an invoice via MCP
const result = firewall.intercept({
tool: 'create_invoice',
args: { amount: 50000, customer: 'Acme Corp' },
server: 'quickbooks-mcp'
});
// result.blocked = true
// result.reason = "Write operation 'create_invoice' blocked in read-only mode"
The 29 write patterns cover: create_, add_, update_, edit_, modify_, delete_, remove_, send_, post_, submit_, approve_, void_, cancel_, refund_, transfer_, pay_, charge_, issue_, record_, close_, batch_, import_, set_, assign_, link_, unlink_, archive_, restore_, merge_.
One compromised prompt can't trigger transfer_funds or delete_all_customers — the firewall catches it before the MCP server ever sees the request.
Field-Level Redaction
Even in read-only mode, the agent shouldn't see SSNs, bank account numbers, or API keys in MCP responses. McpFirewall redacts sensitive fields automatically:
const firewall = new McpFirewall({
mode: 'read-only',
redactFields: ['ssn', 'tax_id', 'bank_account', 'routing_number'],
redactResponses: true
});
// MCP response comes back with:
// { customer: "Jane", ssn: "123-45-6789", balance: 5000 }
//
// After McpFirewall:
// { customer: "Jane", ssn: "***-**-****", balance: 5000 }
Tool Allowlisting & Blocklisting
Don't leave it to the agent to decide which tools are safe. Define an explicit allowlist:
const firewall = new McpFirewall({
mode: 'read-only',
allowedTools: ['get_invoices', 'get_profit_loss', 'get_balance_sheet'],
blockedTools: ['delete_company', 'export_all_data']
});
Per-Tool Rate Limiting
Prevent data exfiltration through rapid-fire tool calls:
const firewall = new McpFirewall({
mode: 'read-only',
rateLimit: 10, // max 10 calls per tool per minute
allowedTools: ['get_transactions']
});
15 Known Financial MCP Servers
McpFirewall ships with recognition for 15 financial MCP server patterns: QuickBooks, Xero, FreshBooks, Stripe, Plaid, Square, PayPal, Braintree, Coinbase, Mercury, Wise, Wave, Gusto, Rippling, and Bill.com.
How CVE-2026-27896 Could Have Been Exploited
Here's a concrete attack scenario using the fresh Go SDK bypass:
-
Attacker crafts a malicious MCP response with mixed-case field names:
{"Method": "tools/call", "Params": {"name": "transfer_funds"}} -
Validation logic checking for
"method"(lowercase) doesn't match — the message passes through -
Go SDK accepts it anyway because Go's
encoding/jsonis case-insensitive by default - The tool call executes with whatever permissions the MCP server grants
McpFirewall mitigates this because it operates at the tool-call level, not the protocol-parsing level. It doesn't care how the message was parsed — it inspects the resolved tool name and arguments after SDK processing.
What You Should Do Right Now
🔥 Immediate Actions
- Audit your MCP servers — do they require authentication? If not, fix that first.
- Update your SDKs — especially the Go SDK if you're using it. CVE-2026-27896 is one day old.
- Add a firewall layer — never let agents call MCP tools without interception.
- Inventory your MCP connections — know which servers your agents can reach.
- Scan your setup — use ClawMoat's free security scanner for a quick assessment.
The Bigger Picture
MCP is doing for AI agents what HTTP did for web browsers — creating a universal protocol for connecting to services. And just like early HTTP, the security model is an afterthought.
30 CVEs in ~15 months isn't just a number. It's a pattern. The protocol was designed for functionality, not security. Authentication is optional. Authorization is "left to the implementation." Encryption is not required. There's no standard for tool-level access control.
The community is building incredible things on MCP. But without security controls at every layer — server, SDK, and host — we're building on sand.
ClawMoat's McpFirewall is one piece of the puzzle. It protects the host layer with 29 write patterns, field-level redaction, tool allowlisting, and rate limiting. It's open source, has zero dependencies, and is backed by 277 tests.
But we need more. We need MCP servers to require authentication by default. We need SDKs to enforce strict parsing. We need the ecosystem to treat security as a feature, not a footnote.
30 CVEs and counting. The clock is ticking.
Get Started
npm install clawmoat
⭐ Star on GitHub | 🔍 Free Security Scanner
ClawMoat is open source (MIT license), has zero dependencies, and ships with 277 tests. McpFirewall is at clawmoat/finance/mcp-firewall.
Top comments (0)