Two vulnerability disclosures landed within hours of each other this week. One sits in a tool almost every enterprise runs, the other in a tool a smaller set of teams run on purpose. Read separately, they’re a Microsoft patch note and an open-source upgrade advisory. Read together, they describe the same problem: the AI layer your organization adopted for productivity has quietly become a place where data leaves and instructions get rewritten.
One click, and Copilot does the attacker’s work#
The first is a chain in Microsoft 365 Copilot Enterprise Search, designated SearchLeak and tracked as CVE-2026-42824. The setup is uncomfortable because it asks so little of the victim. Someone clicks a link that points to a real microsoft.com address. They type nothing. They never enter a password or click a second time. Behind that click, Copilot searches their mailbox, pulls content, and ships it to an attacker-controlled endpoint.
The entry point is the search URL’s query parameter. It’s meant to hold a natural-language question. Copilot reads whatever sits there as instructions instead, a technique the researchers call parameter-to-prompt injection. From there the chain leans on two older web bugs: a rendering race condition that fires an injected image tag before a guardrail can wrap it as text, and a server-side request forgery that turns a trusted search backend into the exfiltration proxy. Each link feeds the next.
What makes this awkward for defenders is the part that has nothing to do with AI. The malicious link sits on a legitimate Microsoft domain, so URL filtering and anti-phishing tooling have little reason to flag it. The payload rides inside a query string, not an attachment or a lookalike domain. The data in scope reportedly includes email content, calendar entries, and indexed files from OneDrive and SharePoint, which is to say most of what an enterprise assistant can see.
The vendor fixed this one on the backend, so there’s no patch to deploy. That’s good for exposure and slightly misleading for risk posture, because the design weakness it exploited isn’t unique to one product.
A gateway that holds every key#
The second disclosure is a three-bug chain in LiteLLM, the open-source gateway many teams put in front of their model providers to centralize spend, logging, and policy. The chain, CVE-2026-47101, CVE-2026-47102, and CVE-2026-40217, lets a low-privilege user climb to full admin and run code on the host. The maintainer shipped the complete fix in v1.83.14-stable.
The reason this matters more than a typical proxy bug is where the gateway sits. It brokers calls to more than a hundred providers behind one interface, which means it holds the keys to all of them, plus the salt that decrypts stored credentials and the database connection string. Take over the host and you’ve taken every provider key the organization uses, along with every prompt and response that’s passed through. In real deployments that traffic is where source code, internal tickets, and pasted secrets end up.
The sharper risk isn’t reading the traffic. It’s rewriting it. The gateway sits on the wire between an agent and the model, so an attacker who controls it can alter responses in transit. The disclosure included a demonstration of a compromised gateway injecting tool calls to push a downstream coding agent into actions it was never asked to take. If the proxy also fronts agent or tool traffic, OAuth tokens and tool credentials are in scope too.
Why these two belong in the same conversation#
My interest in this category dates back to time spent as a defender in a Security Operations Center. The most interesting part of an attacker’s tradecraft was usually how they got the data out, not how they got in. The pattern was always the same underneath: find the trust boundary defenders had stopped inspecting, and route through it. The boundary has moved over the years, from email to encrypted tunnels to cloud storage APIs. Today it includes the assistants and gateways teams adopted to make their work faster.
Most coverage will file these two disclosures under different headings, one a SaaS bug and one an open-source bug. The more useful framing for a security team is that both are identity and trust problems wearing an AI costume.
The Copilot assistant and the LiteLLM gateway are both non-human identities with standing access and broad scope. One can read a user’s entire mailbox on demand. The other holds every model credential the company owns. Neither was treated, by default, with the verification and least-privilege discipline you’d apply to a human account with that much reach. Your security-awareness training doesn’t reach either of them, and “we told the model to be careful” is not a control.
This is significant because the adoption curve is running ahead of the governance curve. Teams are wiring assistants into mailboxes and gateways into every provider faster than they’re inventorying what those components can touch. The result is a growing set of high-privilege identities that nobody has scoped, monitored, or put a verification step in front of.
What to actually do#
For enterprise AI assistants in the SearchLeak mold:
Monitor AI assistant search and query URLs for encoded instructions sitting in parameters, especially anything that looks like markup or image-embedding directives. Audit content-security-policy allowlists for any domain that performs server-side fetches on user-supplied input, since that’s the bridge that turns a render bug into exfiltration. Where the platform allows it, constrain what the assistant can pull and where its output is permitted to send requests.
For self-hosted AI gateways and proxies, upgrade LiteLLM to v1.83.14-stable or later if you run it. Then treat the gateway as what it is, a credential vault, and act accordingly. Rotate provider keys, database credentials, and any MCP or tool tokens if you can’t rule out exposure. Audit every account with admin-equivalent rights on the proxy and assume those accounts have host-level access. Review custom guardrail and callback code paths, because those are the exec surfaces an attacker reuses after getting in. Keep admin and test endpoints off the public internet.
For the broader posture, the durable fix isn’t a single patch. It’s inventory and least privilege applied to non-human identities. Map where AI tools have standing data access and standing credentials. Scope them down. Put verification in front of the actions that move data or touch secrets.
The patches close these specific holes. The pattern is going to keep showing up under new names, and the teams that inventory their AI tool permissions now will spend a lot less time reacting to the next one.
