Zoom's annotation engine hands any meeting attendee code execution on every other device

Two memory corruption bugs in the Zoom code that draws on shared screens let any participant in a meeting execute arbitrary code on every other attendee's device with no clicks and no prompts, according to a research writeup published by Orca Security ^[1][6]. That moves Zoom client version control out of the patch-Tuesday queue: anyone who can get into a meeting can own everyone in it.

CVE-2026-53413 and CVE-2026-53415 are both listed at CVSS 8.3/9.0 and affect Zoom Workplace clients across all platforms ^[1]. Both sit in libannotate.so, the annotation engine behind collaborative drawing during screen sharing ^[3]. In the first, `CAnnoFormatBlock::Deserialize` accepts a 32-bit character count from the network without bounds checking it against fixed 128-byte buffers, giving a stack buffer overflow ^[4]. A 32-bit count can express values up to 4,294,967,295, roughly 33.5 million times the size of the buffer it is trusted to fit ^[1]. The second is a use-after-free in auto-shape metadata handling that yields a write-what-where primitive ^[5]. Chained, an attacker joins a meeting, sends crafted annotation messages, and gets code execution on the other endpoints, with no authentication beyond meeting access and no user interaction ^[6].

Two lower-severity issues shipped in the same disclosure: CVE-2026-53414, a heap buffer over-read in the same annotation parser rated CVSS 6.5 that can cause denial of service or information disclosure ^[7], and CVE-2026-53416, a path traversal specific to the Zoom Workplace VDI Client for Windows ^[8]. That is four CVEs, two of them zero-click remote code execution ^[2].

The reason this is not a normal client update is portability and cost of attack. Orca says the vulnerable library compiles identically across every supported platform, so the same exploit logic works everywhere ^[9]. Researchers at A Security demonstrated a working exploit chain built in under 24 hours using fewer than 20 prompts on publicly available AI models ^[10]. The macOS ARM64 variant bypasses ASLR with leaked pointers, with no PAC and no stack canaries present ^[11]; the Android variant uses heap spraying and vtable corruption ^[12]. A proof-of-concept has been publicly demonstrated by the discovering researchers, and at the time of the writeup no exploitation in the wild had been reported ^[13].

Zoom has deployed server-side filtering that blocks malicious annotation messages, but only for non-E2EE meetings ^[14]. Organisations running end-to-end encrypted meetings face elevated risk precisely because the server cannot inspect that traffic to filter it ^[15]. The conversations you deliberately hardened are the ones with no compensating control.

Fixed versions: Workplace clients on Windows, macOS, iOS and Android before 7.1.5 and 7.0.6 are affected ^[16]; the VDI Client for Windows before 7.0.11 and 6.6.16 ^[17]; Zoom Rooms on all platforms before 7.1.5 ^[18]; and the Zoom Meeting SDK on all platforms before 7.1.5 ^[19]. Upgrade paths are 7.1.5 or the 7.0.6 extended support track for clients, 7.0.11 or 6.6.16 for VDI, and 7.1.5 for Rooms and the SDK ^[20]. Interim advice from Orca is to enforce minimum client versions in meeting preferences, turn on waiting rooms and passcodes, and consider disabling annotations, file transfer, whiteboarding and remote control until endpoints are patched ^[21]. Successful exploitation is described as allowing camera and microphone activation for surveillance, data theft, persistent malware and lateral movement ^[22]. Note that the writeup is also a vendor pitch for Orca's own vulnerable-asset discovery ^[23].

Watch the Meeting SDK line item ^[19]. Conference room hardware and third-party apps that embed Zoom do not patch on your schedule, and Rooms devices are on the same 7.1.5 floor ^[18]. Watch also for the first credible report of in-the-wild use, which would retire the current "PoC only" framing ^[13].