Two AI Tools. Two Weeks. One Broken Boundary.
Enterprise AI security had a rough two weeks in June. Two widely trusted tools — Microsoft 365 Copilot and the LiteLLM proxy framework — were each cracked open by independent research teams, and the vulnerabilities shared a single, damning root cause: AI systems that accept external input with no meaningful trust boundary in place. If your organization is running either tool, or anything architecturally similar, this is the moment to stop and audit your stack.
On June 15, Varonis disclosed SearchLeak (CVE-2026-42824), a proof-of-concept exfiltration chain targeting Microsoft 365 Copilot Enterprise Search. Four days before that, Obsidian Security published details of a three-CVE chain against LiteLLM that escalated a default low-privilege user all the way to admin access and remote code execution. No exotic zero-days. No nation-state tradecraft. Just two enterprise AI tools doing exactly what attackers told them to do — because nothing told them not to.
Below is a breakdown of both vulnerability chains, the pattern connecting them, and a five-check audit you can start running before lunch.
SearchLeak: How Copilot Became a Silent Data Exfiltration Engine
The SearchLeak chain is elegant in the worst possible way. An attacker crafts a URL hosted on a legitimate microsoft.com domain. A victim clicks it. From that single click, Microsoft 365 Copilot searches the victim's mailbox, retrieves sensitive data, and routes it out through Bing's image-search endpoint — all without plugins, a second interaction, or any visible indicator that anything has gone wrong.
Three weaknesses made this possible. First, the URL's query parameter passed attacker-controlled instructions directly into Copilot's underlying language model with no sanitization. Second, a rendering race condition caused an image tag to fire before the output sanitizer had a chance to review the content. Third, Bing's image-search endpoint was allowlisted in the platform's Content Security Policy, giving the exfiltrated data a pre-approved exit route.
Microsoft rated the flaw critical and patched it server-side, according to Varonis. The National Vulnerability Database had not yet assigned a severity score at time of writing, though a third-party tracker lists it at 6.5 medium. The contested severity number matters less than the mechanism, which is not contested at all.
What makes SearchLeak especially significant is its context. This is the third Copilot exfiltration chain Varonis has disclosed in a twelve-month window. That frequency is not a coincidence — it reflects a structural characteristic of how Copilot ingests and processes user-adjacent content. When a productivity AI has broad access to email, documents, and calendar data, and when its input surface is reachable via a trusted URL, prompt injection is not a theoretical risk. It is an active attack category.
LiteLLM: From Default User to Admin in Three CVEs
The Obsidian Security disclosure against LiteLLM tells a different but complementary story. LiteLLM is a popular open-source proxy that lets organizations route requests across multiple large language model providers from a single interface. Its flexibility and ease of deployment have made it a common fixture in enterprise AI stacks. That same ease of deployment, it turns out, created a straightforward privilege escalation path.
Obsidian's researchers chained three CVEs to carry a default low-privilege user account to full admin access and, from there, to remote code execution. The details of each CVE in the chain involve authentication logic flaws and inadequate permission enforcement — the kind of vulnerabilities that appear when a tool is built to be easy to integrate and security hardening is treated as a later concern rather than a foundational one.
The impact is significant for any organization using LiteLLM as a gateway to production AI workloads. Admin access to an LLM proxy means control over model routing, API key management, and potentially the data flowing through every model query. Remote code execution on the host extends that risk to the surrounding infrastructure.
The Pattern Connecting Both Disclosures
Strip away the technical specifics and both incidents reduce to the same sentence: enterprise AI accepts external input with no trust boundary. Copilot trusted the content of a URL parameter. LiteLLM trusted the privilege claims of a low-level user account. In both cases, the AI system performed exactly as designed — it just did so in service of an attacker rather than the intended user.
This is the defining security challenge of the current AI deployment era. Traditional application security assumed relatively static, human-authored inputs. AI systems are designed to be responsive and flexible precisely because the inputs they handle are dynamic and varied. That responsiveness is the product. It is also the attack surface.
The 5-Check Audit for Your AI Stack
The following five checks map directly to the vulnerability classes exposed by SearchLeak and the LiteLLM chain. Each can be initiated without waiting for a formal security engagement.
- Audit your LLM input paths. Identify every place where externally sourced content — URLs, emails, uploaded files, third-party API responses — can reach a language model prompt. Any unvalidated input path is a potential injection vector. Inventory these paths and apply allowlisting or strict parsing at each entry point.
- Review your Content Security Policy for AI-adjacent services. SearchLeak succeeded in part because Bing's endpoint was already allowlisted. Audit your CSP to ensure that AI tools do not inherit overly permissive policies from adjacent services. Any allowlisted domain that can receive outbound requests should be scrutinized.
- Check default privilege configurations on AI proxies and gateways. LiteLLM's escalation chain began with a default low-privilege account. Review the out-of-the-box permission structure of every AI gateway in your environment. Default accounts should have no access to admin functions, and privilege escalation paths should require explicit approval workflows.
- Enumerate what data your AI tools can access at rest. Copilot's damage potential depended on the breadth of mailbox and document access granted to it. Apply the principle of least privilege to AI tool permissions. If Copilot or an equivalent tool does not need access to a particular data store to do its job, revoke that access now.
- Establish a patch latency baseline for AI vendor disclosures. Microsoft patched SearchLeak server-side, but many organizations would not have known to look for the disclosure. Create a tracked process for monitoring CVEs that affect every AI tool in your stack, and set an internal SLA for validating that vendor patches have been applied or mitigated.
What to Tell the Board
If you need to summarize the risk in a single sentence for executive leadership, this is it: our AI tools have broad access to sensitive data and accept instructions from external sources, which means a single malicious link or a misconfigured account can trigger data exfiltration or system compromise without any visible warning to the user.
That sentence is not hypothetical. It describes exactly what happened to Microsoft 365 Copilot and LiteLLM in June. The researchers who found these vulnerabilities were responsible and disclosed responsibly. The next people to find similar flaws may not be.
The five checks above are not a complete security program for enterprise AI. They are the minimum viable audit — the set of questions every security team should be able to answer about their AI stack right now, before the next disclosure lands. If you cannot answer all five, that gap is your priority.
AI tools are accelerating faster than the security frameworks designed to govern them. The organizations that treat AI security as an ongoing operational discipline — rather than a one-time compliance checkbox — are the ones that will be positioned to deploy these tools at scale without handing attackers the keys to their most sensitive data.