AI Copilot Vulnerabilities Disclosed in Microsoft Security Update Guides

Microsoft's Security Update Guide now reads less like a one-off bug tracker and more like a running ledger of how Copilot gets broken. The pattern spans Microsoft 365 Copilot, Copilot Personal, Copilot Studio, GitHub Copilot, and Copilot in Azure, and it keeps growing.

Microsoft's Security Update Guide as a ledger of Copilot flaws

Copilot is an IDE plugin in one context, a browser sidebar in another, a mobile app, a core cloud service, and increasingly an agentic runtime that takes actions on its own. Each surface gets built, shipped, and patched on its own, so Microsoft's disclosure record treats it on its own terms too. GitHub Copilot's attack surface has little in common with Copilot Studio's, and Copilot Personal's consumer-facing design differs from the enterprise data access that Microsoft 365 Copilot depends on, yet all of them keep generating CVEs under the same brand.

Treating each disclosure as an isolated bug makes the record look like ordinary software maintenance, with things breaking, Microsoft fixing them, and life going on. But look at the spread across products instead, and you see a different shape. The same categories of failure (information disclosure, improper neutralization of input, privilege escalation) appear repeatedly across completely different Copilot implementations, built by different teams, serving different users. That kind of repetition across unrelated codebases doesn't point to sloppy engineering in any one team. It points to something built into the category of product itself.

Why Copilot's design makes it structurally attractive to exploit

Natural-language input, broad enterprise data access, and trusted cloud infrastructure intersect in Copilot, and that combination is why vulnerability disclosures keep naming Copilot.

Copilot's usefulness depends on broad, continuous access to a user's data and systems. It reads emails, opens files, checks calendars, pulls from SharePoint, scans Teams conversations, and reaches into whatever third-party services a tenant has connected. That access is the entire value proposition. An assistant that can't see your calendar can't schedule around it. An assistant that can't read your files can't summarize them. Copilot's reach is what makes it worth deploying, but that same reach is what an attacker wants, and any flaw that redirects Copilot's attention hands that attacker the permissions the legitimate user already holds.

That's a different risk model than traditional application security. An attacker going after a conventional app usually has to break into the tenant, find a path to escalate privileges, or get malware onto a machine. None of that is necessary here. The attacker only needs to convince the assistant to use access it already has. The defense can't rely on perimeter controls the way older security models do.

The deeper structural piece is how these assistants are built. Most run on retrieval-augmented generation, pulling in content from emails, documents, web pages, and form inputs as a normal part of answering a question. So the assistant is always working with text it did not write and cannot fully check. Embed an instruction inside that text, in a hidden field, in a web page, in a form submission, and the assistant may follow it as if the real user had typed it. That's not a flaw unique to one implementation. It follows from how retrieval-based assistants work.

The four attack patterns that keep reappearing across Copilot disclosures

Pulling the named Copilot CVEs together reveals four attack patterns that recur constantly and form a taxonomy, not just a list of unrelated bugs.

The first is indirect prompt injection, which some call parameter-to-prompt injection. The mechanism: an attacker's instructions get embedded in content the assistant treats as trustworthy, an incoming email, a SharePoint form field, a crafted URL, and the AI acts on those instructions as though the real user typed them. CVE-2026-21520, known as ShareLeak and carrying a CVSS score of 7.5, shows this mechanism in Copilot Studio. Capsule Security found that Copilot Studio concatenated a malicious payload from a public-facing form field directly with the agent's own system instructions, with no sanitization step separating the two. Microsoft's safety mechanisms flagged the attack, and data still exfiltrated. Detection caught the problem and prevention still failed, which tells you those are two separate engineering problems, not one.

A second case in the same family, CVE-2026-24301 and nicknamed CoSnitch, came out of research by Varonis Threat Labs on Copilot Personal. Researchers used a technique they called meta-hacking: they asked the assistant to explain why a certain prompt couldn't run automatically, and kept pressing until it described the exact conditions that would let it. The assistant named the undocumented parameter itself: autorun=1, which let the prompt run automatically with one click. When researchers built a URL using what Copilot had told them, the parameter executed as described.

The second pattern uses HTML rendering race conditions as exfiltration channels. Content Security Policy allowlists exist to block traffic from leaving through unapproved destinations, but in this pattern they function as bridges instead of barriers, letting exfiltration travel through Microsoft's own trusted infrastructure.

The third pattern is persistent memory poisoning. If Copilot Personal summarizes a page, that page can get the assistant to write attacker-supplied instructions into the user's long-term memory store. Those instructions then shape every later session, not just the one where the poisoning happened. Johann Rehberger reported a related case in Microsoft 365 Copilot, tracked as CVE-2026-24299, involving memory writes and deletions through indirect prompt injection, along with memory modification in the consumer assistant. That finding matters because it shows the pattern isn't confined to the consumer product. It reaches the enterprise assistant too.

The fourth pattern covers improper neutralization and command injection inside output components. One vulnerability targeting Microsoft 365 Copilot falls under CWE-74, improper neutralization of special elements in output used by a downstream component. Another, affecting Copilot Chat embedded in Microsoft Edge, falls under CWE-77, command injection. The mechanism in both: Copilot processes a request containing characters or commands that mean something to a downstream system, fails to strip or neutralize them, and includes them in its response. That response then renders inside the Edge sidebar or a Teams context, and unauthorized information disclosure follows over the network. Neither case requires user interaction or elevated privileges to trigger.

Four categories, four distinct mechanisms, and each one keeps reappearing across different Copilot products built by different teams. That recurrence is the evidence that these are structural weaknesses in the category of assistant Microsoft has built, not isolated coding mistakes waiting to be cleaned up one patch at a time.

No customer action required" does not mean no customer risk

A lot of Copilot advisories in Microsoft's Security Update Guide carry a specific note: no customer action required. For cloud-hosted Copilot services, Microsoft calls this an "Exclusively Hosted Service" fix. There's no update package to download, no build number to track, no toggle for an administrator to flip and confirm. Microsoft patches the backend, and the fix takes effect even though no one on the customer side does anything.

That sounds like good news, and in one respect it is: it removes a chunk of operational burden that used to come with every Windows cumulative update or on-prem patch cycle. But it also removes something administrators used to rely on for confidence. There's no patch package to inspect, no staged deployment ring to test in a lower environment first, no way to independently confirm the fix landed. The fix either happened or it didn't, and there's no signal on the customer's end either way.

The real risk variable was never the specific CVE number but how much organizational data Copilot can reach on any given day. A cloud-side patch closes one specific flaw. It does not touch how much of SharePoint, OneDrive, Teams, and mailbox content Copilot was already able to see before the flaw existed, and will still be able to see after the fix ships.

The instinct to read "no customer action required" as "nothing to do here" is exactly the posture the CVE record argues against. ShareLeak exfiltrated data even after Copilot Studio's own safety mechanisms flagged the attack. CoSnitch's autorun prompt ran to completion even if the victim closed the browser tab right after the page loaded. An injected memory entry persists until the user goes in and removes it by hand. None of these outcomes depended on the victim doing anything careless for more than a few seconds.

What stays in the enterprise's hands is the ceiling on what any successful exploit can reach. Oversharing in SharePoint, loose permissions on OneDrive folders, Teams channels open to more people than they need to be, mailbox content sitting without review, all of that defines how much damage a successful Copilot compromise can do, and Microsoft's patch cycle has no visibility into any of it. Reducing that ceiling is a control plane that belongs entirely to the customer.

There's a regulatory angle that makes this concrete for a specific sector. Federal examiners are increasingly asking financial institutions to describe their AI governance posture directly, and "we use Microsoft 365 Copilot" doesn't answer that question anymore. Examiners want an inventory of which agents are deployed, a documented review process for approving new ones, an audit trail of agent activity, and an incident response plan that specifically accounts for the possibility of an AI agent being compromised. None of that comes bundled with a cloud patch.

CVSS scores understate risk for AI information disclosure flaws

CVSS, the scoring system most security teams use to prioritize what gets fixed first, was built for a world of traditional software flaws. Its formulas were never designed to capture the gap between "information disclosure" in a scoped conventional application and the same label applied to an AI assistant sitting on top of broad enterprise data access.

In a conventional scoped application, an information disclosure flaw exposes the data that application itself holds, and nothing more. In a Copilot deployment, the same label can mean exposure of everything the authenticated user's account can see across the entire tenant: email, files, calendar entries, connected services, all of it. CVSS doesn't have a field for "how much of the organization can this assistant see," so two flaws with identical CVSS math can carry wildly different real-world consequences depending on what the Copilot instance behind them was allowed to touch.

Microsoft's own forward-looking signal backs this up. CVE-2026-35435, affecting the Azure AI Foundry agent runtime and the Microsoft 365 Published Agents runtime, carries Microsoft's "Exploitation More Likely" rating, the highest forecast tier Microsoft assigns before in-the-wild exploitation is confirmed. Microsoft itself is flagging elevated concern here, ahead of an actual incident, and that signal sits outside the base CVSS number.

None of this means CVSS is broken as a tool. So a scoring system built for traditional software produces systematically misleading output when you apply it to AI systems with this kind of reach. Security teams that triage purely by CVSS score will consistently underrate this category of flaw, because the number was never built to measure what a compromised assistant can see across an entire organization.

What the agent runtime and RCE disclosures signal

The earlier patterns, injection and exfiltration, establish that Copilot's weaknesses are structural. The most recent disclosures suggest something sharper: the category is escalating from data exposure into code execution and privilege escalation at the platform level.

CVE-2026-50517, published July 24, 2026, carries a CVSS score of 9.9, the highest in its disclosure batch. It's a deserialization-of-untrusted-data flaw in Microsoft 365 Copilot that allows an authenticated, low-privilege attacker to achieve remote code execution over the network with no user interaction required. This sits inside the Copilot codebase as a traditional software vulnerability rather than as prompt injection, so Copilot now carries a full conventional attack surface running in parallel with its AI-specific one.

CVE-2026-59118, carrying a CVSS score of 9.3, affects the Copilot Cowork component inside Microsoft Power Apps. Cowork has access to organizational content and works directly inside user workflows, so an authorization flaw there opens the door to privilege escalation and data manipulation across connected Microsoft services, not just within Cowork.

The direction this points toward: Copilot is moving from a conversational assistant that answers questions into an agentic platform that submits forms, queries services, writes to memory, and operates inside workflows on a user's behalf. As that shift continues, the consequence of a successful exploit shifts with it, from an attacker reading data to an attacker manipulating it and compromising the workflows built around it.

Capsule Security found it highly unusual that a CVE was assigned to a prompt injection vulnerability in an agentic platform. That reaction says something important: the frameworks the security community uses to classify AI-agent flaws are still being worked out, even as the flaws themselves keep arriving on schedule. The attack surface is outpacing the vocabulary built to describe it.

What enterprises must do beyond Microsoft's patch cycle

Microsoft's patch cycle closes individual flaws. It cannot tell an organization how much of its own data Copilot is able to reach, and that's the variable that determines how bad any future exploit will be. Reviewing SharePoint, OneDrive, Teams, and mailbox permissions for oversharing is work no vendor patch touches, and it directly sets the ceiling on what a compromised Copilot session can expose.

An agent inventory belongs on every security team's list: which Copilot products and agents are active, what data each one can access, and who approved that access. A documented review process for approving new agents matters just as much as the inventory itself, since new agents keep getting added faster than most governance processes account for. Audit logging deserves attention too. Microsoft has stated that memory updates get recorded to organizational audit logs, surfaced through Defender Advanced Hunting, Defender Sentinel, and Azure Portal Sentinel Analytics, through a MemoryUpdated field SOC analysts can join against other signals. That log exists. Whether an organization is actually watching it is a separate question.

Incident response plans need an explicit scenario for AI agent compromise, distinct from a stolen credential or a phished account, because the mechanics of recovery differ: a poisoned memory entry needs to be found and removed, not just a password reset. The CVE record shows these aren't hypothetical scenarios built for a tabletop exercise: they're documented, named, and scored. Microsoft will keep closing the specific flaws as they surface. What Copilot can reach inside any given organization is a question only that organization can answer.