Critical Zimbra Collaboration Suite RCE Now Actively Exploited — Detection and Remediation Guide for Defenders

CERT Polska has issued an urgent warning that attackers have begun actively exploiting a critical remote code execution (RCE) vulnerability in Zimbra Collaboration Suite (ZCS) — the open-source email and collaboration platform used by thousands of organizations, government agencies, and service providers worldwide. This is not a theoretical risk: exploitation is confirmed in the wild, and Zimbra has a long, painful history of being one of the most aggressively targeted enterprise applications on the internet. When a critical ZCS flaw goes live, opportunistic scanners and organized intrusion sets are typically weaponizing it within hours — and that window has now closed for defenders who haven't acted.

If your organization runs an internet-facing Zimbra server, treat this as a probable-compromise scenario until proven otherwise. Zimbra boxes are high-value targets: they hold mailboxes, credentials, address books, and often sit on networks with broad internal reach. Unauthenticated or low-complexity RCE on a mail server is a beachhead, a data theft opportunity, and a persistence platform all in one.

This post breaks down what defenders need to know: the affected attack surface, how this class of Zimbra exploitation typically unfolds, concrete detection logic for your SOC, and a prioritized remediation path.

Technical Analysis

Affected Products and Exposure

The vulnerability affects Zimbra Collaboration Suite (ZCS) — both the open-source and Network Edition builds — in unpatched versions currently deployed in the wild. Zimbra deployments are predominantly Linux-based (Ubuntu, RHEL/CentOS), running a Jetty-based web application stack (/opt/zimbra/jetty/) behind nginx as a reverse proxy. The publicly exposed attack surface typically includes:

• 443/TCP — the Zimbra web client and Admin console (Admin console should be on 7071/TCP and must never be internet-exposed)
• 25/587/TCP — Postfix MTA (mail submission/relay)
• IMAP/POP3 (143/993, 110/995)

Zimbra's own telemetry and third-party scans consistently show tens of thousands of internet-facing ZCS instances, a significant fraction running versions well behind current. That is the pool attackers are now harvesting.

How the Attack Works — Defender's View

Based on the exploitation pattern CERT Polska described and the well-documented anatomy of prior Zimbra RCE campaigns, the attack chain defenders should model looks like this:

1. Reconnaissance and fingerprinting — attackers scan for Zimbra instances by probing the web client login page and characteristic URI paths, enumerating versions via response headers and known endpoints.
2. Triggering the RCE — a crafted HTTP request to a vulnerable ZCS component achieves code execution in the context of the zimbra service user. Because the vulnerable code path is reachable over the standard web ports, no authentication is required in the worst-case configuration.
3. Webshell deployment — the most consistent post-exploitation artifact in Zimbra compromises is a JSP webshell dropped into the Jetty webapps directory (commonly under /opt/zimbra/jetty_base/webapps/zimbra/ or /opt/zimbra/jetty/webapps/). Filenames are often randomized or masquerade as legitimate Zimbra components.
4. Credential theft and mailbox access — Zimbra stores credentials and mail stores locally. Attackers routinely dump LDAP credentials, harvest zimbra user secrets, and access mailbox content directly from disk.
5. Persistence and lateral movement — cron jobs, injected startup scripts, and additional shells provide durability; the mail server then becomes a pivot into the internal network.

Exploitation Status

• Confirmed active exploitation in the wild — per CERT Polska's warning, attacks are underway now.
• Assume public or semi-public exploit code — once in-the-wild exploitation of a mail platform is confirmed, PoC proliferation follows quickly. Treat any unpatched, internet-facing ZCS instance as actively targeted.
• Monitor the CISA Known Exploited Vulnerabilities (KEV) catalog — critical, exploited Zimbra flaws have historically been added rapidly; a KEV listing would impose a binding remediation deadline on U.S. federal agencies and serve as a strong prioritization signal for everyone else.

Detection & Response

The detections below target the highest-fidelity observable behaviors of this threat: the zimbra service or its JVM spawning shells, JSP files written into Jetty webapps directories, and Zimbra host processes making unexpected outbound connections. These are behaviors a veteran SOC analyst would actually want alerted on — they fire on real compromise, not on normal mail flow.

Sigma Rules

---
title: Zimbra Service Process Spawning Shell or Command Interpreter
id: 9c1f4a72-3b58-4d21-9e67-2a8f5c1b7d30
status: experimental
description: Detects the Zimbra mailboxd JVM, nginx, or Postfix processes spawning shells or interpreters, a strong indicator of post-exploitation following RCE against Zimbra Collaboration Suite as warned by CERT Polska.
references:
  - https://www.bleepingcomputer.com/news/security/critical-zimbra-rce-flaw-now-actively-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/opt/zimbra/'
      - 'mailboxd'
      - 'java'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/curl'
      - '/wget'
      - '/python'
      - '/python3'
      - '/perl'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Zimbra maintenance scripts executed via su - zimbra during patching
  - Legitimate zmmailboxdctl operations
level: high
---
title: Webshell Dropped in Zimbra Jetty Webapps Directory
id: 4e8b2d91-6a37-4c15-b802-7f3e9a1c5d24
status: experimental
description: Detects creation of JSP files in Zimbra Jetty webapps directories, the most common persistence artifact observed in Zimbra RCE exploitation campaigns.
references:
  - https://www.bleepingcomputer.com/news/security/critical-zimbra-rce-flaw-now-actively-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1505.003/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.persistence
  - attack.t1505.003
logsource:
  category: file_event
  product: linux
detection:
  selection_path:
    TargetFilename|contains:
      - '/opt/zimbra/jetty/webapps/'
      - '/opt/zimbra/jetty_base/webapps/'
  selection_ext:
    TargetFilename|endswith:
      - '.jsp'
      - '.jspx'
      - '.war'
  condition: selection_path and selection_ext
falsepositives:
  - Zimbra patch and upgrade operations deploying legitimate webapp files
level: critical
---
title: Zimbra Host Initiating Suspicious Outbound Connections
id: 7d2a6e15-91c4-4f83-a630-5b8c2e4d7a19
status: experimental
description: Detects Zimbra server processes establishing outbound connections to non-standard ports, consistent with C2 callbacks or data exfiltration following RCE exploitation.
references:
  - https://attack.mitre.org/techniques/T1071/
author: Security Arsenal
date: 2026/02/10
tags:
  - attack.command_and_control
  - attack.t1071
  - attack.exfiltration
logsource:
  category: network_connection
  product: linux
detection:
  selection_proc:
    Image|contains:
      - '/opt/zimbra/'
      - 'java'
  selection_initiated:
    Initiated: 'true'
  filter_mail_ports:
    DestinationPort:
      - 25
      - 80
      - 443
      - 465
      - 587
      - 993
      - 995
  condition: selection_proc and selection_initiated and not filter_mail_ports
falsepositives:
  - Zimbra update checks and license validation traffic
  - Internal LDAP or proxy service communication
level: medium

KQL — Microsoft Sentinel / Defender

Zimbra runs on Linux, so hunt via Syslog/CEF ingestion and Defender for Endpoint process telemetry if deployed on the host. This query hunts both the webshell artifact and post-exploitation command execution:

// Hunt 1: Process execution under Zimbra service user consistent with webshell activity
union withsource=tableName (Syslog), (DeviceProcessEvents)
| extend Hostname = coalesce(Computer, DeviceName)
| where TimeGenerated > ago(14d)
| where tableName == "Syslog" and SyslogMessage has_any ("/opt/zimbra", "zimbra")
      and SyslogMessage has_any ("/bin/sh", "/bin/bash", "curl ", "wget ", "nc -", "python -c", "base64 -d")
      or tableName == "DeviceProcessEvents" and FolderPath startswith "/opt/zimbra"
      and FileName in~ ("sh", "bash", "dash", "curl", "wget", "nc", "ncat", "python", "python3", "perl")
| project TimeGenerated, Hostname, tableName, ProcessName = coalesce(FileName, ProcessName),
          CommandLine = coalesce(ProcessCommandLine, SyslogMessage), InitiatingProcessName, AccountName
| order by TimeGenerated desc
;
// Hunt 2: JSP files recently written to Jetty webapps directories
DeviceFileEvents
| where TimeGenerated > ago(14d)
| where FolderPath has_any ("/opt/zimbra/jetty/webapps", "/opt/zimbra/jetty_base/webapps")
| where FileName endswith ".jsp" or FileName endswith ".jspx" or FileName endswith ".war"
| project TimeGenerated, DeviceName, FolderPath, FileName, InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc

Velociraptor VQL

Use this artifact to sweep Zimbra hosts for recently written webshells and suspicious child processes of the mailboxd JVM:

-- Zimbra compromise sweep: recent JSP drops in Jetty webapps and suspicious zimbra-user processes
LET webapps = SELECT FullPath, Mtime, Size
FROM glob(globs=['/opt/zimbra/jetty/webapps/**/*.jsp',
                 '/opt/zimbra/jetty_base/webapps/**/*.jsp',
                 '/opt/zimbra/jetty_base/webapps/**/*.war'])
WHERE Mtime > now() - 1209600
ORDER BY Mtime DESC

LET procs = SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Username =~ 'zimbra'
  AND (CommandLine =~ '/bin/(ba)?sh|curl|wget|nc |ncat|python|perl|base64'
       OR Name =~ '^(sh|bash|dash|nc|ncat)$')

SELECT * FROM webapps
UNION ALL
SELECT FullPath=NULL, Mtime=NULL, Size=NULL, Pid, Name, CommandLine, Username, CreateTime FROM procs

Verification and Hardening Script

Run on Zimbra hosts to audit exposure, hunt for webshell artifacts, and confirm patch posture:

#!/bin/bash
# Zimbra RCE exposure & compromise verification script — run as root

echo "=== Zimbra version check ==="
su - zimbra -c 'zmcontrol -v' 2>/dev/null || echo "zmcontrol not found — verify install path"

echo -e "\n=== Recent JSP/WAR files in Jetty webapps (last 30 days) ==="
find /opt/zimbra/jetty*/webapps/ -name '*.jsp' -o -name '*.jspx' -o -name '*.war' 2>/dev/null \
  | xargs -I{} find {} -mtime -30 2>/dev/null

echo -e "\n=== Files modified in webapps dirs (last 14 days) ==="
find /opt/zimbra/jetty*/webapps/ -type f -mtime -14 -ls 2>/dev/null

echo -e "\n=== Suspicious processes owned by zimbra user ==="
ps -u zimbra -o pid,ppid,comm,args | grep -Ei 'sh|bash|curl|wget|nc|python|perl' || echo "None found"

echo -e "\n=== Cron entries for zimbra and root (persistence check) ==="
crontab -u zimbra -l 2>/dev/null
crontab -l 2>/dev/null | grep -vi '^#'

echo -e "\n=== Admin console exposure check (7071 should NOT be public) ==="
ss -tlnp | grep 7071
echo "Verify via external scan that 7071/TCP is firewalled from the internet"

echo -e "\n=== Outbound connections from zimbra processes (non-mail ports) ==="
ss -tnp 2>/dev/null | grep -E 'zimbra|java' | grep -vE ':(25|80|443|465|587|993|995)\b' || echo "None found"

echo -e "\n=== ACTION: Apply vendor patch ==="
echo "1. Review the official Zimbra security advisory and patch immediately"
echo "2. After patching, re-run this script to confirm a clean baseline"
echo "3. If any JSP drops or suspicious processes are found, treat as compromised:"
echo "   - Isolate host, preserve /opt/zimbra/log and mailbox.log for forensics"
echo "   - Rotate ALL Zimbra and LDAP credentials"
echo "   - Initiate IR — webshell presence implies hands-on-keyboard activity"

Remediation

Prioritize these actions in order — hours matter on this one:

1. Patch immediately. Apply the latest Zimbra Collaboration Suite security update from the official Zimbra security advisories page (https://wiki.zimbra.com/wiki/Security_Center and https://www.zimbra.com/product/security/). Confirm you are on the current patch release for your major version — Zimbra patches are cumulative within a release train, and exploitation specifically targets instances lagging behind.
2. Assume breach and hunt before/while patching. Patching closes the door; it does not evict an attacker already inside. Run the webshell sweep and process hunts above on every ZCS host. Check /opt/zimbra/log/mailbox.log and nginx access logs for anomalous requests (unexpected URIs, POSTs to odd paths, single-source enumeration) in the weeks preceding patch.
3. Lock down the Admin console. The Zimbra Admin interface (7071/TCP) must never be reachable from the internet. Restrict it to a management VLAN or VPN and verify externally.
4. Rotate credentials if compromise is suspected. This includes the zimbra system user, LDAP admin/bind credentials, and — given mailbox access is the objective — consider forced password resets for users on the affected server.
5. Reduce the attack surface. Place ZCS behind a WAF/reverse proxy with virtual patching capability, enforce strict egress filtering from the mail host, and disable any unused ZCS service endpoints.
6. Monitor CISA KEV. If this vulnerability is added to the KEV catalog, federal agencies face a binding remediation deadline — use that listing as executive leverage for emergency change windows in your own organization.
7. Plan for the next one. Zimbra is a repeat target. If your organization cannot commit to same-day patching cadence for internet-facing mail infrastructure, evaluate managed alternatives or compensating controls that buy you time (segmentation, egress control, EDR on the host, and the detection logic above).

The pattern here is familiar: a critical flaw in a ubiquitous, internet-exposed collaboration platform, weaponized fast. The organizations that come out clean are the ones that treat a CERT active-exploitation warning as a patching emergency and a hunt trigger — not a news item.

Related Resources

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