Skip to content
AI Security Wire

Published

- 6 min read

By

ZOOMSDAY: AI Built a Zero-Click Zoom RCE Exploit in Under 24 Hours

img of ZOOMSDAY: AI Built a Zero-Click Zoom RCE Exploit in Under 24 Hours

A single researcher, working alone with an off-the-shelf AI model and fewer than 20 prompts, went from a cold start to a working zero-click remote code execution exploit against Zoom in under 24 hours. The target was Zoom’s annotation feature, the tool that lets meeting participants draw and highlight on shared screens. The result, publicly disclosed on August 11 under the name ZOOMSDAY, is a three-bug chain that let any attendee in a call silently take over another attendee’s device, no click required, across Windows, macOS, iOS, and Android.

Zoom patched the flaws quietly between June and July, months before the research went public, and there’s no evidence of in-the-wild exploitation. What makes ZOOMSDAY worth paying attention to isn’t the outcome. Zoom bugs get found and fixed regularly. It’s the timeline, and what that timeline says about how fast AI-assisted vulnerability research has gotten.

The three CVEs

The chain consists of:

  • CVE-2026-53413 (CVSS 8.3): a missing bounds check in Zoom’s annotator function that allows a buffer over-write, enabling remote code execution on another participant’s client.
  • CVE-2026-53414 (CVSS 6.5): a buffer over-read that leaks uninitialized heap memory, including live code and vtable pointers, the exact material needed to defeat address space layout randomization (ASLR).
  • CVE-2026-53415 (CVSS 8.3): a use-after-free in the annotator function that also enables remote code execution.

Zoom tracked the first two under bulletins ZSB-26015 and ZSB-26016. A Security separately scored all three at 9.0 under CVSS 4.0, reflecting the zero-click, zero-interaction nature of the attack path more heavily than Zoom’s own 3.1 scoring did.

How the bug actually works

The annotation feature converts a participant’s drawings and highlights into structured wire objects, each carrying a count field describing how much formatting data follows. One of those fields writes into a fixed 128-byte buffer. According to the researchers, the deserialization routine “reads a 32-bit count off the wire and copies 2 × count bytes in. The count is checked only for being non-zero, there is no comparison against the 128-byte destination anywhere.” Supply an oversized count and the copy runs past the buffer, on the stack corrupting saved registers and the return address, on the heap corrupting adjacent allocations and vtable pointers.

Two things made this reachable without any user action. First, the annotation protocol is proprietary and undocumented, so the parsing logic had never been meaningfully fuzzed or reviewed externally. Second, a missing check on message origin meant a malformed annotation object crafted by one participant could be broadcast to and reconstructed inside every other client in the meeting. No one has to click “allow annotations,” open a file, or approve anything. Joining the call is enough.

What the AI actually did

The interesting part isn’t the memory corruption bug itself, it’s how it was found. A Security describes using publicly available frontier models (the team specifically references working with Claude Opus 4.7 and 4.8) to compress work that would traditionally take a specialized team weeks into a single day. The workflow broke down roughly like this:

  1. Attack surface mapping — the model ranked 3,762 functions across 70 Zoom client libraries by likelihood of containing dangerous memory-unsafe sinks. Notably, the actual vulnerable library initially ranked 45th; researchers had to trace live client execution to catch it, a reminder that AI triage still needs a human checking its homework.
  2. Protocol reverse engineering — reconstructing the undocumented annotation wire format from binary analysis, since no public specification exists.
  3. Vulnerability auditing — flagging the missing bounds check in the deserializer as a concrete, exploitable memory-safety flaw rather than a generic “this looks risky” flag.
  4. Exploit construction — building the actual malformed PDU payloads and validating remote code execution across all four target platforms.

The researchers’ own framing is blunt: “a single researcher was able to develop a nation-state-level exploit in less than a day,” and “the barrier to producing this class of weapon has collapsed, and it won’t come back.” Whether or not you accept the “nation-state-level” comparison at face value, the compressed timeline itself is the story. Work that used to gate this class of bug behind a well-resourced offensive team is now reachable by one person with API access and a few dozen well-aimed prompts.

Impact assessment and what defenders should take from this

For Zoom specifically, the fix is already done: Workplace clients before 7.1.5 and 7.0.6, the Windows VDI client before 7.0.11 and 6.6.16, Zoom Rooms before 7.1.0, and Meeting SDK before 7.1.0 are all affected and should be updated if they haven’t been already. Server-side mitigations were also deployed in July to reduce exposure for meetings still running older clients, though the advisory notes that end-to-end encrypted meetings remain exposed to filtering bypasses since the server can’t inspect encrypted annotation payloads.

The broader takeaway is about exposure windows, not this one product. If AI-assisted research can compress a full discovery-to-exploit cycle for a complex, undocumented binary protocol into a single day, then the gap between “a vulnerability exists” and “a working exploit exists” is shrinking across the board, for every vendor, not just Zoom. Security teams that build patch cadences around the old assumption of weeks-to-months between disclosure and reliable exploitation should revisit that assumption. Practical steps worth prioritizing:

  • Treat any client-side software that parses untrusted, attacker-influenced data from peers (screen annotation, chat rendering, file previews, collaborative editing) as high-risk attack surface, and push vendors for external protocol documentation and third-party audits of these paths.
  • Shorten internal patch SLAs for collaboration and conferencing software specifically, since these tools sit on every endpoint and require zero user error to reach.
  • Assume automated, AI-accelerated fuzzing and function-ranking tools are now within reach of a single motivated researcher or attacker, and factor that into risk models rather than treating it as a future concern.
  • Where vendors offer server-side filtering for legacy or unpatched clients, verify it actually covers your organization’s deployment, and confirm whether encrypted sessions bypass that filtering, as they did here.

References

Frequently Asked Questions

What is ZOOMSDAY?
ZOOMSDAY is the name given by researchers at A Security to a chain of three vulnerabilities, CVE-2026-53413, CVE-2026-53414, and CVE-2026-53415, in Zoom's annotation feature. Chained together, the bugs let any meeting participant silently execute code on another attendee's device with no click, download, or warning required.
Were these vulnerabilities actually exploited by attackers?
No known exploitation has been reported. The flaws are not listed in CISA's Known Exploited Vulnerabilities catalog. Zoom patched them in June and July 2026, roughly two months before A Security publicly disclosed the research in August.
How did AI models help find the bugs?
Researchers used publicly available frontier AI models, working with fewer than 20 prompts total, to rank thousands of candidate functions across Zoom's client libraries for likely memory-safety flaws, reconstruct the undocumented annotation wire protocol, and help build working proof-of-concept payloads. The full path from a blank start to confirmed remote code execution took under 24 hours.
What should organizations do now?
Update all Zoom clients, Rooms, VDI clients, and Meeting SDK deployments to the patched versions immediately if this hasn't already happened. Beyond this specific advisory, security teams should treat AI-accelerated vulnerability research as a standing assumption in their patch-latency and exposure-window calculations, not an edge case.