Zoom Annotation RCE Makes Meeting Membership An Endpoint Boundary

Zoom published three security bulletins on August 11 for flaws in its annotation code. Two bulletins describe remote-code-execution paths from one meeting participant to another, while a third describes a denial-of-service path. Zoom revised all three bulletins on August 14, adding the Video SDK to the affected-product lists and correcting the Zoom Workplace version boundary for two of the flaws. The safe version is not one number across every product line.

A Security, which reported two of the flaws, says it built a working exploit against the proprietary annotation protocol and demonstrated code execution without a separate click from the target beyond participating in the meeting. That is the researcher's account, not evidence of exploitation in the wild. Organizations should update every native client class, verify actual deployment rather than installer approval, and treat meeting admission as an endpoint-security decision while older clients remain in circulation.

ZSB-26015 covers CVE-2026-53413, a missing bounds check that Zoom says can let a meeting participant overwrite a buffer and achieve remote code execution on another participant through network access. Zoom lists Workplace on all supported platforms before 7.1.0 and 7.0.6 in their respective branches, the Windows VDI client before 7.0.11 and 6.6.16, Rooms and the Meeting SDK before 7.1.0, and the Video SDK before 2.6.0. The bulletin assigns CVSS 8.3 High, with user interaction represented by joining or participating in a meeting rather than approving a malicious file.

ZSB-26016 covers CVE-2026-53414, an over-read in the same annotator function. Zoom describes denial of service rather than code execution and assigns CVSS 6.5 Medium. Its affected-version table matches CVE-2026-53413. A Security says the over-read exposed live process memory that helped its exploit work around address randomization, but Zoom's public bulletin states only the supported impact. Defenders can use the research for technical context without silently expanding the vendor's confirmed claim.

ZSB-26017 covers CVE-2026-53415, a use-after-free that Zoom says may also permit participant-to-participant remote code execution. Its later fixed boundaries matter: Workplace before 7.1.5 and 7.0.6, Windows VDI before 7.0.11 and 6.6.16, Rooms and the Meeting SDK before 7.1.5, and the Video SDK before 2.6.5. A fleet-wide baseline must therefore use the highest applicable fixed version for each installed product, not the first patched number found in a summary.

A Security says Zoom's native annotation feature serializes drawing objects into protocol data units and sends them through the meeting infrastructure. Receiving clients deserialize those objects. The researchers report that an attacker-controlled count could drive an oversized copy into a fixed 128-byte buffer in a text-format object. Because the receiving client automatically parses the message, the target did not need to open a document, click a link, or use the annotation tool at that moment.

The research describes a second flaw that could leave uninitialized heap contents in a glyph buffer, and it explains how the overwrite and information leak were combined for code execution on macOS. It also reports an Android control-flow path using heap shaping. Zoom's own bulletins do not reproduce those exploit details or claim that every possible target configuration is equally exploitable. The reliable common statement is narrower: Zoom acknowledges participant-to-participant code-execution risk in the affected products and provides fixed-version boundaries.

The same distinction applies to the phrase zero-click. A target still has to be present in a meeting with the attacker, which Zoom's CVSS vector treats as user interaction. Once that precondition exists, the research says no second action is needed. For risk decisions, this is more useful than arguing over the label: an invited guest, compromised account, or weakly controlled meeting link can put attacker-chosen bytes in reach of a privileged collaboration client.

A Security reports that Zoom shipped a client fix in June and a server-side mitigation on July 15 that filters malicious annotation messages before they reach older clients. The researchers say that filtering works for Zoom's default enhanced encryption because the service can inspect meeting content, but not for end-to-end encrypted meetings because the server does not possess the meeting keys. Zoom's E2EE documentation confirms the key boundary: participant devices generate and hold the keys, while Zoom's servers cannot decrypt the meeting stream.

This does not make E2EE defective. It means confidentiality from the service and server-side content filtering cannot both apply to the same encrypted payload. A malicious participant already holds legitimate meeting keys, so encryption does not validate the safety of the application objects that participant sends. The decisive control is a fixed parser on every endpoint. Temporarily changing encryption mode may expose older clients to the reported server filter, according to A Security, but that researcher guidance is not a substitute for Zoom's instruction to install current updates.

Organizations should avoid turning this incident into a general argument against end-to-end encryption. The operational question is whether any E2EE meeting can include a client below its applicable fixed version. If the answer is unknown, pause sensitive E2EE sessions or constrain them to verified devices until the inventory is complete. Document the temporary decision, its privacy effect, and the condition for restoring the normal encryption policy.

A normal endpoint rollout can miss mobile devices, user-installed fast-track clients, slow-track clients, stale laptops, and machines that accepted the package but have not restarted the application. Zoom's Dashboard can summarize client versions, endpoints, joins, and VDI data. Use that evidence alongside MDM, software-management, and EDR inventories. The target is proof that the running binary meets the correct branch boundary, not merely a successful deployment status.

VDI needs paired attention. The host client and the endpoint plugin can move on separate schedules, and Zoom's bulletin names the Windows VDI client explicitly. Rooms are another device class, not a desktop exception. Embedded Meeting SDK and Video SDK versions belong to application owners and release pipelines, so the collaboration team may need evidence from product engineering rather than the device-management console.

External participants remain outside an organization's patch authority. For sensitive meetings, admission policy can require a current native app, a managed device, or another approved access path. Record exceptions instead of assuming that Zoom's general quarterly minimum is sufficient. Zoom's lifecycle minimum is a broad support floor and can lag the fixed version for a newly disclosed security issue.

A participant had to reach the meeting before the reported path became useful. Waiting rooms, passcodes, authenticated-user requirements, restricted personal meeting IDs, and careful host admission therefore reduce who can send meeting traffic to endpoints. These controls are especially important for public events, vendor calls, recruiting sessions, and support meetings where outsiders routinely join. A familiar display name is not identity proof if the account behind it was compromised.

Zoom lets administrators disable annotation or restrict it to the person sharing, and those settings can reduce unnecessary collaboration surface. The research, however, says affected clients parsed the vulnerable message even when a participant was not actively using the feature. Treat feature restriction as defense in depth and operational containment, not as proof that an unpatched binary is safe. The vendor bulletins identify updating as the corrective action.

Meeting hosts should also separate audience scale from endpoint trust. A large call does not automatically mean compromise, and a small internal call is not automatically safe. The relevant factors are whether an attacker could become a participant, whether vulnerable native clients joined, and whether endpoint evidence shows abnormal behavior during or after the session.

Neither Zoom's bulletins nor A Security's disclosure reports exploitation in the wild. There are no public campaign indicators, attacker infrastructure, or universal file hashes in the cited material. Organizations should not declare every meeting client compromised or reimage entire fleets solely because an affected version existed. That would confuse exposure with evidence of execution.

Higher-risk environments can still review crash telemetry and EDR process trees for affected clients during the exposure window. A conferencing process unexpectedly launching a browser, shell, script interpreter, downloader, or persistence mechanism deserves investigation. The research demonstration caused the macOS client process to launch Safari, but that behavior is an example from the proof of concept, not a complete detection signature. Attackers could choose another child process or remain inside the compromised process.

If evidence indicates execution, preserve the endpoint, meeting identifier, participant list, client version, operating system, crash artifacts, and nearby network and identity logs. Then scope the data and credentials accessible to that user's process and session. Patching closes the known code path; it does not remove persistence or invalidate credentials that may already have been captured.