Zoom Zero-Click RCE Exploit Built With AI in Under 24 Hours

A drawing tool that could take over a computer

Zoom's annotation feature lets people draw and type on a shared screen during a meeting. It is one of the least threatening parts of the product, and it turned out to contain one of the most serious client-side bugs of the year. In August, Zoom fixed a set of memory-corruption flaws in this feature. Researchers at A Security named the set "Zoomsday." The most serious one, CVE-2026-53413, let a meeting participant run code on another participant's machine without that person doing anything.1116 The victim did not have to click, download or approve anything, and nothing on screen showed that the attack had happened.1518

The bug itself is a familiar kind. The headlines came from how it was found. A Security says it went from finding the flaw to a working exploit in less than a day, using fewer than 20 prompts to publicly available AI models.1218 For anyone tracking AI security, this is the important part. Zoomsday is not a prompt injection attack, and it is not an attack on a model. It is an example of AI agents, connected to professional reverse-engineering tools, sharply cutting the time it takes to turn a flaw in widely used software into a working attack.

How the attack worked

Reports on the technical details mostly agree. The flaws are in Zoom's annotation engine, which handles collaborative drawing during screen sharing.13 Annotations do not travel over the network as images. The client converts each one into a structured object made of length counts followed by data, and the receiving client trusts those counts when deciding how much to read.15 In CVE-2026-53413, the deserializer takes a count from the network and copies data into fixed 128-byte buffers without checking that it fits. An oversized count overflows the buffer and can overwrite the return address.131516

A second design problem made the bug reachable. According to Levcovich, the person sharing their screen is only supposed to send acknowledgment messages back to viewers. But a sharer can put an annotation inside an acknowledgment, and the viewer's client will process it as a normal annotation.12 Coverage of the researchers' work also says the message dispatcher passes messages to parsers based on a type number without checking which role the sender has in the meeting.15 As a result, an attacker gets a direct channel to individual participants.16

There were two companion bugs. CVE-2026-53414 is a buffer over-read that can crash a participant's client. CVE-2026-53415 is a use-after-free in how the client handles "auto-shape" metadata, and it can also lead to code execution.1216 On macOS, the researchers got code execution by overwriting stack memory. They noted that the code had no stack canary or pointer authentication to stop this, but that an attacker would still need at least one leaked pointer to get past address space layout randomization (ASLR).12 One analysis says the Android version of the exploit relied on heap spraying and vtable corruption.13

Where the reporting disagrees

Coverage differs on several points that matter.

Severity. Zoom gives CVE-2026-53413 and CVE-2026-53415 a CVSS score of 8.3, High.115 Orca lists the same bugs at 8.3 and 9.013, and one explainer says the main flaw reaches 9.8 under CVSS v3.x.17 The Hacker News notes that Zoom rates the bugs lower than A Security does. Zoom's advisory for one of them describes the impact as denial of service and scores its confidentiality impact at none.15 Since there is a working code-execution chain, the higher scores look more realistic for organizations deciding what to patch first. Still, the ASLR requirement means a real attack needs more than one malformed message.

Credit. A Security presents all three bugs as its own discoveries. Zoom's advisory for the use-after-free credits Zoom's internal Offensive Security team, and A Security acknowledges that Zoom already knew about that bug and was blocking it on the server side before the report came in.1516

Scope. Some reports describe the attack as compromising everyone in a meeting at once.1320 Levcovich's own description is narrower: the attacker builds a malformed annotation and sends it to one chosen participant.12 In practice, an attacker who can target each person individually could still reach everyone in the meeting, so the difference matters less than it seems. The more precise description is one target at a time.

How much the AI did. This is the most important disagreement. One AI-generated explainer says the models found the bug and wrote the exploit "without a human manually reverse-engineering the binary."17 The more careful accounts do not support that. A Security's first approach, an automated ranking of 3,762 functions across 70 libraries, placed the vulnerable library 45th and missed it entirely. The bug only turned up when researchers traced the running client during a live call, one feature at a time.155 APIsec's analysis says experienced humans picked the target and the method and directed the tools, and that the AI did not decide to attack Zoom on its own.5 There is also a question of verification. The Hacker News reported that A Security's writeup did not name a model, so the claim could not be checked independently.15 Levcovich later told SC Media that the team used Anthropic's Claude Opus 4.7 and Opus 4.8, along with MCP integrations for IDA Pro and Frida.12

The best reading is that experts using AI agents moved much faster than they could have alone. That is a narrower claim than "AI hacked Zoom," and it is the one the evidence supports.

The AI agent angle: tools, not prompts

The setup matters for how we think about AI agent risk. The models were not working only from text. Through MCP connectors they could operate a disassembler and a dynamic instrumentation framework, take actions and respond to results from a live program.125 APIsec describes the change as AI speeding up work that used to take a lot of manual effort across reverse engineering, protocol analysis, debugging and exploit writing, which shortens the time between knowing a bug exists and proving it can be exploited.5 Levcovich goes further. He argues that this kind of exploit used to require nation-state teams and months of work, and that the barrier "has collapsed."1815

That changes the defender's threat model, but not in the way the usual AI security categories suggest. Prompt injection and adversarial machine learning are about tricking a model into misbehaving. Zoomsday is the reverse: the model did what it was asked, and what it was asked to do was attack a parser. The defensive concern here is not that models can be manipulated. It is that tool-equipped agents are very good at the slow, painstaking work that used to keep memory-corruption bugs in closed-source software out of reach for most attackers. Huntress's Bryson Byrd put it simply: vendors have less time now, and they need to use the same AI tools to find and fix flaws first.20

Agents are targets too

Zoomsday shows agents being used for attacks. Research published a month later shows them being attacked. AIR disclosed "Plugin4Shell," a zero-click remote code execution flaw affecting Claude Code, Codex, GitHub Copilot and Gemini CLI.37 The agents pinned plugins to a specific, reviewed commit but never checked that the checkout actually landed on that commit. An attacker who controlled the plugin's repository could create a branch named after the pinned commit hash, and git would load the branch instead. Because plugins update automatically in the background, the malicious code would install with no user action.67

Vendors responded unevenly. Anthropic and OpenAI shipped fixes. Microsoft had not, and Google retired Gemini CLI instead of patching it.3 GitHub says it does not allow branch names that look like commit hashes, so the attack does not work on GitHub. AIR responds that marketplaces hosted on platforms like Bitbucket are still exposed.7 As one analyst noted, the danger comes from what agents can access: plugins usually run with the same access as the developer, including source code, credentials and CI/CD systems.9

The two disclosures together show both sides of the problem. AI agents make it faster to find bugs in other software, and the agents themselves create new ways in, because they run code automatically with broad permissions.

What defenders should take from this

The immediate steps are simple. Client fixes shipped in June and July, about two months before public disclosure, and no exploitation had been reported when the bugs were announced.15 Patched versions include Zoom Workplace 7.1.5 and 7.0.6, plus updated builds of Zoom Rooms, the Meeting SDK and the VDI client.1520 Zoom is used by about 70% of the Fortune 10020, so administrators should confirm that every client is actually on a patched version rather than assuming auto-update took care of it.

The longer-term lesson is about time. Zoomsday was handled the traditional way: private disclosure, patches first, and publication later, timed so customers had both the client update and the server-side fix.11 That approach assumes defenders have weeks or months. If attackers with AI agents can go from a closed-source binary to a working exploit in a day, the assumption no longer holds. Zoom's annotation protocol is undocumented, closed-source and was assumed to be well protected20, and that obscurity no longer adds much protection. Defenders should assume that every feature that parses data from other users, including whiteboards, chat attachments and plugin updates, is being examined by agents that are faster than people.