CVE-2026-53413 ‘ZOOMSDAY’: Any Zoom Meeting Participant Can Zero-Click Seize Every Device — AI Built the Working Exploit in 24 Hours

How many Zoom calls did you join today? Now consider this: on any one of those calls, a single malicious participant — a vendor, a contractor, an uninvited guest who slipped past a waiting room — could have silently seized control of every device in that meeting. No link to click. No file to open. No warning of any kind. That is the precise threat that ZOOMSDAY, a chain of three zero-click memory-corruption flaws in Zoom’s annotation engine, placed in front of hundreds of millions of users worldwide — and that was publicly disclosed on August 11, 2026.

What Is ZOOMSDAY?

ZOOMSDAY is the collective name given by researchers at A Security to a trio of memory-corruption vulnerabilities discovered in Zoom’s proprietary annotation layer — the feature that lets participants draw, highlight, and annotate content during screen-sharing sessions. Rather than a flaw in Zoom’s server infrastructure or its web client, these bugs live inside libannotate.so, a shared library loaded into the native Zoom Workplace client on every supported platform.

What makes ZOOMSDAY structurally different from most conferencing vulnerabilities is its zero-click nature. Traditional exploits demand that the victim execute something: open an attachment, visit a URL, approve an administrative prompt. ZOOMSDAY demands nothing of the victim. From the moment annotation data starts flowing — which happens automatically whenever any participant enables the feature — a malicious sender can deliver crafted packets that corrupt the receiver’s memory and eventually hijack their process.

The three constituent CVEs were publicly disclosed by Zoom on August 11, 2026, through security bulletins ZSB-26015 to ZSB-26018, after A Security completed coordinated disclosure.

Technical Breakdown: How Three Flaws Chain Into Total Meeting Compromise

Understanding the exploit chain requires a brief look at how Zoom processes annotation packets during a meeting.

When a participant uses the annotation toolbar, Zoom serialises drawing commands — shapes, text blocks, highlight strokes — into proprietary binary packets and transmits them to every other client in the meeting over an encrypted channel. Each receiving client’s libannotate library deserialises these packets and renders them. The critical function in this pipeline is CAnnoFormatBlock::Deserialize.

CVE	CVSS	Vulnerability Class	Exploit Role
CVE-2026-53413	8.3 High	Stack Buffer Overflow	Primary RCE — overwrites stack and hijacks control flow
CVE-2026-53414	6.5 Medium	Heap Buffer Over-read	Memory leak — leaks ASLR-defeating heap addresses
CVE-2026-53415	8.3 High	Use-After-Free	Write-what-where primitive — delivers the payload precisely

The root cause of CVE-2026-53413 is almost embarrassingly simple: CAnnoFormatBlock::Deserialize accepts attacker-controlled 32-bit character counts from the network and copies data into fixed 128-byte stack buffers without ever checking whether the incoming data fits. An attacker sends a maliciously large character count, the copy operation overflows the buffer, and adjacent stack memory — including the saved return address — is overwritten with attacker data.

CVE-2026-53414 feeds the chain by leaking heap layout information, defeating Address Space Layout Randomisation (ASLR). Without a memory-leak primitive, the stack overflow would crash unpredictably; with one, an attacker can compute exact addresses and land shellcode reliably. CVE-2026-53415 completes the chain with a use-after-free condition in Zoom’s auto-shape metadata handling, providing a precise write-what-where capability that finishes the RCE.

The attack requires screen sharing or annotation to be active, which is standard practice in the vast majority of enterprise Zoom meetings. A Zoom Rooms endpoint in a conference room, a developer screen-sharing a code review, a finance team walking through a spreadsheet — every one of these is a potential target.

For a detailed technical write-up of the research, see the Orca Security research pod and the NVD entry for CVE-2026-53413.

The AI Accelerant: From Zero to Working Exploit in Under 24 Hours

Perhaps the most alarming dimension of ZOOMSDAY is not the vulnerability itself but how it was weaponised. A Security researcher Omer Gull stated that producing a comparable exploit chain five years ago “would have taken a team of five people maybe six months.” His team completed it in under 24 hours using fewer than 20 prompts on publicly available AI models.

The implications for every organisation’s vulnerability management programme are profound. When AI can compress a six-month exploitation timeline to one working day, the traditional assumption that “this CVE is complex to exploit, so we have time” no longer holds. The window between public CVE disclosure and working exploit availability is collapsing.

This is not an isolated incident. Earlier this year we saw the LiteLLM supply chain attack demonstrate how AI-infrastructure components are becoming both attack vectors and attack accelerants. The message is consistent: AI does not respect your patch cycles.

India’s Zoom Exposure — Why This Hits Closer to Home

India is among the world’s heaviest enterprise Zoom consumers. Post-pandemic hybrid working has entrenched Zoom across banking, insurance, IT services, manufacturing, and government institutions. The National Informatics Centre (NIC) and numerous state government bodies use Zoom for inter-departmental calls. Large IT services firms — running hundreds of concurrent client-facing meetings every hour — face the possibility that a single compromised endpoint in a meeting could silently exfiltrate credentials, session tokens, or intellectual property from every other participant.

India’s RBI-regulated financial institutions and SEBI-regulated capital markets firms face an additional compliance dimension: a successful exploitation of ZOOMSDAY could constitute a reportable data breach under DPDPA 2023 and RBI cyber-resilience guidelines if customer data is accessible on the compromised device.

Particularly at risk are organisations that have deployed Zoom Rooms appliances in conference rooms — these often run unattended, are rarely individually managed, and may be on older firmware tracks. The extended-support patch (7.0.6) exists precisely to cover them, but only if someone applies it.

What You Should Do Immediately

As a practitioner who has spent three decades hardening enterprise networks — from FortiGate perimeters to zero-trust micro-segmentation — my defensive recommendations are concrete and urgency-ranked:

1. Patch every Zoom client today. Update Zoom Workplace to version 7.1.5 or later (or 7.0.6 on the extended support track). Zoom Rooms and Meeting SDK must also be at 7.1.5. Zoom VDI Client needs to reach 7.0.11 or 6.6.16. This is non-negotiable — there is a verified working exploit chain.
2. Audit your auto-update status. Enterprise deployments pushed via MSI or MDM often have auto-update disabled for control reasons. Query your endpoint management platform (Intune, SCCM, Jamf) for clients below the patch threshold. Treat any unpatched endpoint as compromised until updated.
3. Enforce annotation controls. While patching is the real fix, as a temporary measure in zero-trust deployments, use Zoom Admin policies to restrict annotation to host-only or disable it entirely for high-sensitivity meetings. This reduces — but does not eliminate — the attack surface.
4. Isolate Zoom Rooms hardware. Conference-room appliances should sit on a segregated VLAN with no access to internal file servers, domain controllers, or privileged workstations. If a Rooms endpoint is compromised, network segmentation limits lateral movement. This is exactly the kind of zero-trust adjacency control I implement at client sites through FortiGate policy enforcement.
5. Enable Zoom’s end-to-end encryption (E2EE) for sensitive meetings. E2EE prevents Zoom servers from inspecting annotation packets, but importantly does not prevent a meeting participant from exploiting this flaw — the vulnerability is client-side. E2EE is still good hygiene but is not a mitigating control for ZOOMSDAY.
6. Accelerate your AI-exposure review. Given that this exploit was developed with public AI tools in <24 hours, revisit the assumption that “complex” CVEs give you weeks of runway. Patch high-severity vulnerabilities in conferencing, productivity, and collaboration software within 48–72 hours of disclosure going forward.

This incident follows a pattern of serious vulnerabilities hitting ubiquitous collaboration software. You may recall our earlier coverage of CVE-2026-62815 — the Microsoft QUIC use-after-free that opened every Windows Server to RCE. Similar memory-safety failures, similar urgency. The threat to enterprise communication infrastructure is systemic.

The Bigger Picture: When AI Writes Exploits Faster Than Humans Patch

ZOOMSDAY crystallises a new threat paradigm. The traditional vulnerability lifecycle looked like this: CVE disclosed → researchers study it (weeks) → PoC developed (months) → exploit-in-the-wild (months to years). AI assistance has collapsed that model. Today the timeline can be: CVE disclosed → AI-assisted PoC (hours to days) → weaponised exploit (days to weeks).

Defenders are not powerless, but they must adapt. The answer is not to slow down AI-assisted research (that ship has sailed). The answer is to compress defensive response times to match. That means automated patch orchestration, continuous vulnerability scanning, and network segmentation that limits blast radius when — not if — an exploit lands.

It also means leaning into zero-trust architecture. A device that is already zero-trust-segmented limits what an attacker can do even after achieving RCE. The compromised Zoom client becomes a dead end rather than a pivot point into Active Directory, production databases, or SWIFT payment systems.

---

Frequently Asked Questions

Do I need to be sharing my screen for ZOOMSDAY to work against me?

Not necessarily. You need to be in a meeting where the annotation feature is active — which can happen when any participant shares their screen. You do not need to be the one sharing, and you do not need to enable annotation yourself. Joining a regular Zoom meeting with a malicious participant is sufficient if annotation is in use.

Does Zoom’s end-to-end encryption protect against this attack?

No. Zoom’s E2EE encrypts communication between participants, but the vulnerability is in the receiving client’s deserialization of annotation packets. A legitimate (but malicious) meeting participant’s packets are decrypted and processed locally. E2EE does not validate that those packets are structurally safe — that is where the missing bounds check fails.

Are Zoom Rooms and Zoom Phone affected?

Zoom Rooms is explicitly affected and must be patched to version 7.1.5. Zoom Phone, which does not use the annotation engine in the same way, was not listed in the bulletins (ZSB-26015 through ZSB-26018). Zoom VDI Client for Windows is also affected and requires its own update (7.0.11 or 6.6.16).

Is ZOOMSDAY being actively exploited in the wild?

As of August 11, 2026, no confirmed in-the-wild exploitation has been reported. However, A Security confirmed a working exploit chain exists, and with public AI models capable of compressing exploit development to under 24 hours, that status can change rapidly. Treat this as imminent exploitation likely rather than safe for now.

---