Zoom Annotation Flaws: Patch Before Sharing Secrets in Meetings

Zoom has published three security bulletins for flaws in its annotation component, including two issues that Zoom says may allow one meeting participant to execute code on another participant's client. The fixes reached supported client branches in June and July, before coordinated public disclosure on August 11, 2026.

Researchers at A Security describe a path in which a malicious participant sends a crafted annotation message to another client without a click, download or prompt from the victim. No exploitation in the wild had been reported when the research became public, and the three CVEs were not in CISA's Known Exploited Vulnerabilities catalog when checked on August 12.

What Zoom's bulletins confirm

CVE-2026-53413 is a high-severity buffer over-write in the annotator function. Zoom assigns CVSS 8.3 and says a meeting participant may be able to achieve remote code execution on another participant's client through network access.
CVE-2026-53414 is a medium-severity buffer over-read in the same component. Zoom assigns CVSS 6.5 and describes denial of service as the potential impact. A Security reports a more consequential information-disclosure primitive, but that broader impact is the researcher's assessment rather than Zoom's.
CVE-2026-53415 is a high-severity use-after-free in the annotator function. Zoom assigns CVSS 8.3 and says it may allow participant-to-participant remote code execution through network access.

Zoom's CVSS vectors mark user interaction as required. A Security describes the exploit path as zero-click from the victim's perspective once both parties are in the meeting. Those statements are not identical, so organizations should not erase the difference: the vendor confirms serious network-reachable flaws inside a meeting, while the zero-click exploitation chain comes from the original research.

Versions that close the three CVEs

Administrators should use the current Zoom release rather than treating the following versions as a long-term target. These are the minimum fixed branches listed in Zoom's bulletins:

Zoom Workplace: 7.1.5 or later, or 7.0.6 or later on the 7.0 branch.
Zoom Workplace VDI Client for Windows: 7.0.11 or later, or 6.6.16 or later.
Zoom Rooms and Zoom Meeting SDK: 7.1.0 or later for CVE-2026-53413 and CVE-2026-53414.
Zoom Rooms and Zoom Meeting SDK: 7.1.5 or later for CVE-2026-53415.

The affected-product language covers all supported platforms for Zoom Workplace, Zoom Rooms and the Meeting SDK, with the VDI bulletin entries specifically naming Windows. Checking only a user's laptop is therefore insufficient when conference rooms, VDI pools or applications embed the Meeting SDK.

The patches predate the headlines

A Security says it discovered the annotation memory-corruption issue on June 8, confirmed a working exploit the next day and reported it to Zoom on June 10. Its disclosure timeline says Zoom shipped the client-side fixes for CVE-2026-53413 and CVE-2026-53414 in version 7.1.0 on June 22, added a server-side mitigation for older clients on July 15, and fixed CVE-2026-53415 in version 7.1.5 on July 20.

Public technical disclosure followed on August 11. This sequencing means a normal, timely update program could have removed the client flaws before exploit details became public. It also means the correct response is to verify deployed versions, not to wait for a new emergency patch that already exists.

The Hacker News reported no known exploitation as of publication. The three CVEs were also absent from the CISA KEV catalog snapshot released on August 11. KEV absence is a prioritization signal, not proof that nobody has exploited a flaw, and it does not reduce the need to update a meeting client that processes content from external participants.

A meeting invitation is an endpoint trust decision

Waiting rooms, passcodes and authenticated-participant rules help keep unknown people out, but the research demonstrates why admission is only the first boundary. Once admitted, a participant can send structured feature data to other clients. Annotation, screen sharing, remote control, file transfer and whiteboarding all expand what the client must parse.

Enforce minimum versions. Inventory Workplace, VDI, Rooms and Meeting SDK deployments, then block obsolete branches where the platform allows.
Limit who can enter sensitive meetings. Use waiting rooms, authenticated participants and unique meeting links rather than a reused public personal-room URL.
Disable unused collaboration features. If annotation is not required, turn it off. Apply the same necessity test to remote control, file transfer and third-party meeting apps.
Do not rely on a server filter as the durable fix. A Security says Zoom deployed a server-side mitigation for older clients, but client updates close the vulnerable code path and remain the primary control.
Watch the endpoint. Unexpected browser, shell or script launches from the Zoom process tree and clusters of client crashes deserve investigation.

Keep credentials off the shared screen

Incident bridges, vendor support calls and deployment sessions often combine screen sharing with urgent requests for passwords, recovery codes, API keys or private configuration. Displaying a secret on screen or pasting it into meeting chat makes every participant and every participating endpoint part of that secret's trust boundary. Recording and transcription can create additional durable copies.

Keep the meeting for context and verbal coordination, then move an approved secret handoff to a separate channel. Verify the recipient independently, use an expiring one-time encrypted link, confirm receipt and rotate the value after the task. Do not read the secret aloud, expose it in a shared terminal or paste the plaintext into the call's chat or notes.

Secretus can reduce plaintext copies during that narrow transfer, but it cannot make a vulnerable or already-compromised meeting endpoint safe. A malicious client can capture a secret after decryption. Patch first; for a high-risk incident, use a known-clean device and an independently verified recovery channel before delivering credentials.

Questions for a sensitive-meeting runbook

Can the organizer enforce a fixed Zoom client version for staff and guests?
Are Zoom Rooms, VDI pools and embedded Meeting SDK versions inventoried?
Which collaboration features are enabled by default but not actually needed?
How will participants exchange a recovery code without showing it on screen?
Who can move the incident bridge to a clean platform or device?
Which secrets must be rotated if a participant endpoint is later suspected?

The central lesson is narrower than the exploit headline: a trusted meeting room is still a network between endpoints. Patch the clients that interpret meeting data, restrict who and what can participate, and keep the secret itself on a separate, short-lived delivery path.