CVE-2026-35435: Azure AI Foundry's M365 published agents trusted callers they shouldn't have

What is this?

On May 7, 2026, Microsoft disclosed CVE-2026-35435, an elevation-of-privilege vulnerability in Azure AI Foundry affecting Microsoft 365 published agents. The flaw is rated CVSS 8.6 (CRITICAL) and is classified as CWE-284 — Improper Access Control. According to the advisory and follow-up coverage by Qualys, SecurityWeek and CybersecurityNews, the issue was disclosed alongside Microsoft’s May 2026 Patch Tuesday and is described by Microsoft as exploited in the wild. As of disclosure, no full patch was available; Microsoft published a set of compensating controls instead.

The bug is in the authorization path of agents that are published from Azure AI Foundry into Microsoft 365. An unauthorized remote attacker can bypass the runtime’s access checks and elevate from a low-privileged role to one with broad control over agent workflows, data connectors and the resources the agent was wired to reach.

How it works

Azure AI Foundry lets organizations build LLM-backed agents — search assistants, ticket triagers, document analyzers — and publish them into Microsoft 365 surfaces (Teams, Outlook, SharePoint, Copilot endpoints). Once published, an agent runs with a service principal that holds delegated permissions over the connectors and data sources it was given at design time.

CVE-2026-35435 lives in the authorization layer that gates calls to that published agent at runtime. According to multiple analyses citing Microsoft’s advisory, the agent runtime did not consistently bind the identity and role of the caller to a server-side session. Caller-supplied identity material — or its absence — was treated as sufficient evidence of authorization. The result, in the language of CWE-284, is that the agent accepted requests from principals that should have been rejected and routed them through workflows reserved for owner-shaped roles.

Concretely, post-exploitation actions described in public coverage include: republishing or modifying an agent’s configuration with elevated permissions, abusing the agent’s existing Microsoft 365 integrations to read mail and files or impersonate the user the agent was speaking for, and pivoting laterally inside an Azure AI Foundry workspace to other agents and connected services.

# Conceptual class — illustrative, not exploit code
caller ─▶ agent runtime
            ├── trusts caller-supplied identity claim          ❌
            └── routes call to owner-shaped workflow
                ├── modify agent config
                ├── reuse delegated M365 permissions (mail, files)
                └── pivot to sibling agents in the workspace

The vulnerability does not require user interaction and is reachable over the network. It is a pure authorization bug — no memory corruption, no prompt injection — but it sits on top of an LLM agent runtime, so the blast radius is shaped by everything the agent was permitted to do on the user’s behalf.

Why it matters

Three points are worth landing.

First, identity is now the LLM agent attack surface. The model itself is not the vulnerability here. The vulnerability is in how the runtime decides who is talking to the agent and what role that caller holds. This is the same class of failure that has affected Microsoft’s stack twice in recent weeks: CVE-2026-32173 on Azure SRE Agent (April 2026) trusted a multi-tenant token check it shouldn’t have; CVE-2026-35435 trusts caller identity for M365 published agents. Two different products, same lesson — the agent’s privileged identity is the prize.

Second, published agents are a fleet, not a feature. Once an organization opens Azure AI Foundry to its lines of business, dozens or hundreds of agents land in M365 with bespoke connector permissions. An EoP that lets an attacker republish or repurpose an agent inherits all of those permissions at once. There is no easy way to bound impact without an inventory of what is published and what each agent can reach.

Third, active exploitation before a patch reframes the timeline. The standard 90-day disclosure window does not apply when the vendor is the source of the disclosure and reports in-the-wild abuse. The defensive question becomes immediate: assume the agent population in your tenant may have been touched and act on that basis.

Defenses

Microsoft’s published compensating controls, plus what falls out of the disclosure for any agent runtime, point to a tight checklist.

Inventory and scope first. Catalog every Azure AI Foundry workspace and every M365 published agent in your tenant. For each, record the service principal, the connectors it can reach, the data scopes those connectors hold, and who is authorized to publish or modify the agent. You cannot reason about blast radius without this.

Apply least privilege to agent service principals. Most published agents are over-permissioned by default. Strip connectors and Graph API scopes back to the minimum the agent actually uses. Remove standing access to mailboxes, SharePoint sites and Teams channels the agent does not need at design time.

Enforce conditional access on the agent path. Microsoft recommends conditional access policies that prevent agents from operating from untrusted locations, untrusted devices, or anonymous network egress. Treat the agent’s service principal like a user account for the purpose of these policies.

Disable or quarantine high-exposure agents. Public-facing or anonymously reachable published agents are the highest priority. If you cannot immediately scope them down, take them offline until the runtime fix lands.

Move identity decisions to the server. This is the architectural lesson that survives the specific CVE. Any agent framework that lets the caller assert who they are — through a flag, a header, or an unbound token — has the same failure mode as senderIsOwner=true in OpenClaw or the loose appid check in Azure SRE Agent. Bind role, tenant and ownership to an authenticated session validated server-side. Never trust the caller’s claim.

Log, alert and rotate. Stand up alerts on agent configuration changes (republish, permission grant, connector swap), on unusual access patterns from agent service principals, and on first-time callers to sensitive published agents. After remediation, rotate the secrets each affected agent was permitted to reach.

Status

Item	Detail
CVE	CVE-2026-35435
CWE	CWE-284 (Improper Access Control)
CVSS	8.6 (CRITICAL)
Disclosed	May 7, 2026 (Microsoft, Patch Tuesday)
Vendor	Microsoft
Affected product	Azure AI Foundry — M365 published agents
Patch status	No patch at disclosure; mitigations published
Exploitation	Reported active in the wild by Microsoft
Attack vector	Network, no user interaction required
Primary mitigation	Least privilege on agent service principals, conditional access, quarantine of high-exposure agents