PERMISSION/PROTOCOL
Back to incident tracker

2026-06-15

HighPrimary

CVE-2026-42824 SearchLeak: One Malicious Link Made M365 Copilot Exfiltrate Email, MFA Codes, and Calendar Data

Varonis found CVE-2026-42824 (SearchLeak): a malicious URL triggers M365 Copilot to exfiltrate emails, MFA codes, and calendar data via P2P injection, HTML race condition, and SSRF through Bing. Patched June 15, 2026.

Microsoft 365 CopilotCredential exposureOne-click prompt injection / data exfiltrationM365 Copilot Enterprise search / email, calendar, SharePoint, OneDrive

What happened

Varonis researchers crafted a URL with a malicious instruction in the Copilot Enterprise Search q parameter telling Copilot to search the victim's mailbox and embed the results in an img tag URL. When a victim clicked the link, Bing's SSRF proxy forwarded the data to attacker infrastructure — all while Copilot appeared to process a normal search.

Why it matters

Email content including access codes and sensitive communications, MFA/2FA codes, calendar events and meeting details, SharePoint documents, and OneDrive files were exfiltrated to attacker-controlled infrastructure in a single user click. No plugins, credentials, or elevated permissions required.

Missing authorization check

The Copilot Enterprise Search endpoint must sanitize URL parameters before passing them to the AI as executable prompts. HTML rendering must apply content sanitization during the streaming phase, not after. Outbound fetch capabilities via Bing should require an explicit authorization gate before the AI initiates external requests carrying user data.

Would PP block it?

PP enforced externally to the M365 Copilot runtime could gate the outbound exfiltration step: any Copilot action that fetches an external URL with user data embedded should require a signed authority receipt. This breaks the SSRF chain at Bing. PP does not address the P2P injection at the URL parameter level or the HTML rendering race condition — those require input validation and streaming-phase sanitization on Microsoft's side. Full coverage: PP for gating external fetch operations, vendor-side input sanitization for the prompt injection vector.

Incident analysis

Timeline and technical read

Timeline

  1. 2026-06-15

    Varonis publishes SearchLeak research; Microsoft releases CVE-2026-42824 patch

  2. 2026-06-15

    BleepingComputer, Dark Reading, SC Media, and CybersecurityNews cover the vulnerability

  3. 2026-06-16

    Coverage expands; Microsoft confirms critical severity rating and patch availability

Technical breakdown

  • Parameter-to-Prompt (P2P) injection: the Copilot Enterprise Search endpoint passed the URL q parameter directly to the AI as an executable instruction — allowing an attacker to craft a URL that instructs Copilot to search the victim's mailbox and embed results in an img tag pointing at attacker infrastructure.
  • HTML rendering race condition: during Copilot's streaming output phase, the browser rendered raw HTML (including img tags) before Microsoft's post-processing sanitizer wrapped output in code blocks — creating a window where attacker-controlled markup fired outbound requests before sanitization engaged.
  • SSRF via Bing allowlist: Bing's image search endpoint was on the Copilot CSP allowlist. Copilot's img requests pointed at Bing, which performed a server-side fetch to attacker-controlled URLs containing the stolen data — turning Bing into an exfiltration proxy that bypassed direct-origin restrictions.
  • The three-stage chain required no plugins, no credentials, no special permissions, and only a single victim click. The victim's interface showed Copilot 'thinking' while the exfiltration completed invisibly in the background.
  • Exposed data included email content, MFA/2FA codes, calendar events, meeting notes, SharePoint documents, and OneDrive files — the full surface of M365 Copilot Enterprise Search indexed content.

Authorization boundary

Where the authorization boundary should have been

This incident is categorized as Credential exposure. The relevant Permission Protocol gate is Tool-Call Gate. The read is conditional: the block only applies where the real action boundary is routed through a gate.

If enforced at
Tool-call layer (outbound fetch / SSRF via Bing), rendering layer (streaming sanitization)
Still needs
Parameter-to-prompt injection at the URL query layer; HTML streaming-phase sanitization timing; PP gates tool calls, not URL parameter parsing
Receipt required for
Any Copilot action that initiates an outbound request containing data retrieved from the user's mailbox, calendar, or organizational files

PP's tool-call gate would require a signed receipt before Copilot initiates outbound fetch requests carrying user data, breaking the SSRF exfiltration chain. The root P2P injection and HTML rendering race condition are Microsoft-side issues outside PP's enforcement surface.

Start small

Put the relevant gate at this action boundary.

This incident maps to Tool-Call Gate. Start with the boundary that controls the actual action, then require a signed receipt before execution.

Replay this incident with a signer in the loop