CVE-2026-53413: Zoom "Zoomsday" Zero-Click RCE via Annotation Feature — Detection and Remediation Guide

Zoom has patched four vulnerabilities in its collaboration client — and one of them is the kind of bug that keeps incident responders up at night. Tracked as CVE-2026-53413 and already nicknamed "Zoomsday," the flaw is a zero-click, unauthenticated remote code execution vulnerability in Zoom's annotation feature. A meeting participant can trigger memory corruption on another attendee's machine simply by abusing the shared annotation channel — the victim doesn't need to click a link, open a file, or accept a prompt. The malicious input arrives as part of ordinary meeting traffic.

The flaw was discovered by a researcher known as A Security and disclosed to Zoom, which has now shipped fixes for it alongside three additional vulnerabilities. For defenders, the calculus is straightforward: Zoom sits on virtually every corporate endpoint, meetings routinely include external participants, and the attack surface here is exposed by default in most tenants. Any environment where users join meetings with untrusted or unvetted participants — which is to say, nearly all of them — should treat this as a priority patch.

This post breaks down what we know about the vulnerability, what post-exploitation behavior looks like, how to hunt for it, and exactly what to do about it.

Technical Analysis

What Was Patched

Zoom's security update addresses four vulnerabilities, headlined by:

How the Vulnerability Works

CVE-2026-53413 is a memory corruption vulnerability in the client-side handling of annotation data. The annotation feature — the shared whiteboard/screen-markup capability that lets meeting participants draw, highlight, and type over shared content — requires every connected client to parse and render annotation objects streamed from other participants in near real time.

From a defender's perspective, the critical characteristics are:

• Zero-click delivery: The exploit rides the normal meeting data channel. The victim's client parses attacker-controlled annotation input automatically. There is no user interaction requirement beyond the victim being in the same meeting as the attacker.
• Unauthenticated relative to the victim: The attacker needs only to be a meeting participant. In practice, that means any meeting with open or weakly controlled admission — public links, forwarded invitations, compromised attendee accounts, or "zoombombing"-style walk-ins — is a viable delivery vehicle.
• Client-side code execution: Exploitation lands inside the Zoom client process context, running with the victim user's privileges. Memory corruption in a media/rendering component typically means a crash-prone exploit path, but a working exploit achieves arbitrary code execution on the endpoint.

The realistic attack chain looks like this:

1. Attacker joins a target meeting as a participant (open meeting, phished invite, or compromised participant account).
2. Attacker's client sends crafted annotation data into the shared meeting stream.
3. The victim's Zoom client parses the malformed annotation object, corrupting memory and redirecting execution.
4. Code executes in the context of the victim's Zoom process — typically followed by a staged payload: spawning a scripting interpreter, dropping a second-stage binary, or establishing outbound C2.

Affected Products and Exploitation Status

The vulnerability affects the Zoom Workplace desktop clients that implement the annotation rendering feature across supported platforms (Windows and macOS, with other client variants covered in the vendor bulletin). Consult the official Zoom security bulletin at https://www.zoom.com/en/trust/security/ for the exact affected and fixed version numbers per platform, and confirm your fleet against those numbers rather than assuming.

As of this writing, there is no confirmed public in-the-wild exploitation reported, and the flaw was disclosed through coordinated channels. Do not let that breed complacency: zero-click collaboration-platform bugs (the Zoom/Pegasus-era lessons from 2019–2021 come to mind, and more recent messaging-platform zero-clicks) historically move from disclosure to weaponization quickly, especially when the delivery mechanism — a meeting anyone can join — is this frictionless.

Detection & Response

Because exploitation occurs inside the Zoom client process, endpoint telemetry is your ground truth. The most reliable post-exploitation signal is the Zoom client spawning processes it never legitimately spawns. Zoom's renderer/updater spawning cmd.exe, PowerShell, rundll32.exe, mshta.exe, or an Office-style LOLBin chain is a high-fidelity indicator that the client process was hijacked.

A secondary signal is client instability: memory-corruption exploits — even failed attempts — frequently crash the target process. A burst of Zoom crashes correlated with meeting activity involving external participants warrants triage.

Sigma Rules

---
title: Zoom Client Process Spawning Suspicious Child Process
id: 3c9e7b41-2f6a-4d18-9e55-8a1c4f72b9d0
status: experimental
description: Detects the Zoom desktop client spawning command interpreters, script engines, or LOLBins — consistent with post-exploitation behavior following client-side RCE such as CVE-2026-53413 (zero-click annotation memory corruption).
references:
  - https://securityaffairs.com/197042/hacking/zoom-patches-zoomsday-zero-click-flaw-enabling-remote-code-execution.html
  - https://attack.mitre.org/techniques/T1203/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1203
logsource:
  category: process_creation
  product: windows
detection:
  selection_parent:
    ParentImage|endswith:
      - '\Zoom.exe'
      - '\ZoomMeetingsModuleHost.exe'
      - '\CptHost.exe'
  selection_child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\pwsh.exe'
      - '\wscript.exe'
      - '\cscript.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\regsvr32.exe'
      - '\certutil.exe'
      - '\bitsadmin.exe'
      - '\wmic.exe'
  condition: selection_parent and selection_child
falsepositives:
  - Rare — Zoom does not legitimately spawn these binaries in normal meeting operation; investigate every hit
level: critical
---
title: Zoom Client Crash Followed by Unexpected Process Execution
id: 8f2d5a69-1c4b-4e77-b3a1-6d9e0f85c2a7
status: experimental
description: Detects Windows Error Reporting activity for the Zoom client, which may indicate failed or successful memory corruption exploitation attempts against CVE-2026-53413. Correlate with process telemetry for the Zoom process tree.
references:
  - https://securityaffairs.com/197042/hacking/zoom-patches-zoomsday-zero-click-flaw-enabling-remote-code-execution.html
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.exploitation_for_client_execution
  - attack.t1203
logsource:
  category: process_creation
  product: windows
detection:
  selection:
    Image|endswith: '\WerFault.exe'
    CommandLine|contains:
      - 'Zoom.exe'
  condition: selection
falsepositives:
  - Legitimate Zoom application instability — tune by correlating with meeting activity involving external participants
level: medium

KQL — Microsoft Sentinel / Defender

This hunt looks for the Zoom client spawning child processes associated with post-exploitation staging, and enriches with network activity from the Zoom process tree.

// Hunt: Zoom client spawning suspicious child processes (post-RCE staging, CVE-2026-53413)
let suspiciousChildren = dynamic(["cmd.exe", "powershell.exe", "pwsh.exe", "wscript.exe", "cscript.exe", "mshta.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe", "bitsadmin.exe", "wmic.exe"]);
DeviceProcessEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ ("Zoom.exe", "ZoomMeetingsModuleHost.exe", "CptHost.exe")
| where FileName in~ (suspiciousChildren)
| project TimeGenerated, DeviceName, AccountName,
          ParentProcess = InitiatingProcessFileName,
          ParentCommandLine = InitiatingProcessCommandLine,
          ChildProcess = FileName, ProcessCommandLine, SHA256, FolderPath
| order by TimeGenerated desc;

// Correlate: unexpected outbound connections from Zoom child processes
DeviceNetworkEvents
| where TimeGenerated > ago(7d)
| where InitiatingProcessFileName in~ (suspiciousChildren)
| where InitiatingProcessParentFileName in~ ("Zoom.exe", "ZoomMeetingsModuleHost.exe", "CptHost.exe")
| where RemoteIPType == "Public"
| summarize Connections = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
    by DeviceName, InitiatingProcessFileName, RemoteUrl, RemoteIP, RemotePort
| order by FirstSeen desc;

Velociraptor VQL

Use this artifact during triage to enumerate the live process tree and flag any Zoom parent process with anomalous children across the fleet.

-- Hunt for Zoom client processes with suspicious child processes (post-exploitation staging)
LET zoom_procs = SELECT Pid, Name, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)zoom|cphost'

SELECT Pid, Name, CommandLine, Exe, Username, CreateTime,
       get(member='Ppid') AS Ppid
FROM pslist()
WHERE Ppid IN (SELECT Pid FROM zoom_procs)
  AND Name =~ '(?i)cmd|powershell|pwsh|wscript|cscript|mshta|rundll32|regsvr32|certutil|bitsadmin|wmic'

Remediation

1. Patch the Zoom Client Fleet — Immediately

• Deploy the current patched Zoom Workplace client build per the official Zoom security bulletin (https://www.zoom.com/en/trust/security/). Verify the exact fixed version numbers there for each platform in your estate — do not assume auto-update has covered your fleet.
• For managed Windows deployments, push the updated MSI via your standard software distribution (Intune, SCCM/MECM, GPO) and enforce a minimum client version. Zoom admin policy supports minimum-version enforcement — use it to forcibly retire vulnerable builds.
• macOS fleets: push the current DMG via your MDM and verify receipt; do not rely on user-initiated updates.

2. Verify and Enforce with Scripting

# Audit Zoom client versions across the fleet and flag vulnerable installs
# Run via Intune/SCCM/PSRemoting; export results for central review

$results = foreach ($path in @('HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
                              'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*',
                              'HKCU:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*')) {
    Get-ItemProperty $path -ErrorAction SilentlyContinue |
        Where-Object { $_.DisplayName -match 'Zoom' } |
        Select-Object @{N='Host';E={$env:COMPUTERNAME}}, DisplayName, DisplayVersion, InstallDate
}

# Compare DisplayVersion against the fixed version in the Zoom security bulletin
# Flag anything below the patched build for immediate remediation
$results | Export-Csv -Path ".\zoom_version_audit_$(Get-Date -Format 'yyyyMMdd').csv" -NoTypeInformation
$results | Format-Table -AutoSize

3. Compensating Controls While Patching

• Disable the annotation feature tenant-wide until clients are patched. In the Zoom Admin portal: Account Management → Account Settings → Meeting → In Meeting (Basic) → Annotation — set to Off and lock the setting. This removes the vulnerable code path from active meeting sessions.
• Tighten meeting admission: require authentication for meeting join, enable waiting rooms, restrict screen sharing and annotation to hosts/co-hosts by default, and disable "join before host." These controls shrink the population that can reach the exploit delivery channel.
• Segment and monitor: ensure Zoom endpoints are covered by EDR with process-tree telemetry enabled — the detections above are useless without process lineage collection.

4. Threat-Hunt for Pre-Patch Exposure

• Run the KQL and VQL hunts above against the last 7–30 days of telemetry, with particular attention to endpoints that joined meetings with external participants.
• Review Zoom crash/WER events clustered around specific meeting windows — a crash loop on one attendee's client during a meeting with an unknown participant is worth an IR look.
• If you find Zoom-spawned interpreter processes, treat the endpoint as compromised: isolate, acquire memory, and pivot on the child process command lines and any resulting network connections.

5. Strategic Hardening

• Add Zoom client version compliance to your vulnerability management SLAs — collaboration clients are first-class attack surface, not productivity afterthoughts.
• Review your Zoom tenant configuration against CIS-style benchmarks: external participant controls, recording/annotation defaults, and admin-set minimum versions should all be hardened posture, not per-meeting user choice.

The Zoomsday disclosure is a reminder that zero-click bugs don't only live in mobile messaging stacks — they're sitting in the tools your entire workforce uses to talk to strangers every day. Patch fast, disable annotation if you can't, and make sure your process-lineage telemetry would actually catch the follow-on stage.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub