One Zoom Participant Could Seize Another’s Computer Without a Click

Tom’s Hardware’s August 13 report detailed a patched Zoom exploit chain through which one meeting participant could execute code on another attendee’s computer without a click, download or approval prompt. The attacker had to join the same meeting but did not need to be its host.

The complete client-side answer depends on the installed branch. Zoom Workplace 7.0 installations need version 7.0.6 or later, while the 7.1 fast-track branch needs 7.1.5 or later to close all three disclosed vulnerabilities. Administrators should verify the version running after installation and restart, not merely whether an update job was assigned.

Why joining a meeting created the attack boundary

The exploit did not depend on a malicious link, file or remote-control request. Zoom’s native clients automatically reconstructed serialized objects used by the annotation feature, including objects received through an active meeting even when nobody was drawing on a shared screen or whiteboard.

A Security’s technical disclosure documents the annotation-parser path, CVE-2026-53413, CVE-2026-53414 and CVE-2026-53415, the coordinated client and server mitigations, and the remaining exposure of outdated clients in end-to-end encrypted meetings. Crafted count and object values could make the recipient read or overwrite memory outside the intended buffers, giving the attacker a route from ordinary meeting traffic to code execution.

The meeting itself supplied the necessary access. A participant could direct malicious annotation data toward a presenter, while a malicious presenter had a channel to individual viewers. The recipient did not have to activate annotation, accept control, open an attachment or respond to a warning.

Code reached through this path would initially run with the permissions of the Zoom process and logged-in user. That is still a serious endpoint compromise, but it is not the same as automatic administrator, root or kernel access.

Which Zoom releases close the full client-side path

The safest decision is based on product and branch, not on whether a version number merely begins with 7. The first two flaws were addressed earlier on the 7.1 line, but the third required the later fast-track release; therefore, 7.1.0 is not the floor for the complete disclosed chain.

• Zoom Workplace 7.0 branch: versions below 7.0.6 require an update to 7.0.6 or a later supported release.
• Zoom Workplace 7.1 fast-track branch: versions below 7.1.5 require an update to 7.1.5 or later.
• Managed desktop fleet: apply the relevant branch rule to the version actually installed on every Windows, macOS and Linux endpoint.
• Other Zoom products: do not apply the ordinary Workplace desktop floor to VDI clients, Zoom Rooms, Meeting SDK or Video SDK packages.

Zoom’s ZSB-26017 bulletin, revised August 14, lists Zoom Workplace before 7.1.5 and 7.0.6 in their respective branches as affected by CVE-2026-53415; it separately sets floors of 7.0.11 and 6.6.16 for the Windows VDI client, 7.1.5 for Zoom Rooms and Meeting SDK, and 2.6.5 for Video SDK. These separate boundaries make product classification a necessary first step in any inventory check.

Organizations already running a release later than the applicable floor do not need to downgrade to one of the named patch versions. The named releases are minimum boundaries for this chain, not preferred long-term targets; the current supported organizational package remains the better destination.

How administrators can verify managed installations

An approved package or completed deployment task does not prove that a patched client is running. The decisive evidence is the installed application or executable version observed after the package has been applied and the old Zoom process has exited.

1. Separate Zoom Workplace desktop clients from VDI, Zoom Rooms, Meeting SDK, Video SDK and mobile installations.
2. Group Workplace desktop clients by release branch and operating system.
3. Flag 7.0 clients below 7.0.6 and 7.1 clients below 7.1.5.
4. Move older or unsupported branches to a currently supported organizational release rather than preserving them at an obsolete version.
5. Deploy the approved package and close or restart Zoom where the management workflow does not do so automatically.
6. Collect the installed or executable version again, then isolate installation failures, offline endpoints and machines still running the earlier process.
7. Compare a sample of client-reported versions with the management inventory on each supported desktop platform.

Management tools may display a package version, file version and short public release differently. Inventory should therefore retain the complete value available from the endpoint and map it to the public Zoom release, rather than deciding compliance from a truncated string.

Server filtering reduces risk but does not replace patching

Zoom deployed server-side filtering intended to stop malicious annotation messages before they reached older clients. That mitigation cannot inspect meeting content when end-to-end encryption prevents the server from reading it, leaving the client-side update as the reliable control across meeting configurations.

Waiting rooms, passcodes and authenticated-user requirements can reduce who reaches the vulnerable parser, but they do not repair it. An admitted malicious participant or a compromised authorized account would already be inside the attack boundary.

As of August 15, the patches and product-specific boundaries are public. The remaining operational question is which endpoints still fall below their applicable floor: 7.0.6 for the Workplace 7.0 branch, 7.1.5 for its fast-track branch, or the separate minimum assigned to another Zoom product.

Also read:

• 9 Ways to Find Your Life Purpose—Without Waiting for One Perfect Answer
• Claude Mythos Just Gave One Company Government-Level Cyber Weapons — And It’s Only April 2026
• Download YouTube Subtitles Without the Video—But Check Permission First