Microsoft 365 Copilot: an open redirect that blurred the tenant boundary

What is this?

On 2 July 2026 Microsoft published an advisory for an elevation-of-privilege vulnerability in Microsoft 365 Copilot, rated critical. The flaw is an open redirect — a URL that Copilot could be steered to treat as trusted even though it pointed to an untrusted destination — and its consequence was unusual for that bug class: it could let an authenticated attacker cross the trust boundary that is supposed to keep one Microsoft 365 tenant’s data isolated from another’s. In the worst-case scenario described by Microsoft, a low-privilege account in one organization could reach files, emails, or Teams messages belonging to a different organization that uses the same Copilot service. Microsoft fixed the issue server-side, so there is no patch for customers to install, but the incident is a clean illustration of how a mundane web weakness becomes serious once an LLM assistant sits in the middle of a permission chain.

How it works

Copilot is not a single model answering a single question. It is an orchestration layer that fans a user prompt out across Microsoft Graph, SharePoint Online, Exchange, and Entra ID, retrieves whatever the user is authorized to see, and composes an answer. Every one of those retrievals is supposed to be authorized as the requesting user, at query time.

The vulnerability lived in that orchestration seam. An open redirect meant a link the assistant handled could send it to an attacker-influenced destination while the surrounding request still carried the appearance of a trusted, first-party flow. According to the public advisory and the analyses that followed, this momentarily blurred the line between “data from this tenant” and “data from that tenant” — the orchestration engine treated content from separate tenants as if it belonged to the same authoritative domain under certain conditions. Because Copilot logs its retrievals as actions performed by the application rather than by the end user, the true origin of a request could also be obscured, which is exactly what makes this class of bug hard to spot after the fact.

No exploit code is public, and we are not reproducing one. The mechanism matters more than any payload: when an LLM assistant is granted broad, cross-service read access and then trusts a redirect it should have re-validated, the model’s reach becomes the attacker’s reach.

Why it matters

Open redirects are usually filed under “low severity.” What raises the stakes here is the blast radius of the component sitting behind the redirect. A copilot that can reason over an entire tenant’s mail, documents, and chat has, by design, a very large view of sensitive data. A single failure in how a request is authorized does not leak one file — it can expose an arbitrary slice of a corpus, and in this case potentially a neighboring organization’s corpus. Cross-tenant isolation is one of the load-bearing promises of multi-tenant SaaS; a privilege-escalation path that crosses it, even briefly, is a first-order concern for any regulated environment.

The wider lesson is architectural. As assistants become the default interface to corporate data, they inherit and amplify every misconfiguration and every trust assumption beneath them. An over-permissive SharePoint site that was merely latent risk becomes reachable the moment a copilot will surface it in response to a prompt. Security teams should now treat AI assistants as high-value, high-privilege applications and threat-model them accordingly — including red-team exercises that specifically probe whether a crafted prompt or a handled link can cross a tenant boundary.

Defenses

The server-side fix removes this specific path, but the exposure it revealed is structural and worth hardening against regardless.

• Constrain the assistant’s identity. Review the permissions granted to the Copilot service principal in Entra ID and strip any tenant-wide Graph scopes it does not need. The narrower the assistant’s read reach, the smaller the blast radius of any future authorization slip.
• Tighten the data underneath. Audit SharePoint Online external sharing and site permissions. Restrict or disable external sharing on sites holding sensitive data; a copilot cannot leak what it was never allowed to index.
• Review cross-tenant access settings. In Entra ID external identities, examine inbound and outbound cross-tenant configurations and reduce trust to the minimum your B2B collaboration actually requires.
• Monitor Copilot activity as a first-class log source. In the Microsoft 365 Defender portal, hunt for prompts returning data from unexpected sources or accesses without a clear business justification. Because actions are logged as the application, focus on anomalous retrieval patterns rather than user attribution alone.
• Validate every redirect and re-authorize at retrieval time. For teams building their own LLM assistants: never let the model follow a redirect on trust. Re-validate the final destination, and re-check authorization as the user at the point of each data fetch, not just at the front door.
• Threat-model the assistant, not just the model. Add “can a prompt or link cross a tenant / privilege boundary?” to your test plan, and treat the orchestration layer — not the LLM weights — as the primary attack surface.

Status

The vulnerability was disclosed and fixed by Microsoft in early July 2026. No customer action is required to receive the fix, but the configuration hardening above remains sound.

Item	Detail
Affected product	Microsoft 365 Copilot (orchestration across SharePoint Online, Exchange, Entra ID, Microsoft Graph)
Class	Open redirect → cross-tenant elevation of privilege
Vendor severity	Critical
Prerequisite	Authenticated attacker with some existing tenant access
Fix	Applied server-side by Microsoft; no customer patch
Reference	CVE-2026-41106 (MSRC Security Update Guide)
Disclosure	~2 July 2026