CVE-2026-73570 turns a narrow Zimbra configuration into an internet-reachable command-execution path. It affects Zimbra Collaboration instances before version 10.1.20 when the optional zimbra-snmp package is installed and SNMP notifications are enabled. An unauthenticated attacker can send crafted SMTP requests that result in operating-system command execution as the zimbra user. CERT Polska reported active exploitation, and CERT.LV published a further active-exploitation notice on September 1.
For an organization that operates its own mail infrastructure, this is a patch-and-hunt event. Installing version 10.1.20 removes the known vulnerable code path. It does not answer whether an attacker used that path before the upgrade, what commands ran, whether persistence was established, or whether credentials and mail data require further review.
That distinction matters because a Zimbra server is rarely an isolated application. It commonly holds mailboxes, address books, authentication integrations, transport configuration, and an operational relationship with the rest of the environment. A security team should handle this vulnerability as a potential entry point into a business system, with an owner, a response record, and a defined decision about whether compromise evidence exists.
Establish whether the vulnerable condition exists
Start by locating every self-managed and provider-managed Zimbra deployment. Do not assume that your IT team owns every instance. Older business units, acquired organizations, regional offices, disaster-recovery environments, and external hosting arrangements often create blind spots.
Build a short list that records the server name, IP address, public exposure, Zimbra version, operating-system owner, mail-service owner, hosting model, backup location, log destination, and last known maintenance date. Include dormant instances and recovery systems. An instance that is powered down today can return during a recovery event with an outdated version and the same exposure.
The affected software boundary is straightforward: Zimbra Collaboration before 10.1.20. The configuration boundary needs more care. The vulnerability requires the optional zimbra-snmp package, SNMP notifications enabled through snmp_notify, and the swatchdog service. CERT Polska notes that swatchdog is enabled by default. Do not infer safety only because an administrator believes SNMP is unused. Verify the package and configuration on each server.
This is also a useful point to separate production facts from assumptions. A public MX record does not prove a host runs Zimbra. A Zimbra host does not prove the vulnerable SNMP path is enabled. Conversely, a system that is not directly exposed to the web may still accept SMTP traffic through a gateway or network rule that makes the attack path reachable. The teams responsible should validate the actual flow.
Questions to answer before change work begins
The response lead should be able to get clear answers to a few operational questions:
- Which Zimbra servers run a version earlier than 10.1.20?
- Which of those servers have
zimbra-snmp,snmp_notify, andswatchdogin the vulnerable combination? - Which systems can send SMTP traffic to them, including internet-facing relays and internal applications?
- Are
/var/log/zimbra.log, operating-system audit data, process telemetry, and network logs retained long enough to investigate the reported exploitation window? - Can the team take an evidence-preserving backup or snapshot before maintenance without overwriting useful forensic material?
The answers determine priority. A vulnerable server that can receive attacker-controlled SMTP traffic deserves immediate handling. A server that has been upgraded but cannot be shown clean still needs investigation.
Upgrade without erasing the investigation
Zimbra lists version 10.1.20 as the release that fixes the command-injection issue. Its advisory also warns that unsupported versions may carry the same vulnerabilities even when they are not represented in the current supported-version table. Organizations running an older branch should treat unsupported software as a migration and risk decision, not as a reason to defer the response.
Before making changes, preserve the information needed to reconstruct what happened. This does not require every organization to perform a full forensic acquisition on every server. It does require avoiding the common failure mode where a team patches, restarts services, accidentally rotates logs, and only then asks whether the server was compromised.
At a minimum, preserve relevant Zimbra logs, web-server and mail-transfer logs, current process and network-connection information if available, scheduled-task and service configuration, recently modified files, and the current Zimbra configuration. Record the server time, time zone, and the precise time each response action occurs. If the organization has endpoint detection, SIEM, or centralized Linux logging, place a retention hold on the relevant records before maintenance.
Then schedule and perform the upgrade through the normal change process, with an emergency path if the server is internet-facing and meets the vulnerable condition. Confirm the installed release after the change. Confirm that expected mail flow, authentication, monitoring, backup jobs, and administrative access still work. A successful package operation is not enough evidence that the business service returned safely.
Temporary configuration changes may reduce exposure while an upgrade is being arranged, but they are not a substitute for the vendor fix. Security teams should avoid publishing improvised commands or assuming that disabling an adjacent service removes every reachable path. The verified remediation is an upgrade to the fixed release.
Hunt for the activity that patch status cannot show
CERT Polska provided useful starting points for a targeted review. It recommends searching /var/log/zimbra.log for service-status changes containing a suspicious payload, including entries where a service changes from stopped to running or from running to stopped. It also recommends checking for files created by the zimbra user during the prior 30 days in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/, and /tmp/.
Those checks are starting points, not proof that an instance is clean. An attacker can use arbitrary commands, so teams should investigate anomalies in the context of their own server baseline. Review unexpected child processes from Zimbra-related services, unfamiliar outbound connections, new or modified cron entries, changes to service definitions, unusual SSH authorized keys, recent account changes, suspicious web application content, and access to credential stores or mail archives.
Focus on chronology. Determine whether unusual log entries or file changes occurred before the server was patched. Correlate those events with SMTP connections, web access, authentication events, proxy logs, firewall records, and endpoint telemetry. A malicious file with a familiar name is more useful when the team can show which process wrote it, which remote connection preceded it, and whether it later contacted another host.
If evidence suggests exploitation, treat the host as compromised rather than simply patched. Isolate it in a way that preserves access for the incident-response team and avoids unnecessary service restoration from an untrusted server. Scope credentials and tokens accessible to the zimbra account and the host, review administrative accounts and delegated access, and look for lateral movement from the server. Decisions about password resets, token revocation, mailbox review, notification, rebuild, and restoration should follow the evidence and the organization's incident-response process.
Turn one mail-server emergency into a repeatable control
The broader failure exposed by incidents like this is often not the missing patch. It is the inability to answer basic questions quickly: Which servers run the product? Which configuration makes them vulnerable? Who can authorize maintenance? Where are the logs? Who decides whether a patched system needs an incident investigation?
Remote-access appliances, mail systems, file-transfer platforms, identity servers, and management consoles deserve a separate exposure inventory and a faster emergency workflow than ordinary workstation patching. For each category, document the technical owner and business owner, internet exposure, authentication dependencies, monitoring coverage, backup and recovery method, support status, normal maintenance window, and escalation route.
Use configuration checks alongside version checks. The Zimbra issue is a good example of why version-only vulnerability reporting can leave teams with both false urgency and false confidence. Every pre-10.1.20 host must be assessed, but the vulnerable configuration depends on an optional component and enabled settings. The team needs enough endpoint and configuration context to identify the systems that are truly exposed, then enough evidence to prove they were remediated.
Finally, keep a response record that connects the vulnerability, affected assets, evidence preserved, patch decision, hunt results, owner, exceptions, and follow-up work. This is useful during an incident and months later, when leadership, auditors, customers, or insurers ask what the organization knew and what it did.
Meridian Vulnerability Management can support that operating model by using Aegis endpoint context across Windows, macOS, and Linux to maintain fleet visibility, investigate emerging threats, track remediation, and verify endpoint state after change work.
The immediate action is simple: identify Zimbra systems before 10.1.20, verify the SNMP condition, preserve relevant evidence, upgrade, and hunt for the activity CERT Polska described. The durable action is to make sure the next exploited infrastructure flaw does not begin with a search for the system owner and end with a patch report that cannot establish whether the system was already breached.
