Microsoft Purview stored XSS shows the risk in compliance consoles

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Cymulate's research: Microsoft Purview Communication Compliance could render captured content as live HTML, turning a review workflow into stored XSS and reviewer token theft.

Why it matters: IAM, PAM, and NHI teams should treat compliance consoles as privileged attack surfaces, because attacker-controlled content can be rendered inside authenticated reviewer sessions and used to steal tokens.

Context

Microsoft Purview Communication Compliance is meant to inspect hostile content, not trust it. The problem here is that a review console can become part of the attack surface when captured messages are rendered back into an authenticated browser without neutralisation.

For identity and access governance, the issue is not simply cross-site scripting. It is that a privileged reviewer identity is exposed through a control plane that aggregates sensitive communications, then executes attacker-supplied content in the same session used for investigation.

That makes compliance tooling a high-value identity surface. If a message from Teams, email, or Copilot can reach the analyst browser unchanged, then the boundary between monitored content and trusted application content has already failed.

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 privileged reviewer sessions create token theft risk?

A: Because the browser session often contains reusable access artefacts that an injected script can read if it runs in the portal origin. If the reviewer identity can be impersonated from those artefacts, the attacker gains the same investigative reach that the compliance workflow was meant to protect.

Q: What are the signs that a monitored-message workflow is becoming unsafe?

A: Look for any product path that replays captured content across timelines, flyouts, or case views without clear output encoding controls. If the same evidence can be surfaced in multiple review contexts, each one must be assessed as a potential render-time attack surface, not just a storage location.

Q: How should teams balance reviewer access with accountability in compliance tooling?

A: Use tightly scoped reviewer roles, isolate them from broader administrator privileges, and treat their browser sessions as high-value credentials. Accountability works only when the review function is separated from other admin duties and the session cannot be reused as a general-purpose tenant foothold.

Technical breakdown

Stored XSS in a compliance review console

Stored cross-site scripting happens when user-controlled content is saved by a system and later rendered to another user as executable markup. In this case, the monitoring pipeline captures message bodies for review, but the review interface passes that captured content into the browser without sanitisation. The key technical failure is not message ingestion. It is unsafe rendering of hostile content inside a privileged portal origin. Once the browser interprets that content as HTML, any script or event handler included in the stored message can execute as though it were part of the application itself.

Practical implication: review consoles that display captured communications must treat stored content as untrusted input at render time, not just at ingestion time.

Why authenticated reviewer tokens are exposed

The exploit chain matters because the browser session belongs to a high-privilege reviewer identity. When malicious code runs in that origin, it can access browser storage and pull session artefacts such as access tokens and refresh tokens. That turns a content-handling bug into identity compromise, because the attacker no longer needs to stay inside the injected page. They can reuse the stolen artefacts to impersonate the reviewer and act within the compliance workflow as that identity. The control failure is session trust, not only input handling.

Practical implication: privileged review identities need browser-session protections that assume any rendered content may try to harvest tokens.

Why multi-source message correlation increases the attack surface

Communication review products often correlate the same message across Teams, email, and Copilot interactions. That correlation improves analyst efficiency, but it also expands the number of places where captured content can be surfaced back to the reviewer. The attack uses that feature to move from a flagged message into a timeline or flyout where the stored payload is rendered. In governance terms, the product is not merely storing evidence. It is re-exposing evidence in a privileged context, and that re-exposure is where the compromise occurs.

Practical implication: any workflow that replays captured content across sources needs the same sanitisation and origin controls as the initial ingestion path.

Threat narrative

Attacker objective: The attacker aims to steal a privileged reviewer’s tokens and impersonate that compliance identity inside Microsoft Purview.

1. Entry occurs when an external user sends a Teams message, email, or Copilot prompt containing malicious HTML into a monitored communication channel.
2. Credential access follows when the review console renders the stored payload inside the authenticated purview.microsoft.com session and the script reads browser-held reviewer tokens.
3. Impact is achieved when the stolen access and refresh tokens are used to impersonate the compliance reviewer and act with privileged access inside the tenant.

Breaches seen in the wild

• Gitloker GitHub extortion campaign: Phishing via GitHub notifications tricked developers into authorising malicious OAuth apps; Gitloker then wiped repos and demanded contact.
• CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Compliance consoles are privileged identity surfaces, not passive viewers. A review tool that renders captured communications inside an authenticated session is handling hostile content on behalf of high-trust users. That changes the governance model from simple monitoring to privileged content execution. The practical conclusion is that compliance workflows must be treated as Tier 0 adjacent control planes, with reviewer identities protected accordingly.

Render-time trust is the broken assumption here. The product assumption that captured message bodies can be safely displayed to analysts without full neutralisation fails the moment monitored content can contain active markup. That is not a minor implementation bug; it is a broken premise about what review interfaces are allowed to trust. The implication is that compliance tooling must be governed as an untrusted-content execution path, not just a storage system.

Identity blast radius grows when evidence replay and session trust meet. The same feature that helps analysts correlate messages across sources also increases the amount of attacker-controlled material surfaced in one privileged browser session. When tokens live in browser-accessible storage, a single bad render becomes an identity compromise rather than a content defect. Practitioners should see this as a blast-radius problem across the review workflow, not an isolated web vulnerability.

Reviewer roles need the same containment discipline as administrators. Communication Compliance Analyst, Investigator, and Reviewer roles sit closer to sensitive data than most teams acknowledge. If those identities can be impersonated through browser token theft, then the governance gap is in session containment and role scoping, not only in input filtering. Teams should treat reviewer access as privileged access with strong segregation and tighter operating assumptions.

Monitoring and security tools cannot outsource trust to their inputs. The article shows a category-wide pattern: when a platform is designed to collect attacker-controlled content, the application itself must assume that every payload is hostile until proven otherwise. That assumption is especially important for compliance, DLP, SIEM, and ticketing consoles. Practitioners need to evaluate these tools as execution surfaces for untrusted evidence, not as neutral display layers.

What this signals

Compliance review needs browser-level containment. The lesson for practitioners is that any console that replays attacker-controlled content should be treated as an untrusted rendering environment, not a harmless analyst view. That means review work should happen in isolated sessions, with access paths designed to limit what a stolen browser token can do.

Identity blast radius is the real control metric. When a single reviewer session can be turned into impersonation of a privileged compliance identity, the question is no longer whether a message was flagged correctly. The question is how far that session can reach if rendering controls fail, and whether the workflow contains that blast radius before token reuse becomes tenant-wide access.

For practitioners

• Treat compliance consoles as Tier 0 applications Apply phishing-resistant MFA, strict conditional access, and isolated review workstations or browser profiles to identities that can inspect monitored content.
• Sanitise captured content at render time Review every code path that displays stored message bodies, timelines, or match views and require output encoding or HTML neutralisation before browser rendering.
• Reduce the value of stolen browser sessions Use shorter token lifetimes, token binding where available, and continuous access evaluation so a stolen review token has less reuse value.
• Separate reviewer roles from broader admin access Keep Communication Compliance reviewers out of global administrative roles and limit who can open cases that replay attacker-controlled content.
• Test the second half of the attack chain Validate whether your controls detect unusual browser-origin exfiltration, new-domain POSTs, or token reuse after a review console opens malicious content.

Key takeaways

• The core failure is not message detection but unsafe rendering of captured content inside a privileged review session.
• The exploit turns a compliance workflow into reviewer token theft and account takeover by abusing browser-accessible session artefacts.
• The decisive control is to treat evidence replay, session storage, and reviewer access as one trust boundary and contain all three together.

Key terms

• Reflected Cross-Site Scripting: A reflected cross-site scripting flaw occurs when an application copies attacker-controlled input into the response without proper encoding and the browser executes it. The attack usually starts with a crafted link or request and succeeds when the victim loads the malicious content in an authenticated session.
• Review Console: A review console is the analyst-facing interface used to inspect captured messages, alerts, or evidence. In identity security terms, it is a privileged control plane because it often exposes sensitive content to users with elevated read and triage rights, making its session and rendering boundaries security-critical.
• Browser Session Token: A browser-held artefact that can keep a user authenticated after sign-in, often without requiring the password again. When stolen, it can function as a live access credential until expiry or revocation, so it should be governed as identity state rather than as harmless application data.
• Event Replay: Event replay is the reprocessing of previously recorded events to rebuild application state or validate behaviour. It is commonly used after delivery failures, during testing, or in recovery scenarios. To work safely, replay logic must be separated from side effects such as notifications or external API calls.

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.