al-ice.ai

A 10.0 With No Patch to Install: Missing-Authentication Privilege Escalation in Azure AI Foundry

AI Vulnerabilities & CVEs by al-ice.ai Editorial

On 17 September 2026 Microsoft disclosed CVE-2026-85889, titled “Azure AI Foundry Elevation of Privilege Vulnerability,” with the maximum possible severity: CVSS 10.0. The weakness is CWE-306, missing authentication for a critical function — a component of the enterprise platform teams use to build, deploy, and manage generative-AI applications and agents did not consistently enforce an identity check, so an unauthorized attacker could elevate privileges over the network with no privileges and no user interaction (vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H). Microsoft rates it Critical. As of the advisory, Microsoft flagged it as neither publicly disclosed nor observed exploited — which is reassuring, but does not change what the score means: anyone who could reach the function could use it as anyone.

The detail that determines how this plays operationally is that there is no customer patch. Microsoft's advisory lists the software release as N/A: this was a cloud-service flaw remediated on Microsoft's side, so tenants have nothing to install and no build number to verify against. That is the normal shape of SaaS security fixes — and it is exactly why some coverage framed the fix as “silent.” The disclosure exists in MSRC and NVD (NVD published the record the same day, last modified 25 September), but no action was ever asked of customers, so teams that triage by “patch released → schedule window” will have filed it under nothing-to-do. For a 10.0 in the control plane of your AI platform, nothing-to-do is the wrong conclusion: the question is not what to install, but what happened while the check was missing.

The second Foundry privilege-escalation flaw this year

This site covered CVE-2026-35435, a privilege-escalation flaw in Azure AI Foundry affecting M365-published agents, earlier this year. Two privilege-escalation findings in the same platform family within months is a pattern worth naming: the AI platform layer — model endpoints, agent runtimes, published-agent identity bindings — is accumulating the same class of authorization bugs that took identity teams a decade to grind out of classic cloud IAM. Attackers do not need to jailbreak your model when the platform around it confuses one tenant's caller for another, or no caller at all. The LiteLLM MCP auth bypass that became the first MCP flaw in CISA's KEV catalog is the same lesson from the open-source side: agent infrastructure keeps shipping fallback paths that treat unauthenticated input as authorized.

CWE-306 in particular deserves a specific kind of review. Missing-authentication bugs rarely sit alone; they cluster where a new API surface was added faster than its authorization review — partner model endpoints, admin-adjacent management functions, migration-era compatibility shims. Microsoft's one-line description says only that a critical function lacked the check. Tenants cannot see which function, which makes compensating review of your own side — who holds standing privilege in Foundry, which service principals can touch production agents, what your logs would show — the only available move.

What to do

  • Audit standing privilege in Foundry now, not on a quarterly cadence. List human and service-principal role assignments over AI Foundry resources, published agents, and connected data. A missing-authentication window means any over-broad grant was exercisable by more callers than your model assumed.
  • Review privileged operations across the exposure window. Look for role changes, agent republishes, endpoint or credential rotations, and data-source attachments you cannot attribute — particularly calls that should have required authentication and appear to have succeeded without it.
  • Treat “no patch required” as a detection task, not an all-clear. Service-side fixes leave no local artifact to verify. Confirm with your own telemetry rather than the vendor's remediation statement: sign-in and audit logs for the platform, not just endpoint agents.
  • Shrink the blast radius for the next one. Scope-3.1 scope-changed scores exist because one flaw crosses a boundary. Separate dev and production Foundry projects, require just-in-time elevation for agent publish and data-connect operations, and alert on privilege use outside change windows.
  • Track AI-platform CVEs like infrastructure CVEs. Foundry, Agentforce, Bedrock-class flaws now carry KEV-grade operational weight. If your vulnerability program routes cloud-service disclosures to a mailing list nobody reads, re-route them to the team that owns the agents.

Sources: