Azure MCP Server's SSRF Could Leak Its Managed Identity Token to a URL

Microsoft published CVE-2026-26118 on 10 March 2026: a server-side request forgery flaw in Azure MCP Server Tools, the package that lets AI agents and MCP clients act on Azure resources in natural language. An attacker who can interact with an MCP-backed agent could submit a malicious URL in place of a normal Azure resource identifier; the server would then send an outbound request to that address and, in Microsoft's words, “may include its managed identity token” — handing the caller a credential it was never meant to see. Microsoft scored the flaw CVSS 8.8 and rated it Important, and the packages that carry the fix are 1.0.2 and 2.0.0-beta.17. The advisory records no exploitation and no public disclosure before the patch, and no real harm is recorded for it. This incident is one entry in the Orca AI Incident Archive, which holds the full record with its cited sources, severity grade and confidence assessment.

What the advisory actually says

The Microsoft Security Response Center record is terse, and almost every published detail about this flaw descends from it or from Microsoft's answers to a handful of follow-up questions. The description in full: “Server-side request forgery (ssrf) in Azure MCP Server allows an authorized attacker to elevate privileges over a network.” The CVE record reserved the identifier on 11 February 2026 and made it public on 10 March at 14:00 UTC; Microsoft's release note, and NVD's entry, both carry that day. NVD analysed the record and published it at 18:18 UTC the same afternoon. The one regulator notice found for this article came from Morocco: the DGSSI's maCERT unit carried CVE-2026-26118 in a bulletin dated 11 March 2026, listing Azure MCP Server Tools among affected products at its own risk level of Important, with no separate score and a pointer back to Microsoft's release.

The weakness is mapped to CWE-918, server-side request forgery, and the impact classification is elevation of privilege. Microsoft's base score is 8.8 on the vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, with a temporal score of 7.7 on E:U/RL:O/RC:C — the E:U component meaning no exploit code was known to Microsoft when the score was set, and RL:O meaning an official fix was available. NVD carries the same base score and bands it High; Microsoft's own three-step scale calls it Important.

Two fields matter as much as the score. Microsoft's record says Exploited: No and Publicly Disclosed: No. CISA's SSVC decision record on the NVD entry, timestamped 5 March 2026, agrees on exploitation — none — while judging technical impact total and automatable no. The FIRST EPSS model put the probability of exploitation in the next 30 days at roughly 1.0%, at the 62.8th percentile, in a pull dated 3 November 2026. This is a flaw that was found and fixed, not one that is known to have been used.

How a resource identifier becomes an outbound request

Azure MCP Server is Microsoft's implementation of the Model Context Protocol, the interface AI agents use to call tools. Its tools take the parameters an agent supplies — a storage account name, a subscription identifier, a database name — and turn them into calls against Azure's management and data planes. Microsoft's documentation describes the server as authenticating through Entra ID using “your Azure user credentials or managed identity,” with access bounded by Azure role-based access control.

The flaw sits at the point where a parameter that should name an Azure resource is accepted as a URL instead. Microsoft's own explanation: an attacker “could exploit this issue by sending specially crafted input to an Azure Model Context Protocol (MCP) Server tool that accepts user-provided parameters. If the attacker can interact with the MCP-backed agent, they can submit a malicious URL in place of a normal Azure resource identifier.” The server then sends the request where it was told to, rather than where the tool intended.

The part that turns a nuisance into a privilege escalation is what rides along. Microsoft says the outbound request “may include its managed identity token,” which lets the attacker capture that token “without requiring administrative access.” A managed identity token is a bearer credential: whoever holds it can present it to the Azure services that identity is authorised for, until it expires. The mitigating half of the same paragraph is just as important — the attacker obtains “the permissions associated with the MCP Server's managed identity” and, in Microsoft's words, “does not gain broader tenant-level or administrator permissions; only those tied to the compromised managed identity.” The blast radius is whatever someone granted that identity, which in practice is often more than a single tool needed.

Microsoft does not name the affected tool or parameter, and no source reviewed for this article does. That omission is itself a detail: the advisory describes a class of tool — one that accepts user-provided parameters and can be induced to fetch a URL — rather than a single endpoint.

The fix, and the packages that carried it

This was not a Windows update. Azure MCP Server Tools ship as a NuGet package for .NET, an npm package and a Python package on PyPI, and the fix is a version bump in whichever one a deployment uses. Microsoft's advisory lists the affected ranges as 1.0.0 up to but excluding 1.0.2, and 2.0.0-beta.1 up to but excluding 2.0.0-beta.17, across the NuGet, npm and PyPI distributions.

The npm registry dates show the fixed builds were on the registry before the advisory. Version 1.0.2 of @azure/mcp was published on 6 March 2026, four days before the CVE became public; 2.0.0-beta.17 was published on 6 February 2026, five days before Microsoft reserved the CVE identifier and a month before the advisory appeared. Whatever the sequence inside Microsoft, the patched code was not written in response to publication day. NVD and GitHub's advisory database agree on those upper bounds. They differ slightly at the bottom of the PyPI range — NVD says 2.0.0-beta.1, the GitHub advisory says 2.0.0b14 — a discrepancy the two records have carried since publication and one that only affects how far back a Python deployment needs to look.

The advisory itself was revised on 20 March 2026, ten days after publication, with a note that Microsoft had “added products to the Security Updates table that document the various packaging methods used to deliver Azure MCP Server Tools.” In other words, the first version of the advisory named the product but not every channel it shipped through, which matters when the remediation is “upgrade the package” rather than “install this KB.”

What is not established

Who found it. Neither Microsoft's advisory nor the CVE.org record names a reporter; the credits field on the CVE is empty. That is not evidence that no one was credited privately, only that no public credit exists.

Any exploitation. Microsoft records none, CISA's SSVC assessment concurs, and no source reviewed for this article describes a compromised identity in the wild. The record's real-harm field is false, consistent with that. Low EPSS is a forecast, not a finding, and the absence of a reported incident is not proof that none occurred.

Whether a public exploit exists. This is where the secondary coverage splits. A March 2026 post on Blueinfy's blog states that there are “public proof-of-concept exploits, such as those on GitHub” and warns of “rapid weaponization,” but gives no link, payload or walkthrough, and does not demonstrate the flaw. Microsoft's record says the vulnerability was not publicly disclosed before the patch. A GitHub repository search for the CVE identifier on 4 November 2026 returned one repository — a Microsoft Sentinel detection lab published 17 March 2026, not an exploit — and Mallory's vulnerability page states that two candidate exploits were screened and rejected. The claim of working public exploit code is, on the evidence available, unsubstantiated; the claim that no one has tried is equally unproven.

The framing. A page on PolicyLayer, a vendor incident-summary site, recasts CVE-2026-26118 as an unauthenticated remote-code-execution chain ending in full tenant takeover, crediting a named researcher and an RSAC 2026 demonstration. That page's own cited sources are titled as SSRF, its dates do not reconcile with the CVE timeline, and neither Microsoft's advisory nor SecurityWeek's reporting of 10 March describes code execution. This article treats the SSRF-and-token account as the established one and does not repeat the RCE framing.

Why the token, and not the request, is the finding

Server-side request forgery is one of the oldest bug classes in web software, and on its own it is usually a way to reach systems the attacker cannot address directly. What makes this record worth keeping is the credential attached to the request. The MCP server is a confused deputy by design: it holds an identity so that an agent can act on a user's behalf, and every parameter an agent passes is, from the server's point of view, attacker-influenced text. When one of those parameters becomes a destination rather than a name, the deputy carries its own authorisation to the destination.

Microsoft's documentation sharpens where that risk concentrates. It describes the local server as “intended strictly for developer use within your organization,” while separately publishing deployment guides for self-hosted remote servers in Microsoft Foundry and Copilot Studio — the configurations where a managed identity, rather than a developer's own sign-in, is typically the credential in play. The advisory's token-theft path is specifically about the managed identity. It does not say that every installation was exposed, and it does not say how many were.

The general lesson is the one OWASP's AI Security Verification Standard now uses the case to teach. The AISVS orchestration chapter cites CVE-2026-26118 among its worked examples and draws the conclusion that “MCP tool parameters must be treated as attacker-controlled, and outbound requests from MCP servers must run through the same egress and origin policies expected of any other agent-driven I/O.” That is a control recommendation, not a finding about this incident, but it is the most concrete answer anyone has published to the question of what should change.

What changed after

Three things, and none of them is dramatic. Microsoft shipped fixed packages in all three ecosystems and revised the advisory to name them. The vulnerability-intelligence ecosystem absorbed it quietly: a low EPSS score, and an NVD record last modified on 17 June 2026. And the standards community adopted it as a teaching case, which is a slower and more durable form of response than a patch.

For anyone still running an affected build, the remediation is unchanged and unglamorous: move to 1.0.2 or later on the stable line, or 2.0.0-beta.17 or later on the preview line, in every package manager the deployment touches. Beyond that, the advisory's own logic implies three controls — restrict what the server can reach outbound, give the managed identity only the roles its tools actually need, and treat any tool parameter that can become a URL as hostile input. None of those is required to have survived CVE-2026-26118. Each would reduce what the next one is worth to an attacker.

How the archive classifies this one

The record is filed as a vulnerability — something found, not something known to have been exploited — with confidence graded A, meaning well documented with primary sources agreeing, and it is not marked as disputed. Its real-harm field is false and its AI involvement is confirmed, because the affected product is the bridge between an AI agent and a cloud control plane rather than a general-purpose service that happens to sit nearby. The date is recorded at day precision, 10 March 2026, with no end date, because this is a single point in time rather than a campaign. The region is global and the landmark flag is false.

One field reads differently from the published scoring. The archive's severity is recorded as medium, on its own scale; the number both Microsoft and NVD publish is 8.8, which Microsoft calls Important and NVD bands High. The record's summary leads with that 8.8, and the discrepancy is a difference in bucketing rather than in facts.

What the record cannot convey is how much of this story is an absence. There is a flaw that hands a cloud identity to whoever asks for it in the wrong shape. There is a fix, shipped before the announcement. There is no credited discoverer, no named tool, no confirmed exploitation and no way for an outsider to tell whether any hosted deployment ever ran a vulnerable build while holding a powerful identity. The advisory is precise about what the flaw does and silent about nearly everything else, and that silence is the most useful thing to notice about it.