CVE-2026-73570: Zimbra Zero-Click Email Vulnerability Exploited Before Disclosure — Detection and Remediation Guide

Zimbra has disclosed a serious vulnerability — CVE-2026-73570 — affecting Zimbra Collaboration, and the timeline should concern every defender running this platform: the flaw was exploited in the wild before public disclosure. Under certain conditions, the vulnerability can be triggered simply by delivering a specially crafted email to a victim's mailbox — no clicks, no opens, no user interaction required.

Zero-click exploitation against a collaboration platform is about as bad as it gets for defenders. Zimbra sits at the center of organizational communications, frequently exposed directly to the internet, and historically a favorite target of both criminal groups and nation-state operators seeking mailbox access, credential theft, and a persistence foothold inside the network. If your organization runs Zimbra — particularly any internet-facing instance — you should treat this as an active incident-response scenario, not a routine patch cycle. Assume compromise until you can demonstrate otherwise.

Technical Analysis

What We Know

• CVE: CVE-2026-73570
• Affected product: Zimbra Collaboration (self-hosted email and collaboration suite)
• Attack vector: Specially crafted email messages
• User interaction required: None — exploitation occurs under certain conditions without the recipient taking any action
• Exploitation status: Confirmed in-the-wild exploitation prior to public disclosure — this is the defining characteristic of the incident. Attackers had working exploitation capability while defenders had no public advisory, no CVE, and no patch guidance.

Why the Pre-Disclosure Exploitation Matters

The sequence of events here is critical for scoping your response. Because exploitation occurred before the vulnerability was publicly disclosed, there is an unknown dwell-time window during which attackers could have compromised Zimbra servers with zero chance of signature-based detection catching the initial vector. That means:

1. Patching alone is insufficient. Applying the vendor fix stops future exploitation but does nothing about access already established — webshells, injected mail filters, credential theft, or persistence mechanisms planted during the pre-disclosure window.
2. Retrospective log review is mandatory. Zimbra's mailbox.log, audit.log, and access_log (nginx proxy) are your ground truth for establishing whether crafted messages were delivered and whether post-exploitation activity followed.
3. The mailbox content itself is the weapon. Because the trigger is a specially crafted email processed by Zimbra's rendering/parsing pipeline, the malicious message may still be sitting in user mailboxes. On unpatched servers, it remains a live detonation risk; on patched servers, it is forensic evidence.

Attack Chain (Defender's View)

While full technical details remain limited at disclosure time, the observable chain for this class of zero-click Zimbra exploitation follows a well-established pattern we have responded to repeatedly:

1. Delivery: Attacker sends a crafted email to a target mailbox. No link click or attachment open is needed — server-side or client-side rendering of the message content triggers the flaw.
2. Execution in Zimbra context: Exploitation runs code or injects content within the Zimbra web application context — the zmmailboxd Java process and/or the victim's authenticated webmail session.
3. Post-exploitation: Typical follow-on activity in Zimbra compromises includes webshell deployment under Jetty webapp directories (/opt/zimbra/jetty_base/webapps/), creation of malicious mail forwarding/filter rules for data exfiltration, credential harvesting via injected login forms, and lateral movement using harvested credentials.

The practical defensive takeaway: hunt for both the delivery artifact (the crafted email) and the post-exploitation footprint (webshells, rogue filters, anomalous child processes of the Zimbra service, unusual outbound connections from the Zimbra host).

Detection & Response

The detections below target the highest-fidelity observables for this threat class: anomalous process execution under the Zimbra service account, webshell artifacts in Jetty webapp paths, and suspicious request patterns against Zimbra web endpoints. They are tuned to avoid the noise floor of normal Zimbra operations.

Sigma Rules

---
title: Zimbra Mailboxd Process Spawning Shell or Script Interpreter
id: 9c2e7a41-3d6f-4b18-a5c9-7e1f2d8b4a06
status: experimental
description: Detects the Zimbra mailboxd Java process or zimbra user spawning shells, script interpreters, or download tools - a strong post-exploitation indicator for zero-click exploitation such as CVE-2026-73570.
references:
  - https://www.securityweek.com/zimbra-vulnerability-exploited-in-the-wild-prior-to-public-disclosure/
  - https://attack.mitre.org/techniques/T1059/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.execution
  - attack.t1059
  - attack.initial_access
  - attack.t1190
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/opt/zimbra/'
    ParentCommandLine|contains:
      - 'zmmailboxd'
      - 'jetty'
  selection_user:
    User: 'zimbra'
  selection_image:
    Image|endswith:
      - '/bash'
      - '/sh'
      - '/dash'
      - '/python'
      - '/python3'
      - '/perl'
      - '/curl'
      - '/wget'
      - '/nc'
      - '/ncat'
  condition: selection_image and (selection_parent or selection_user)
falsepositives:
  - Zimbra administrative scripts run manually under the zimbra user (zmcontrol, zmprov) - filter by known admin tooling paths
level: high
---
title: Webshell Artifact Written to Zimbra Jetty Webapp Directory
id: 4b8f1d62-7a3e-4c59-b2d8-6f0a9c3e5b17
status: experimental
description: Detects creation or modification of JSP or script files inside Zimbra Jetty webapp directories, a common persistence mechanism following Zimbra exploitation in the wild.
references:
  - https://www.securityweek.com/zimbra-vulnerability-exploited-in-the-wild-prior-to-public-disclosure/
  - https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/opt/zimbra/jetty_base/webapps/'
      - '/opt/zimbra/jetty/webapps/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.sh'
      - '.php'
  condition: selection_path and selection_ext
falsepositives:
  - Legitimate Zimbra patch or upgrade operations - correlate with change windows before escalating
level: critical
---
title: Suspicious Crafted Content in Zimbra Webmail Requests
id: 61a3c9d4-8f2b-4e76-a1c5-9d4b7e2f8c35
status: experimental
description: Detects HTTP requests to Zimbra endpoints containing inline script or event-handler patterns consistent with crafted-email exploitation attempts such as CVE-2026-73570.
references:
  - https://www.securityweek.com/zimbra-vulnerability-exploited-in-the-wild-prior-to-public-disclosure/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: proxy
detection:
  selection_host:
    cs-host|contains:
      - 'zimbra'
      - 'mail.'
  selection_uri:
    cs-uri-query|contains:
      - '<script'
      - 'onerror='
      - 'onload='
      - 'javascript:'
      - '%3Cscript'
      - '%3cscript'
  condition: selection_host and selection_uri
falsepositives:
  - Rare - encoded HTML in legitimate query parameters; tune cs-host to your Zimbra hostnames
level: high

KQL — Microsoft Sentinel / Defender

This query hunts Zimbra proxy/mailbox logs ingested via Syslog or CEF for request patterns consistent with crafted-email delivery and post-exploitation probing. It also surfaces anomalous process execution on Zimbra hosts for organizations collecting Linux audit data into LinuxAuditLog/Syslog.

// Hunt 1: Crafted-content indicators in requests to Zimbra endpoints
let zimbraHosts = dynamic(["mail.", "zimbra", "webmail."]);
union isfuzzy=true
    (CommonSecurityLog
    | where TimeGenerated > ago(14d)
    | where DestinationHostName has_any (zimbraHosts) or RequestURL has_any (zimbraHosts)
    | where RequestURL has_any ("<script", "%3Cscript", "%3cscript", "onerror=", "onload=", "javascript:")
    | project TimeGenerated, SourceIP, DestinationHostName, RequestURL, RequestMethod, SourceUserID),
    (Syslog
    | where TimeGenerated > ago(14d)
    | where Computer has_any (zimbraHosts)
    | where SyslogMessage has_any ("<script", "%3Cscript", "onerror=", "javascript:")
      and SyslogMessage has_any ("/service/", "/zimbra", "/h/")
    | project TimeGenerated, Computer, ProcessName, SyslogMessage)
| sort by TimeGenerated desc;

// Hunt 2: Shell or interpreter execution under the zimbra service account (post-exploitation)
Syslog
| where TimeGenerated > ago(14d)
| where SyslogMessage has_any ("zimbra") and SyslogMessage has_any ("/bin/bash", "/bin/sh", "python", "perl", "curl ", "wget ", "nc ", "ncat")
| where SyslogMessage has_any ("COMMAND=", "execve", "audit")
| project TimeGenerated, Computer, ProcessName, SyslogMessage
| sort by TimeGenerated desc;

Velociraptor VQL

Use this hunt across your Zimbra hosts to enumerate recently modified executable content in Jetty webapp directories (webshell sweep) alongside suspicious processes running as the zimbra user.

-- Zimbra compromise triage: webshell sweep + anomalous zimbra-user processes
-- Artifact 1: Recently created/modified script files in Jetty webapp paths
SELECT FullPath, Mtime, Ctime, Size
FROM glob(globs=[
  '/opt/zimbra/jetty_base/webapps/**/*.jsp',
  '/opt/zimbra/jetty_base/webapps/**/*.sh',
  '/opt/zimbra/jetty/webapps/**/*.jsp'
])
WHERE Mtime > now() - 86400*30
ORDER BY Mtime DESC

-- Artifact 2: Suspicious processes running as zimbra user
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Username =~ 'zimbra'
  AND CommandLine =~ 'bash|/bin/sh|python|perl|curl |wget |nc |ncat'

Bash — Verify, Patch, and Triage

Run the following on each Zimbra host. It confirms your version, applies available vendor updates, and performs a first-pass compromise assessment. Review vendor guidance for the exact fixed build for your release train before upgrading.

#!/bin/bash
# CVE-2026-73570 - Zimbra verify/patch/triage script
# Run as root on the Zimbra host. Review output carefully before remediation actions.

echo "=== [1] Current Zimbra version ==="
su - zimbra -c 'zmcontrol -v'

echo "=== [2] Check for and apply OS/Zimbra package updates ==="
if command -v apt-get >/dev/null 2>&1; then
  apt-get update && apt-get upgrade zimbra-* -y
elif command -v yum >/dev/null 2>&1; then
  yum check-update
  yum update 'zimbra-*' -y
fi
# NOTE: For CVE-specific fixes, follow the official Zimbra security advisory at
# https://wiki.zimbra.com/wiki/Security_Center and https://www.zimbra.com/product/security/

echo "=== [3] Webshell sweep - recently modified files in Jetty webapp dirs ==="
find /opt/zimbra/jetty_base/webapps /opt/zimbra/jetty/webapps \
  -type f \( -name '*.jsp' -o -name '*.jspx' -o -name '*.sh' \) \
  -mtime -30 -printf '%T@ %p\n' 2>/dev/null | sort -rn | head -50

echo "=== [4] Suspicious processes under zimbra user ==="
ps -u zimbra -o pid,ppid,user,etime,cmd | grep -Ei 'bash|/bin/sh|python|perl|curl|wget|nc |ncat' || echo "None found"

echo "=== [5] Rogue mail forwarding/filter rules (run per-mailbox review) ==="
su - zimbra -c 'zmprov gaa' | while read acct; do
  rules=$(su - zimbra -c "zmprov ga $acct zimbraMailSieveScript zimbraPrefMailForwardingAddress" 2>/dev/null)
  echo "$rules" | grep -Ei 'redirect|forward' >/dev/null 2>&1 && { echo "--- $acct"; echo "$rules"; }
done

echo "=== [6] Recent anomalous access patterns in nginx proxy logs ==="
grep -Ei 'script|onerror|onload|javascript:' /opt/zimbra/log/nginx.access.log 2>/dev/null | tail -50

echo "=== [7] Outbound connections from zimbra processes ==="
ss -tnp | grep -Ei 'zimbra|java' | grep -v ':25 \|:443 \|:80 ' || echo "None found"

Remediation

Given confirmed pre-disclosure exploitation, treat this as a patch-and-hunt operation, in that order but without pause between them:

1. Patch immediately. Apply the vendor fix per the official Zimbra Security Center advisory (wiki.zimbra.com/wiki/Security_Center) and the SecurityWeek report referencing CVE-2026-73570. Confirm the fixed build number for your specific release train (Zimbra patches are release-specific — verify with zmcontrol -v after upgrading). If you are on an end-of-support Zimbra version that will not receive the fix, migration off that version is the remediation.
2. Restrict exposure while patching. If you cannot patch within hours, place Zimbra behind a VPN or IP allowlist at the perimeter and disable external access to webmail endpoints. This is a temporary risk reduction only — the delivery vector is email, which likely still flows.
3. Hunt retroactively. Because exploitation preceded disclosure, review at minimum the last 30 days of mailbox.log, audit.log, and nginx.access.log for the indicators above. Look for the crafted-email delivery, then pivot on any host that shows post-exploitation signals.
4. Sweep for persistence. Audit Jetty webapp directories for webshells, review every mailbox for unauthorized forwarding rules and Sieve scripts (attackers routinely hide exfiltration in mail filters), and review Zimbra admin accounts and delegated admin grants.
5. Rotate credentials. For any host showing compromise indicators: reset all mailbox passwords, revoke active sessions (zmprov session invalidation), rotate admin credentials, and re-issue any credentials that traversed the Zimbra host.
6. Rebuild if confirmed. A Zimbra host with confirmed webshell deployment or service-account command execution should be rebuilt from known-good media and restored from pre-compromise backups, not cleaned in place.
7. Monitor CISA KEV. Given in-the-wild exploitation, track the CISA Known Exploited Vulnerabilities catalog for CVE-2026-73570 — a KEV listing will carry a binding remediation deadline for federal agencies and serves as a strong forcing function for everyone else.

The uncomfortable lesson of this disclosure is one Zimbra defenders have learned before: internet-facing collaboration platforms are exploited faster than patch cycles, and email is the perfect zero-click delivery mechanism. If Zimbra is critical to your operations, it belongs on your highest-priority attack-surface monitoring and your fastest patch SLA — full stop.

Related Resources

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