From Azure SSRF to RSAC Stage: What CVE-2026-26118 Teaches Us About MCP Gateway Security

On March 10, 2026, Microsoft published CVE-2026-26118 — a server-side request forgery vulnerability in the Azure MCP Server rated CVSS 8.8. Five days later, Token Security announced that researchers Ariel Simon and Marc Gendron would present MCPwned at RSAC 2026, demonstrating how remote code execution flaws in Azure MCP servers could enable attackers to compromise entire Azure tenants. These are not theoretical exercises. They represent the moment MCP security moved from conference slides to CVE databases, and they carry a clear architectural lesson: tool-call inspection at the gateway layer is no longer optional.

This post examines what went wrong, why it was predictable, and what the emerging consensus around gateway-based defense looks like in practice.

The CVE: Server-Side Request Forgery in Azure MCP Server

CVE-2026-26118 targets the Azure MCP Server — the component that bridges AI agent interactions with Azure cloud resources. The vulnerability allows an authorized attacker to coerce the server into making requests to internal endpoints that should be unreachable from the MCP layer, specifically Azure’s Instance Metadata Service (IMDS) at 169.254.169.254.

The attack chain works as follows. An attacker with access to the MCP server crafts a tool invocation that embeds a URL pointing to the IMDS metadata endpoint. The Azure MCP Server, lacking sufficient request validation, forwards this request internally. The IMDS responds with managed identity tokens — credentials that grant whatever permissions the Azure resource’s managed identity holds. In many enterprise deployments, managed identities carry broad permissions: access to Key Vault secrets, Storage Account data, or even Azure Resource Manager operations.

The CVSS 8.8 score reflects three factors: network-accessible attack vector, low complexity, and high impact across confidentiality, integrity, and availability. Microsoft has not published a detailed advisory or public proof-of-concept at the time of writing, but the attack pattern is well-understood. SSRF against cloud metadata endpoints is one of the most documented vulnerability classes in cloud security — the Capital One breach of 2019 used essentially the same technique against AWS’s equivalent endpoint. The difference here is the attack surface: it is not a misconfigured web application but an AI agent communication layer.

What makes this CVE significant for the MCP ecosystem is not the novelty of the technique but the context in which it occurs. MCP servers sit between AI agents and backend infrastructure. They receive tool calls that are often constructed or influenced by language model outputs, which are in turn influenced by user prompts, retrieved documents, and other context sources. The SSRF did not require a sophisticated exploit chain. It required a tool call with a crafted URL parameter — exactly the kind of input that a gateway-level inspection layer is designed to catch.

Why This Was Inevitable

The Azure SSRF is not an isolated incident. It fits a pattern that security researchers have been documenting with increasing urgency throughout early 2026.

Token Security’s MCPwned research, set for presentation at RSAC 2026, demonstrates remote code execution paths in Azure MCP servers that go beyond SSRF to full tenant compromise. While the complete findings have not been published ahead of the conference, the announcement alone confirms that the Azure MCP Server attack surface extends well beyond a single CVE.

The broader data supports this. Security Boulevard’s analysis of MCP security risks identifies five primary vulnerability categories that apply across the ecosystem:

Context injection. MCP formalizes context exchange but does not inherently validate the legitimacy of each context element. Adversaries target context assembly pipelines rather than models directly, embedding malicious instructions in contextual payloads from compromised sources.

Identity and authorization failures. AI agents frequently lack proper access controls over context sources. Without fine-grained permissions at the context layer, agents can access unauthorized memory namespaces, documents, or APIs.

Delegation exploitation. Delegation metadata embedded in MCP payloads can enable privilege escalation if treated as authoritative without independent verification. The Security Boulevard analysis is direct: “Authority must be derived from identity systems, not from context payloads.”

Cross-tenant data leakage. In multi-tenant deployments, insufficient tenant-bound enforcement allows sensitive data to cross organizational boundaries through shared memory layers and context retrieval systems.

Authentication gaps. Token scope restrictions and short lifespans are inadequate safeguards when both sender and receiver identities are not validated during context exchanges.

The CVE-2026-26118 SSRF is a concrete example of the first two categories combined — a context injection (the crafted URL) exploiting an authorization failure (the MCP server’s ability to reach the metadata endpoint without restriction). The fact that it appeared in a first-party Microsoft service, maintained by engineers with deep cloud security expertise, underscores how easy it is to miss these vectors when the MCP server is treated as a trusted intermediary rather than an attack surface.

The Gateway Defense Pattern

The architectural response emerging across the ecosystem is gateway-level inspection — a proxy layer that sits between AI agents and MCP servers, inspecting every tool call before it reaches the upstream server.

This is not a new idea. API gateways have enforced request validation, rate limiting, and access control for REST and GraphQL APIs for over a decade. What is new is applying this pattern specifically to MCP’s tool-call protocol, where the inputs are often generated or influenced by language models and carry risks that differ from traditional API traffic.

A gateway positioned in front of MCP servers provides three defense layers:

Request inspection. Every tool call passes through the gateway before reaching the upstream server. The gateway can examine parameters for known attack patterns — SSRF indicators like internal IP ranges and cloud metadata URLs, path traversal sequences, shell injection characters, and encoded payloads. In the case of CVE-2026-26118, a gateway rule blocking requests containing 169.254.169.254 or other IMDS endpoints would have stopped the attack before it reached the Azure MCP Server.

Tool-call validation. Beyond pattern matching, gateways can enforce schema validation on tool call parameters, verify that requested tools are on an approved list, and check that the calling agent has authorization to invoke specific tools. This addresses the delegation exploitation category — even if an agent’s context claims it has permission to perform an action, the gateway validates against an independent policy.

Network isolation. The gateway can enforce network boundaries, ensuring that MCP servers can only reach approved endpoints. Docker-based isolation, network policies, and egress controls prevent a compromised or misconfigured MCP server from reaching internal infrastructure even if the request inspection layer is bypassed.

Wiz Research’s MCP security briefing explicitly recommends this approach. Their analysis calls for centralized proxy solutions that provide a single point of control for audit logging, guardrails enforcement, message approval, sensitive data masking, and threat mitigation against prompt injection attacks. They note that current MCP registries offer only weak trust signals — approximately one-third of the 3,500 servers listed on one major registry link to non-existent repositories — which makes upstream validation even more critical.

Open-Source Gateway Approaches

Several open-source projects have emerged to implement the gateway pattern for MCP deployments. Each takes a slightly different architectural approach, and the right choice depends on the deployment context.

MCPProxy implements a quarantine-and-approve workflow for upstream MCP servers. New servers are added via mcpproxy upstream add and placed in quarantine by default. Administrators review discovered tools and explicitly approve them with mcpproxy upstream approve before they become available to agents. BM25-based tool discovery limits which tools are exposed to any given query, reducing the attack surface by ensuring agents only see relevant tools rather than the full catalog. Docker-based isolation runs upstream servers in containers with restricted network access.

Sentrial focuses on policy-based filtering with a rules engine that evaluates tool calls against configurable security policies. It supports allowlisting and denylisting of tool parameters, request logging, and integration with external policy services.

MCPDome provides a firewall-style interface for MCP traffic with real-time monitoring, traffic visualization, and rule-based blocking. Its dashboard-driven approach is oriented toward security operations teams that want visibility into MCP traffic patterns.

Cordon takes a minimalist approach to MCP sandboxing with namespace isolation and capability restrictions. Developed with a focus on local development environments, it restricts what file system paths and network endpoints MCP servers can access.

Wiz also references MCP Guardian and MCP Gateway as emerging open-source solutions in this space.

The common thread across all of these projects is the architectural principle: do not trust tool calls that have passed through a language model’s context window. Validate them independently at a layer that the agent cannot influence.

Microsoft’s Own Playbook

Microsoft’s response to the growing MCP attack surface extends beyond patching CVE-2026-26118. Their internal MCP governance playbook, published through Microsoft Inside Track, describes a three-pillar approach to MCP security at enterprise scale.

Secure-by-default architecture. MCP deployments at Microsoft are built with restrictive defaults that must be explicitly relaxed rather than permissive defaults that must be tightened. This inverts the common pattern where MCP servers are deployed with full access and then gradually locked down after incidents.

Automated governance. Rather than relying on manual review of MCP server configurations, Microsoft’s approach automates policy enforcement, inventory tracking, and compliance validation. This addresses the scale problem — when an organization runs hundreds of MCP servers across multiple teams, manual governance does not keep pace with deployment velocity.

Inventory management. Every MCP server in Microsoft’s environment is tracked in a central registry with metadata about its capabilities, permissions, data access patterns, and risk classification. This inventory enables rapid response when vulnerabilities like CVE-2026-26118 are disclosed — the security team can immediately identify which deployments are affected and prioritize patching.

The playbook’s emphasis on centralized visibility and automated enforcement aligns directly with the gateway pattern. A gateway that proxies all MCP traffic inherently provides the inventory and audit capabilities that Microsoft describes, because every tool call flows through a single observation point.

Practical Steps: Securing Your MCP Deployment

Whether you are running MCP servers in production or evaluating them for enterprise adoption, the CVE-2026-26118 disclosure and the broader research landscape point to a concrete set of actions.

Deploy a gateway or proxy layer. Choose from the open-source options listed above based on your deployment context. If you need quarantine workflows and tool discovery controls, MCPProxy fits. If you need policy-engine integration, Sentrial may be more appropriate. If you need a visual operations dashboard, MCPDome provides that. The specific tool matters less than the architectural principle: no tool call should reach an MCP server without passing through an inspection layer.

Block cloud metadata endpoints. Any gateway or network policy should deny requests to 169.254.169.254 (AWS, Azure IMDS), metadata.google.internal (GCP), and equivalent endpoints for your cloud provider. This is the most direct mitigation for CVE-2026-26118 and the entire class of SSRF attacks targeting cloud credentials.

Enforce network isolation. Run MCP servers in containers or VMs with restricted egress. They should only be able to reach the specific endpoints they need — not the entire internal network, and certainly not cloud metadata services. Docker isolation with explicit network allowlists is a low-effort, high-impact control.

Implement tool allowlisting. Do not expose every tool an MCP server offers. Maintain an explicit list of approved tools and reject calls to anything not on the list. This limits the blast radius when a server is compromised or when a new vulnerability is discovered in a tool you do not use.

Audit tool-call logs. Gateway-level logging captures every tool invocation with full parameter detail. Review these logs for anomalies: unexpected URLs in parameters, unusual tool invocation patterns, or calls to tools that should not be reachable from a given agent. This telemetry is invaluable for both incident response and proactive threat hunting.

Track upstream advisories. Subscribe to CVE feeds for every MCP server in your deployment. The Azure MCP Server SSRF will not be the last vulnerability in this category. The combination of language-model-influenced inputs and server-side resource access creates an attack surface that will continue to produce CVEs as adoption grows.

The Trajectory

CVE-2026-26118 is the first high-profile CVE specific to the MCP ecosystem, but the conditions that produced it — insufficient input validation on tool-call parameters, overly permissive network access from MCP servers, and trust assumptions about language-model-generated inputs — exist across hundreds of MCP server implementations. Token Security’s upcoming RSAC presentation will likely expand the known attack surface further.

The good news is that the defense pattern is well-understood and multiple implementations exist. Gateway-level inspection is not speculative architecture; it is a proven pattern from API security applied to a new protocol. The tooling is available. The research is clear. The remaining variable is adoption.

---

Sources:

• CVE-2026-26118 — Azure MCP Server SSRF (The Hacker Wire)
• Token Security MCPwned at RSAC 2026 (Yahoo Finance)
• MCP Security Research Briefing (Wiz Research)
• Protecting AI Conversations at Microsoft with MCP Security (Microsoft Inside Track)
• Model Context Protocol Security Risks (Security Boulevard)