Zoomsday Turned a Meeting Invite Into Zero-Click Code Execution

A.Security’s August 11 disclosure documented a working exploit chain that allowed one participant in a live Zoom meeting to execute code on another attendee’s vulnerable native client without a click or visible warning; it identified Zoom Workplace versions before 7.1.5 and 7.0.6, Windows VDI clients before 7.0.11 and 6.6.16, and Zoom Rooms and Meeting SDK releases before 7.1.0 as affected in their respective branches.

The invitation itself did not compromise a device. The target first had to join a meeting containing the attacker, but the vulnerable annotation parser then processed participant-supplied data automatically, even when nobody appeared to be drawing or using a whiteboard.

Why joining the meeting exposed the client

Zoom annotations cross the network as structured objects rather than completed images. Receiving clients deserialize descriptions of text, shapes and formatting before sending the reconstructed objects to the renderer, placing native parsing code in contact with data controlled by another participant.

The researchers found an unchecked count in the text-formatting path that could copy more data than fixed-size buffers were designed to hold. A separate over-read could reveal memory useful for bypassing address randomization. Combined, the flaws moved the result beyond a client crash to demonstrated remote code execution.

TechRadar’s independent account described the malicious annotation messages as automatically parsed and found that the attacker could be either the host or a guest. The meeting channels allowed a presenter to address viewers, while a viewer could direct annotation traffic toward the presenter.

This makes zero-click accurate for the exploitation stage, but “zero interaction” would be misleading. The victim still had to enter the same meeting as the malicious participant. In the headline, the meeting invite is the route into that dangerous context, not a calendar item that executes code merely by arriving.

Affected versions depend on product and branch

The exposure matrix is not a single universal Zoom version. Administrators must match each installed product to its release branch and supported platform:

• Zoom Workplace, all supported platforms: releases before 7.1.5 and 7.0.6 in their respective branches.
• Zoom Workplace VDI Client for Windows: releases before 7.0.11 and 6.6.16 in their respective branches.
• Zoom Rooms, all supported platforms: releases before 7.1.0.
• Zoom Meeting SDK, all supported platforms: releases before 7.1.0.

The annotation implementation was shared across native clients, and the research covered Windows, macOS, iOS and Android. Administrators should therefore use the published product cutoff instead of assuming that an operating system not featured in a particular demonstration is outside the affected scope.

A server-side filter can protect older clients when Zoom’s infrastructure can inspect the meeting traffic. That protection does not extend to end-to-end encrypted meetings, where the service cannot read and filter the crafted annotation payload. Updating the endpoint remains the durable fix.

What administrators should do now

1. Inventory Zoom Workplace, the Windows VDI Client, Zoom Rooms and Meeting SDK deployments separately, including the complete installed version and branch.
2. Update each deployment to at least the applicable fixed release shown above, or preferably the newest version approved for the organization.
3. Use Zoom’s minimum-version controls where available and apply them to guests as well as managed users.
4. Until older clients are removed, assess whether end-to-end encryption should be disabled for affected meetings so the server-side filter remains available.
5. Restrict meeting entry with waiting rooms, passcodes or authenticated-user policies, and disable annotation where it is unnecessary. These controls reduce reachability but do not repair the vulnerable parser.

Endpoint monitoring can add visibility while updates are deployed. Exploited code inherits the permissions of the Zoom process, and failed attempts may terminate the client. An unexpected browser, shell or script interpreter launched by Zoom is therefore worth investigating, although the absence of such activity does not establish that a device is patched.

AI-assisted exploit development narrows the patch window

Tom’s Hardware’s August 13 report highlighted the researchers’ claim that a small team produced the working exploit with fewer than 20 prompts to an AI agent. Human researchers still chose the target, redirected the investigation when an early approach failed, and validated the resulting chain.

That result does not prove that every vulnerability can be weaponized on the same schedule. It does show that closed source code and an undocumented protocol no longer guarantee a lengthy reverse-engineering delay. AI assistance helped rank code, reconstruct the annotation protocol and accelerate exploit development against software already exposed to untrusted meeting participants.

The operational consequence is a smaller margin between disclosure and practical attack capability. Conferencing clients accept complex input from guests and external organizations during routine work, so an outdated endpoint may become reachable through an ordinary meeting rather than a conventional malicious attachment.

As of the public reports, the demonstrated exploit was working and fixes were available. The remaining risk is concentrated in endpoints below the correct product and branch cutoff, particularly older clients used in end-to-end encrypted meetings where server filtering cannot compensate for the missing client update.

Also read:

• Linus Torvalds Rejects an AI Ban as Linux Sets Rules for Assisted Code
• Mastering AI-Assisted Coding: Boris Tane's Disciplined Workflow with Claude Code
• Golden Globes 2026: ‘One Battle After Another’ Turned Nine Nods Into Four Wins