Microsoft Purview stored XSS shows the risk in compliance consoles

At a glance

What this is: This research shows that Microsoft Purview Communication Compliance could render attacker-controlled content in a privileged review session, turning a monitoring workflow into stored XSS and token theft.

Why it matters: It matters because IAM, PAM, and NHI teams must treat compliance tooling as a high-value privileged surface where browser session protection, role scoping, and content sanitization all become access controls.

By the numbers:

• The attack worked with a standard M365 license in any tenant, and no permissions in the target tenant were required.

👉 Read Cymulate's analysis of Microsoft Purview Communication Compliance token theft

Context

Compliance and monitoring consoles are not passive viewers of content. They are privileged applications that ingest hostile input, store it, and then render it for analysts who can read the organisation’s most sensitive captured communications. In Microsoft Purview Communication Compliance, that review model became the attack surface when captured message bodies were displayed back to reviewers without sufficient neutralisation.

For IAM and PAM teams, the problem is not only stored cross-site scripting. It is the governance assumption that a privileged review console can safely render untrusted content because the content originated from a policy workflow. Once that assumption fails, the browser session, reviewer role, and token storage become part of the control plane and need to be treated that way.

Key questions

Q: What breaks when a compliance console renders monitored content without sanitisation?

A: The browser becomes an execution environment for attacker-controlled content, which means the review workflow can turn into stored XSS and session theft. In privileged compliance tools, that failure can expose tokens, tenant identifiers, and case data. The control that failed is the render boundary, not the message-capture policy.

Q: Why do compliance reviewers need stronger identity controls than ordinary users?

A: Because reviewers operate on high-value case data and often hold tokens that can read sensitive communications, manage policy, or validate investigations. If their browser session is compromised, the attacker inherits a privileged identity rather than a generic user account. That makes browser containment and session protection part of compliance governance.

Q: How can security teams tell whether a review console is too trusted?

A: Look for systems that ingest untrusted content, store it, and then render it inside an authenticated admin or analyst session. If the product can display external HTML, rich text, or message previews to privileged staff, it needs the same sanitisation, role scoping, and session hardening as any public-facing application.

Q: Who is accountable when a monitoring platform exposes privileged reviewer tokens?

A: The accountability usually spans the platform owner, the security team that approved the workflow, and the identity team that granted reviewer access. If the console can execute hostile input, then application security, IAM, and PAM controls all share responsibility for the control failure. Regulatory scrutiny will focus on whether access was proportionate and protected.

Technical breakdown

Stored cross-site scripting in a compliance review console

Stored XSS occurs when attacker-controlled content is saved by a system and later rendered in another user’s browser as executable markup or script. In this case, the review experience passed captured message text into the browser through an unsafe HTML rendering path. Because the content came from monitored Teams, email, or Copilot sources, the application treated hostile input as review data rather than untrusted code. That is the architectural mistake: a content inspection workflow that fails to separate storage, parsing, and rendering creates a first-party execution path for the attacker.

Practical implication: review consoles must neutralise captured content before any browser render path can interpret it.

Why token theft follows privileged browser execution

Once arbitrary JavaScript runs in the authenticated origin, it inherits the browser’s trust context. In portal-style applications, access tokens, refresh tokens, tenant identifiers, and session state are often available in web storage or adjacent client-side state. The attack does not need to break authentication directly. It abuses the fact that the reviewer is already authenticated and that the browser is allowed to present, read, and reuse identity artefacts inside the privileged session. From there, the attacker can impersonate the reviewer until the session or token set is invalidated.

Practical implication: browser session hardening and token binding matter as much as portal patching.

Why cross-tenant delivery makes the control gap worse

The payload did not require foothold inside the target tenant. The message could originate from a standard external tenant account, be captured by the supervision policy, and then appear in the reviewer’s queue as routine compliance work. That means the attack path crosses a boundary many teams assume is protective: external sender, monitored content, privileged reviewer, then compromise. The visibility model becomes the delivery model. When any user who can send a message can influence what a reviewer’s browser executes, the review pipeline itself is a trust boundary that has to be controlled like an internet-facing application.

Practical implication: treat monitored external content as attacker input all the way through case review.

Threat narrative

Attacker objective: The attacker’s objective is to steal privileged reviewer tokens and impersonate a compliance identity that can inspect sensitive monitored communications.

1. Entry occurred when an external user sent a monitored Teams message, email, or Copilot prompt containing stored HTML payload content that the compliance pipeline would later surface.
2. Escalation occurred when the reviewer opened the case and the unsafe rendering path executed attacker JavaScript inside the authenticated purview.microsoft.com session.
3. Impact occurred when the script read browser-stored MSAL tokens and impersonated the privileged compliance reviewer across the tenant.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• CoPhish OAuth Token Theft via Copilot Studio — CoPhish campaign exploits Microsoft Copilot Studio agents to steal OAuth tokens via AI-assisted phishing.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compliance consoles are tier-0 identity surfaces, not passive review tools. A reviewer in Microsoft Purview can read captured communications that the business treats as highly sensitive, so the console inherits the same risk profile as an administrator workstation. The security model fails when organisations assume monitoring products are low-risk because their primary job is inspection. The correct operating assumption is that any system able to render hostile content for privileged staff must be governed like a privileged application.

Stored XSS in a review workflow is really a governance failure over untrusted content. The broken premise is that captured messages are safe to re-display because the system already decided they were worth reviewing. That assumption collapses when the actor sending content is external, the message is persistent, and the reviewer is highly privileged. The implication is not merely browser hardening, but recognising that content inspection pipelines create attack paths unless the render boundary is explicitly controlled.

Privileged compliance roles need stronger session containment than ordinary business users. Analysts, investigators, and reviewers are not just viewers. They are identities whose browser artefacts can reveal policy data, case timelines, and token material. A console compromise here does not create a generic endpoint event. It creates a direct route into regulated communications oversight. Practitioners should treat reviewer identities as high-value operational accounts and bound what their sessions can expose.

Attack surface management must now extend to the content your own controls ingest. Security teams often look outward for exposed services and inward for overprivileged accounts, but compliance platforms combine both problems. They ingest externally supplied content and then expose it to privileged humans inside the identity plane. That means content sanitisation, role design, and browser session controls belong in the same governance conversation. If the review surface can be reached by any message sender, it is already part of the adversary model.

Cross-channel monitoring expands the blast radius unless the review path is isolated. Email, Teams, and Copilot all flowed into the same review experience, which widened the number of ways an attacker could seed a payload. The lesson is that channel consolidation without render isolation concentrates risk. Practitioner programmes should evaluate whether shared review queues, shared browser contexts, and shared token state are multiplying exposure across the same identity.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, and 38% have no or low visibility, according to The State of Non-Human Identity Security.
• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities.
• Reviewers who must inspect externally sourced content should be governed with the same lifecycle discipline highlighted in NHI Lifecycle Management Guide.

What this signals

Content inspection systems now sit inside the identity perimeter. When a monitoring platform can render external content back to a privileged human, the security team has to treat it as an identity control point, not just a workflow tool. That means browser session containment, role scoping, and content sanitisation should be reviewed together, with the OWASP Non-Human Identity Top 10 useful for thinking about delegated access and exposure paths.

Reviewer console compromise is a governance problem before it is an application bug. The organisation has to decide whether compliance analysts are operating with tier-0 access in a browser that can be influenced by anyone who can send a message. If the answer is yes, then access reviews, JIT activation, and session constraints need to be aligned to that reality, not to the softer assumptions of ordinary business applications.

Identity blast radius: the blast radius is no longer just the analyst account. Once a monitored message can trigger execution in the review origin, the relevant boundary becomes the combination of sender reach, review queue privilege, and token persistence. Practitioners should map that boundary against NIST SP 800-53 Rev 5 Security and Privacy Controls, especially controls covering access enforcement, auditability, and input handling.

For practitioners

• Harden compliance review consoles as privileged applications Require phishing-resistant MFA, device-bound access, and a separate browser profile or workstation for analysts who review captured content. The goal is to keep hostile messages away from the same session that holds privileged identity artefacts.
• Sanitise captured content before browser rendering Audit every review path that displays monitored messages, attachments, or Copilot output. Ensure stored HTML, rich text, and embedded fields are neutralised before they reach the browser origin.
• Reduce the value of a stolen reviewer session Apply shorter token lifetimes, continuous access evaluation, and bound sessions for compliance identities so token theft does not automatically become long-lived impersonation.
• Scope reviewer roles to the minimum viable set Separate analyst, investigator, and reviewer duties where possible, and avoid giving compliance reviewers unrelated administrator privileges that would widen post-exploitation reach.

Key takeaways

• Microsoft Purview Communication Compliance could be turned into a stored XSS path that exposed privileged reviewer tokens.
• The exploit worked because captured content was treated as safe to render inside an authenticated compliance session.
• Teams should harden compliance consoles like tier-0 applications, with sanitisation, session binding, and tighter reviewer scoping.

Key terms

• Universal Cross-Site Scripting: Universal Cross-Site Scripting is a flaw that lets an attacker execute script on an origin of their choosing inside a trusted browser context. In Android WebView, that means the application’s rendering layer becomes the problem, allowing account hijacking, session theft, and content manipulation on otherwise trusted sites.
• Compliance console: A compliance console is the application analysts use to inspect messages, policy matches, and review cases. It is an identity-sensitive control point because it often sits on top of high-privilege roles, holds sensitive evidence, and can become an attack surface when it renders untrusted content.
• Token Theft: An attack where a valid authentication token is stolen and replayed by an attacker to gain unauthorised access. Short token lifespans and token binding are the primary mitigations.
• Reviewer identity: A reviewer identity is a privileged account used to inspect, triage, or approve monitored content in security or compliance workflows. It usually carries broader read access than ordinary users, so protecting its browser session, device posture, and role scope is part of identity governance, not just endpoint hygiene.

What's in the full report

Cymulate's full report covers the operational detail this post intentionally leaves for the source:

• Proof-of-concept payload construction and the exact review path that executed it
• Disclosure timeline and vendor response details for the service-side fix
• Browser storage artefacts observed during token exfiltration and how the exfiltration request was shaped
• Recommended validation checks for security teams that want to test similar review consoles

👉 The full Cymulate post covers the attack chain, payload path, and recommended defensive checks in detail.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.