Three Zoom annotation bugs made every screen share a two-way takeover path

Zoom has patched three flaws in the annotation tool, the feature that lets participants draw on a shared screen, that on the paths researchers traced allowed a viewer to run code on the presenter's machine and the presenter to run code on every viewer's ^[1][2]. The client fixes shipped in June and July, roughly two months before the write-up that made the mechanism public, so any fleet still on an older build is now behind a documented route rather than a theoretical one ^[3].

The versions that close the set: Zoom Workplace on all supported platforms before 7.1.5 and 7.0.6 in their respective branches; the Workplace VDI Client for Windows before 7.0.11 and 6.6.16; Zoom Rooms and the Zoom Meeting SDK before 7.1.0, and before 7.1.5 for the third flaw ^[4]. SecurityAffairs described the Workplace 7.1.5 and 7.0.6, Rooms 7.1.5 and Meeting SDK 7.1.5 releases as landing "this week," which does not sit cleanly beside the June and July timeline reported by The Hacker News ^[5][3]. No exploitation has been reported, and none of the three identifiers is in CISA's Known Exploited Vulnerabilities catalog ^[6].

Zoom has published no technical detail, so the internals come from the reverse engineering done by A Security, the Israeli-founded offensive-security startup that left stealth in June with $37 million ^[7][8]. A drawing does not cross the wire as an image: the client serialises it into a structured object sent as a run of counts followed by data, and the receiver trusts those counts to decide how much to read ^[9]. One field fills a fixed 128-byte buffer with no length check, and because it is the object's last field, an oversized count runs past the end and over the return address ^[10]. The bug sits in CAnnoFormatBlock::Deserialize in libannotate.so, reachable through Zoom's normal encrypted transport ^[11].

What turns one malformed drawing into a room-wide problem is a missing origin check. Every viewer holds a channel to the sharer and the sharer holds one back for acknowledgements; the dispatcher reads the type number off the wire and hands it to the matching parser without asking which seat the sender occupied ^[12]. 0x10001 means here is an object, 0x10002 means I received yours, and sending the first where the second belongs makes the victim's client rebuild the object in full ^[13].

The two accounts of severity diverge. Zoom tracks CVE-2026-53413 at CVSS 8.3, CVE-2026-53414 at 6.5 and CVE-2026-53415 at 8.3 ^[14]; A Security puts all three at 9.0 under CVSS 4.0, a figure in none of the bulletins ^[15]. Zoom issues its own CVE records and NIST no longer routinely re-scores them, so the lower numbers will likely stand ^[16]. All three vendor vectors also mark user interaction as required, which is hard to reconcile with the zero-click framing ^[17]. On the over-read, the firm says it recovered uninitialised heap memory holding live code and vtable pointers, the material an address-randomisation bypass needs; the advisory says the bug may allow denial of service and scores confidentiality impact at none ^[18][19]. Credit splits too: two bulletins name Idan Levcovich of A Security, while the use-after-free is credited to Zoom Offensive Security, the in-house team behind the 9.8-rated account takeover flaw patched in July ^[20][21].

Treat the AI framing carefully. The firm says it went from flaw to working exploit in under a day using fewer than 20 prompts on publicly available models, but names no model, and its own account is messier: the automated first pass produced a queue of 3,762 functions across 70 libraries and ranked the vulnerable library 45th, surfacing only under live dynamic tracing ^[22][23][24].

Watch whether Zoom or NIST revises the scores, whether the identifiers reach KEV, and whether your VDI estate got the 7.0.11 and 6.6.16 builds, which are easy to miss when the headline number is 7.1.5 ^[4].