Three memory-corruption vulnerabilities in Zoom's annotation engine — the feature that lets meeting participants draw and annotate over a shared screen — could have allowed any attacker inside an active call to silently execute arbitrary code on every other participant's device, with no click and no warning. The Israeli offensive-security firm A Security, which first disclosed the flaws under the banner "Zoomsday," confirmed working exploits on Windows, macOS, iOS, and Android. Zoom shipped client-side patches in June and July 2026, roughly eight weeks before the technical details became public on 11 August.
How the annotation protocol became an attack surface
Zoom's annotation feature operates over a proprietary, undocumented binary protocol. When a participant draws on a shared screen, the client does not transmit pixels — it serialises a typed in-memory object describing the shape, text, or stroke, wraps it in a Protocol Data Unit (PDU), and delivers it through Zoom's Multimedia Router (MMR) infrastructure. Every recipient's client then deserialises those bytes back into a live object graph.
A Security's researchers began by statically ranking the 121 native shared libraries in the Android client. An automated analysis of JNI entry points and dangerous sinks (memcpy, strcpy, computed-size allocators) produced a queue of 3,762 functions across 70 libraries. The annotation library libannotate.so ranked 45th — off the top of the list entirely. It surfaced only when the team switched to dynamic tracing: attaching to a live call via Frida and exercising each meeting feature to watch which libraries fired. Drawing an annotation lit up libannotate.so and its serialise/deserialise pair. The same source code compiles into every Zoom platform client, meaning a single bug has cross-platform reach by design.
Three CVEs, one shared root cause
The core problem is that the deserialiser trusts attacker-supplied counts from the wire to decide how much memory to read or write into fixed-size local buffers.
CVE-2026-53413 (CVSS 8.3, ZSB-26015) — stack buffer over-write. Text annotations are built in layers: a CAnnoTextFrame holds a list of CAnnoTextRange items, each carrying a CAnnoFormatBlock with four fixed 128-byte UTF-16 string buffers (font names, styles). The parser reads a 32-bit character count from the wire for each buffer and copies 2 × count bytes into it. No comparison against the 128-byte destination exists. The fourth buffer is the final field of its parent, a 704-byte stack-allocated object inside the text frame's deserialiser. An oversized count therefore runs off the end of that object, through saved registers, and over the return address. Both the count and the copied bytes are fully attacker-controlled, giving a clean, remotely triggered stack overflow.
CVE-2026-53414 (CVSS 6.5, ZSB-26016) — heap buffer over-read. A separate code path allocates a glyph buffer using a wire-supplied character count (2 × count + 2 bytes) but fills it only with the bytes actually present in the packet. When the wire count exceeds the packet body, the tail of the allocation is never initialised — the allocator's raw, untouched heap memory. A terminating null is written only at the far end. Captured slabs from a live target contained live code pointers and vtable references from loaded libraries: exactly the material needed to defeat ASLR.
CVE-2026-53415 (CVSS 8.3, ZSB-26017) — use-after-free / write-what-where. The parser handling message type 75 — an auto-shape metadata object (CAnnoObjAutoMetaShape) — reads attacker-supplied bytes directly into an internal linked-list structure and then unlinks that list without validating the pointers. The result is a write-what-where primitive. Zoom had already deployed a server-side filter for this message type before the report arrived and credited the finding to its own Offensive Security team. That filter, however, cannot apply to end-to-end encrypted (E2EE) meetings, where the server is intentionally blind to call content. Client-side remediation arrived in version 7.1.5.
◆ Key Takeaway
All three flaws trace back to a single architectural decision: the annotation deserialiser trusts wire-supplied length and count fields without bounding them against the fixed destination buffers. In a protocol where the sender controls every byte of the PDU, that trust is unconditional. Patching individual buffers addresses the symptoms; auditing every count-prefixed read in the deserialise stack is the durable fix.
How exploitation works in practice — and what "zero-click" really means
The exploit path starts with a design gap, not a code bug. Zoom's MMR routes annotation PDUs through per-participant channels: the sharer holds a downstream channel to every viewer, and each viewer holds an upstream channel back to the sharer. Acknowledgement messages (AddObjAck, opcode 0x10002) share the same dispatch path as full object messages (AddObj, opcode 0x10001). The factory function CAnnoPduFactory::create reads the opcode off the wire and routes to the matching deserialiser with no check on which seat the sender occupies. Placing an AddObj body on the acknowledgement channel causes the recipient to fully deserialise the object — including any malformed length fields.
From the sharer seat, that channel reaches every participant simultaneously. From a viewer seat, it reaches only the sharer. The annotation feature is always-on; the victim does not need to have opened the annotation toolbar.
On macOS, the annoter bundle ships as plain arm64 with no pointer-authentication codes (PAC) and no stack canary. The CVE-2026-53413 overflow runs clean into the epilogue, which restores callee-saved registers from the stack before returning. Overwriting that stack region plants attacker-controlled values in X19–X28, X29, and X30 (the link register). A single gadget in the macOS shared library cache — MOV X0, X19; MOV X1, X21; BL execvp — completes the chain. In the published proof-of-concept, this launched Safari on a real target's Mac during a live call.
On Android, where the stack path is not available, the researchers used the heap-resident extension-child variant of the same overflow. Spraying 592-byte size-class objects places a controlled neighbour adjacent to the overflow source. Partially overwriting the neighbour's vtable pointer — only the low bytes, which are module-relative and ASLR-invariant — retargets the next virtual call dispatched through that pointer to an attacker-chosen offset inside the module. No address leak is required.
Patch status, affected versions, and the scoring dispute
Client-side fixes are available and Zoom recommends immediate update. The versions that close all three CVEs:
- Zoom Workplace (all supported platforms): version 7.1.5 or 7.0.6 in their respective branches
- Zoom Workplace VDI Client for Windows: versions 7.0.11 and 6.6.16
- Zoom Rooms and Zoom Meeting SDK (all platforms): version 7.1.0 (7.1.5 for CVE-2026-53415)
- E2EE meetings require client-side patches for full coverage — server-side filters cannot inspect encrypted payloads
- No exploitation in the wild has been reported; none of the three identifiers appear in CISA's Known Exploited Vulnerabilities catalogue
- A Security reported the first two CVEs on 10 June 2026; Zoom acknowledged within one day and shipped fixes before public disclosure on 11 August
- CVSS disagreement: A Security scores all three at 9.0 under CVSS 4.0; Zoom's own bulletins score them at 8.3, 6.5, and 8.3 under CVSS 3.1, with user interaction marked as required
The scoring gap matters to Swiss and European practitioners. FINMA circular 2023/1 and the ISA both require that vulnerability remediation timelines be risk-calibrated. A CVSS 6.5 rating from the vendor versus 9.0 from the discovering firm for what the researchers describe as a zero-click ASLR bypass creates genuine ambiguity in a risk-based patching process. Where vendor and researcher scores diverge significantly, organisations should use the higher figure for prioritisation unless their own internal analysis establishes otherwise.
The episode also adds weight to an ongoing debate about AI-assisted offensive research. A Security reports that the entire path from discovery to working exploit — on closed-source enterprise software with no published protocol specification — was completed in under 24 hours using fewer than 20 prompts on publicly available AI models. The AI-assisted static ranker missed the vulnerable library on the first pass, ranking it 45th; the breakthrough came from dynamic tracing guided by human judgment, with AI accelerating the reverse-engineering once the target was identified. The claim is unverifiable externally — no model is named in the writeup — but the timeline itself is the point: an effort that would historically have required weeks now fits within a working day.
Enterprise security teams running Zoom at scale should verify that endpoint management tooling has applied the June and July client updates across all platforms, with particular attention to VDI deployments and mobile fleets where patch distribution is less uniform. Organisations that have enabled E2EE meetings should treat the server-side filter for CVE-2026-53415 as insufficient and confirm the client version directly. As AI-assisted exploitation compresses the time between disclosure and weaponisation, the window for deliberate patching is narrowing — and for vulnerabilities in ubiquitous collaboration infrastructure used by regulated financial institutions and healthcare providers, that compression carries direct implications for incident reporting obligations under DORA and the revised Swiss ISA.