A mailbox quota-accounting vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user to consume another user’s mailbox quota by repeatedly sharing and revoking a document. Creation of the recipient’s shared-file record charges the document size to mailbox-wide usage. Revocation deletes the record and reverses its folder counters without reversing the mailbox-wide charge. Repeated normal share notifications therefore accumulate quota usage after the visible records are gone. On accounts with a finite quota, this can prevent incoming mail and other size-increasing operations without recipient interaction. The issue affects ZCS 10.1.16 and 10.1.20.

An SMTP command injection vulnerability in the data-source testing functionality of Zimbra Collaboration Suite (ZCS) allows an ordinary authenticated user with account options enabled to inject CR/LF into the emailAddress inserted into an SMTP envelope command by a JSON SOAP request. After a successful preliminary POP3 or IMAP login, Zimbra sends the injected commands to the selected SMTP service. If that service accepts the pipelined transaction, the attacker can submit mail with attacker-selected recipients, headers and body content without victim interaction. The vulnerable command-construction path is present in ZCS 10.1.16 and 10.1.20.

A local privilege escalation vulnerability in the optional dnscache package of Zimbra Collaboration Suite (ZCS) allows the Unix zimbra account to access files with root privileges. The passwordless sudo policy permits arbitrary arguments to zmunbound, whose wrapper forwards them to Unbound without restricting the configuration path. An attacker can supply a configuration that retains root privileges and disables the chroot. Include directives expose root-readable file contents through parser errors, while an attacker-selected logfile path creates a root-owned file or appends Unbound log records to an existing file. This can disclose password hashes and private keys and corrupt privileged configuration files, preventing affected services from starting with the modified configuration. The affected configuration is present in ZCS 10.1.16 and 10.1.21 dnscache packages.

A local privilege escalation vulnerability in the Zimbra Collaboration Suite (ZCS) MTA package allows the Unix zimbra account to execute arbitrary commands as root. The installed sudo policy permits passwordless root execution of Postfix administration commands without restricting their arguments. An attacker can select a zimbra-controlled daemondirectory in the Postfix configuration and invoke postfix set-permissions, causing Postfix to execute the attacker's post-install program as root. The Postfix configuration directory is also writable by zimbra, so restricting postconf alone does not remove the execution path. Exploitation requires local command execution as zimbra on an MTA node. ZCS 10.1.16 and 10.1.21 are affected.

A local privilege escalation vulnerability in the zmmailboxdmgr launcher of Zimbra Collaboration Suite (ZCS) allows the Unix zimbra account to execute arbitrary commands as root. The passwordless sudo interface accepts JVM arguments that are not adequately restricted. An attacker can postpone Jetty's privilege drop, register an OnOutOfMemoryError command and force heap exhaustion during startup, causing the command to execute while the JVM still runs as root. Exploitation requires local command execution as zimbra on a mailbox server and interrupts mailboxd during the malicious restart. ZCS 10.1.16 and 10.1.21 are affected.

A missing authorization vulnerability in Zimbra Collaboration Suite (ZCS) allows a delegated administrator with no explicit administrative grants to overwrite global Zimlet configuration through ConfigureZimletRequest. The uploaded configuration can also add an attacker-controlled domain to the proxy allowlist of the default class of service. If a signed-in user in that class opens a crafted /service/proxy URL, Zimbra serves attacker-controlled HTML under its own origin. The resulting JavaScript can read mailbox data and perform authenticated actions as the victim. Exploitation requires a delegated-administrator account and access to the admin SOAP service; the browser compromise additionally requires the victim to open the crafted URL. ZCS 10.1.16 and 10.1.20 are affected.

A reflected cross-site scripting vulnerability in the login page of Zimbra Collaboration Suite (ZCS) allows an unauthenticated attacker to execute JavaScript through the zrememberme parameter. A crafted relogin URL selects a two-factor error display that inserts the parameter into a hidden input attribute without HTML encoding. A victim who opens the URL receives attacker-controlled script and page content under the legitimate Zimbra origin, allowing credential capture through a replacement login form. The relogin path logs out an existing session before rendering the payload, so the demonstrated attack does not inherit that session's mailbox access. ZCS 10.1.16 and 10.1.17 are affected.

An LDAP filter injection vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user to query otherwise unreturned attributes of calendar resources through SearchCalendarResourcesRequest. Zimbra escapes search values but inserts the supplied attribute names directly into LDAP filter expressions without validation. An attacker can inject additional conditions and use repeated matching queries to recover readable resource attributes such as internal mailbox hostnames and mail transport routes. The search remains restricted to calendar-resource objects and the LDAP service account's access rights. ZCS 10.1.16 and 10.1.21 are affected.

A cross-account authorization vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user to insert forged shared-file records into another user's mailbox through FileSharedWithMeRequest. The request bypasses delegated-account authorization and accepts attacker-selected file metadata, owner identifiers and declared sizes without validating a corresponding document share. An attacker can plant entries attributed to another real local account without that account sharing a document. No victim interaction is required. ZCS 10.1.16 and 10.1.20 are affected.

A CSS sanitization vulnerability in Zimbra Collaboration Suite (ZCS) allows an authenticated user with Briefcase access to publish a document that displays attacker-controlled content under the Zimbra origin. When processing a stylesheet containing non-ASCII characters, DefangFilter appends the final ASCII segment without sanitizing it. HTML stored as application/x-zimbra-doc can therefore retain CSS URL references that the normal sanitizer removes. An attacker can share a crafted document that loads external resources and displays a credential-collection form using Zimbra's own visual assets. Exploitation requires the victim to open the document in a browser that renders the content type inline; credential theft additionally requires form submission. ZCS 10.1.16 and 10.1.20 are affected.

A cross-site request forgery vulnerability in the OAuth extension of Zimbra Collaboration Suite (ZCS) Network Edition allows an attacker to link an attacker-controlled external account to a victim's mailbox. The OAuth callback does not bind its state value or authorization code to the initiating Zimbra session and instead selects the destination mailbox from the browser's current authentication cookie. On a deployment with the provider configured, an attacker can induce a signed-in victim to load a callback containing a fresh code for the attacker's provider account. This creates a persistent data source that imports attacker-controlled contacts or events. With bidirectional CalDAV synchronization, appointments subsequently created or edited in the linked calendar are also disclosed to the attacker. ZCS 10.1.16 and 10.1.20 are affected.

A hostname canonicalization vulnerability in the email HTML sanitizers of Zimbra Collaboration Suite (ZCS) allows an unauthenticated sender to bypass the restriction on forms that target the Zimbra host. DefangFilter and the OWASP ActionAttributePolicy compare the form-action hostname with the request hostname before browser URL canonicalization. A percent-encoded hostname can therefore survive sanitization while the browser submits the form to the normal Zimbra origin with the recipient's authentication cookie. This permits authenticated form requests from a crafted email after the recipient opens it in Classic and submits the form. The issue is present in ZCS 10.1.16 and 10.1.21. It does not bypass an endpoint's CSRF-token checks; a state-changing attack additionally requires an endpoint that accepts the resulting request without that protection.

An organizer authentication vulnerability in Zimbra Collaboration Suite (ZCS) allows an unauthenticated email sender to insert calendar invitations attributed to another user. The email delivery path permits external invitations but does not verify that the message sender is authorized to use the iCalendar ORGANIZER identity. When automatic invitation insertion is enabled, a crafted REQUEST component creates an event containing attacker-selected meeting details and reminders under a forged organizer without recipient interaction. No corresponding event is created in the claimed organizer's calendar. ZCS 10.1.16 and 10.1.21 are affected.

An attendee authentication vulnerability in the email calendar processing of Zimbra Collaboration Suite (ZCS) allows an unauthenticated sender to forge another attendee's response to an existing meeting. Zimbra passes a null sender identity when processing iCalendar REPLY components, causing the attendee authorization filter to be skipped. An attacker who knows the meeting UID, organizer address and attendee address can send a non-outdated reply that changes the attendee's participation status in the organizer's calendar. The change occurs automatically during delivery without organizer or attendee interaction. ZCS 10.1.16 and 10.1.21 are affected.

An organizer authentication vulnerability in the email calendar processing of Zimbra Collaboration Suite (ZCS) allows an unauthenticated sender to cancel or modify an existing meeting in a recipient's calendar. Zimbra accepts iCalendar CANCEL and REQUEST components without verifying that the email sender is authorized to act as the supplied organizer. An attacker who knows the meeting UID and organizer address can supply a non-outdated sequence number to move the recipient's meeting to Trash or replace its details. Processing occurs automatically during email delivery without recipient interaction. ZCS 10.1.16 and 10.1.21 are affected.

A request attribute override vulnerability in Zimbra Collaboration Suite (ZCS) allows unauthenticated requests to /h/ to populate servlet attributes intended for trusted internal dispatch. RestFilter copies URL parameters specifying an authentication token, target account, target item and dispatch state into the request attributes consumed by the Classic Web Client. Combined with CVE-2026-10632 on ZCS 10.1.16, this allows an attacker to supply their own valid token and document identifiers and execute JavaScript in another user's signed-in browser session. ZCS 10.1.17 blocks that XSS chain by changing the document renderer, but retains the request attribute override.

A reflected cross-site scripting vulnerability in the Classic Web Client of Zimbra Collaboration Suite (ZCS) allows an attacker to inject JavaScript through the packages parameter of the /h/rest document editor. The editor inserts package names into script attributes without HTML encoding. When combined with CVE-2026-50053, an attacker with an ordinary Zimbra account can supply their own authentication token and document identifiers in a URL and execute JavaScript in another signed-in user's Zimbra browser session when that user opens the URL. This permits reading mailbox data and performing authenticated actions as the victim. The issue affects ZCS 10.1.16 and was remediated in 10.1.17.

An authentication rate-limit bypass in Zimbra Collaboration Suite 10.1.0 through 10.1.21 allows unauthenticated attackers to make repeated password guesses through GraphQL without incrementing Zimbra’s source-IP failure counter. GraphQL aliases allow multiple authentication attempts in one HTTP request.

LDAP filter injection in Zimbra Collaboration Suite 10.1.0 through 10.1.21 allows unauthenticated attackers to alter external LDAP search filters. On domains using search-filter authentication and lazy provisioning, this creates a password oracle for external directory users. Authenticated S/MIME lookups can also return certificates and identity data for unintended directory entries.

A policy-enforcement flaw in Zimbra Collaboration Suite allows an authenticated user to bypass disabled mail forwarding by using a Sieve notify action to send copies of email content and headers to an arbitrary address.

An authorization flaw in Zimbra Collaboration Suite’s GrantRightsRequest allows an attacker with access to an authenticated account to grant another local account the loginAs right, creating persistent mailbox access and mail-sending authority that survives password changes and session expiry.

An authorization bypass in the EWS FindItem handler of Zimbra Collaboration Suite 10.1.0 through 10.1.19 allows an authenticated user with EWS enabled to read complete mailbox items, including raw MIME and attachments, from arbitrary local accounts without a share or delegation grant.

An unauthenticated calendar sender can place active markup in a COUNTER message's RFC From address. Selecting the message in Zimbra Classic triggers stored XSS, allowing the attacker to access mailbox data and act as the victim.

When OnlyOffice/Document Editing is available, an unauthenticated remote attacker with access to an existing supported public Briefcase document can abuse unsigned save fields to perform path-traversal writes and execute commands as zimbra.

An unauthenticated sender can forge a share notification that triggers stored XSS when a signed-in Zimbra Modern recipient clicks Accept Share, allowing the attacker to access mailbox data and act as the victim.

An unauthenticated sender can forge a share notification that triggers stored XSS when a signed-in Zimbra Classic recipient clicks Accept Share, allowing the attacker to access mailbox data and act as the victim.

CVE-2026-73570: Zimbra SNMP RCE abused to deploy coin-miner malware

CVE-2026-73570 is a Remote Code Execution issue in Zimbra Collaboration Suite (ZCS), related to SNMP notification/logwatch handling.

In short, an unauthenticated attacker can send a crafted SMTP request and get OS command execution as the zimbra user when the vulnerable SNMP/logwatch components are installed and enabled.

According to NVD, the issue affects Zimbra versions before 10.1.20 when SNMP is installed and SNMP notification is enabled. The Hacker News also reported active exploitation against Zimbra servers.

The observed attack chain is usually:

malicious SMTP request -> unsafe SNMP/logwatch handling -> command execution as zimbra -> malware dropped into /dev/shm -> cron persistence added -> miner or backdoor keeps respawning

What is CVE-2026-73570?

CVE-2026-73570 is an OS Command Injection vulnerability in Zimbra Collaboration Suite.

The issue is in the SNMP notification/logwatch flow, where attacker-controlled input is not handled safely before being passed into system-level processing.

The command runs as the zimbra user, not root. That is still serious because the zimbra user controls important Zimbra services, mailbox components, logs, cron jobs and runtime paths.

When is a Zimbra server at risk?

A server should be checked immediately if:

It is running Zimbra Collaboration Suite. It is not patched to a fixed version. zimbra-snmp or zimbra-net-snmp is installed. SNMP is enabled in Zimbra. zmlogswatch or zmswatch is running.

Quick checks:

su - zimbra -c 'zmcontrol -v' dpkg -l | grep -E 'zimbra-snmp|zimbra-net-snmp' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp' su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status'

If you see zimbraServiceEnabled: snmp and zmlogswatch is running, treat the server as high priority for compromise checks.

Signs of compromise

In the cases observed, malware was often dropped into /dev/shm. This directory is a tmpfs location, writable and easy to miss during a quick investigation.

Check:

ls -la /dev/shm crontab -l -u zimbra ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep

Common suspicious files:

/dev/shm/.khp /dev/shm/.khpts /dev/shm/.rguard /dev/shm/idle /dev/shm/javab /dev/shm/ksmd

A cron entry like this is a strong persistence indicator:

/dev/shm/.khp

Why does the malware keep coming back?

Deleting files from /dev/shm is usually not enough.

The malware can return because:

The malicious process is still running in memory. The zimbra crontab runs /dev/shm/.khp every minute. .rguard or idle may protect or redeploy the payload. SNMP/logwatch is still enabled, so the CVE can be exploited again.

The correct order is:

stop reinfection source -> preserve evidence -> kill malware processes -> remove malicious cron -> quarantine malware files -> verify clean state -> recover Zimbra services if needed -> patch/upgrade Zimbra

Cleanup procedure

Run the following commands as root. Review each command before running it on production.

Step 1: Stop the reinfection source

systemctl stop cron su - zimbra -c 'zmlogswatchctl stop' su - zimbra -c 'zmswatchctl stop' su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled snmp'

Disabling SNMP/logwatch is the most important containment step. Do not re-enable these components before Zimbra is patched.

Step 2: Preserve malware evidence

mkdir -p /root/incident-zimbra cp -a /dev/shm/.khp \ /dev/shm/.khpts \ /dev/shm/.rguard \ /dev/shm/idle \ /dev/shm/javab \ /dev/shm/ksmd \ /root/incident-zimbra/ 2>/dev/null crontab -l -u zimbra > /root/incident-zimbra/zimbra-cron-before.txt 2>&1 ps auxf > /root/incident-zimbra/ps-before.txt ss -tunap > /root/incident-zimbra/ss-before.txt sha256sum /root/incident-zimbra/ > /root/incident-zimbra/sha256.txt 2>/dev/null

Step 3: Kill malware processes

pkill -9 -u zimbra -f 'khp|rguard|javab|idle|ksmd'

Step 4: Remove malicious cron

crontab -l -u zimbra | grep -v '/dev/shm/.khp' | crontab -u zimbra -

Step 5: Quarantine malware files

mkdir -p /root/quarantine-zimbra mv /dev/shm/.khp \ /dev/shm/.khpts \ /dev/shm/.rguard \ /dev/shm/idle \ /dev/shm/javab \ /dev/shm/ksmd \ /root/quarantine-zimbra/ 2>/dev/null

Step 6: Start cron again

systemctl start cron systemctl is-active cron

Only start cron. Do not start zmlogswatch, zmswatch or SNMP before patching Zimbra.

Verify after cleanup

ls -la /dev/shm crontab -l -u zimbra | grep /dev/shm ps aux | grep -E 'khp|rguard|javab|idle|ksmd' | grep -v grep su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | grep snmp || echo SNMPDISABLED'

Expected result:

/dev/shm is clean no cron entry calling /dev/shm/.khp no suspicious javab/rguard/idle/khp/ksmd process SNMP is disabled

If Zimbra MySQL or mailbox fails

After malware activity or an unexpected reboot, Zimbra may show:

mailbox Stopped mysql.server is not running service webapp Stopped zimbra webapp Stopped zimbraAdmin webapp Stopped zimlet webapp Stopped

Check MySQL and services:

su - zimbra -c 'zmcontrol status' su - zimbra -c 'mysql.server status' ss -ltnp | grep 7306 tail -n 200 /opt/zimbra/log/mysqlerror.log

If MySQL is stuck in crash recovery or has a stale socket, back up relevant files first.

Backup before MySQL recovery

mkdir -p /root/zimbra-mysql-backup cp -a /opt/zimbra/log/mysqlerror.log /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/ibdata1 /root/zimbra-mysql-backup/ 2>/dev/null cp -a /opt/zimbra/db/data/iblogfile /root/zimbra-mysql-backup/ 2>/dev/null

Light MySQL recovery

su - zimbra -c 'zmmailboxdctl stop' mv /opt/zimbra/data/tmp/mysql/mysql.sock /root/zimbra-mysql-backup/mysql.sock.bak 2>/dev/null mv /opt/zimbra/db/data/tc.log /root/zimbra-mysql-backup/tc.log.bak 2>/dev/null su - zimbra -c 'mysql.server start' sleep 20 su - zimbra -c 'mysql.server status' su - zimbra -c 'zmmailboxdctl start' sleep 40 su - zimbra -c 'zmcontrol status'

Expected result:

mysql is running mailbox Running service webapp Running zimbra webapp Running zimbraAdmin webapp Running zimlet webapp Running

This is not a universal fix. Always check /opt/zimbra/log/mysqlerror.log first.

Does this delete mail data?

The malware cleanup steps do not touch mailbox data directly.

Zimbra mail data is usually stored in:

/opt/zimbra/store/

Zimbra database data is usually stored in:

/opt/zimbra/db/data/

The MySQL recovery steps touch tc.log and mysql.sock, so back up first.

Check for JSP webshells

After handling /dev/shm, cron and processes, also check for suspicious JSP files created by the zimbra user in recent days.

Important paths include:

/opt/zimbra/jetty/webapps/ /opt/zimbra/jettybase/webapps/ /tmp/

Unexpected JSP/JSPX files, executable scripts, archives or recently modified web application files may indicate payload staging or webshell deployment.

Check JSP/JSPX files:

find /opt/zimbra/jetty/webapps -type f \( -name ".jsp" -o -name ".jspx" \) -printf '%TY-%Tm-%Td %TH:%TM:%TS %p\n' | sort

If suspicious JSP backdoors are found, preserve evidence first, then quarantine them from both paths:

/opt/zimbra/jetty/webapps/zimbra/ /opt/zimbra/jettybase/webapps/zimbra/

Evidence backup and quarantine:

TS=$(date +%Y%m%d%H%M%S) INC=/root/incident-zmmail-jsp-webshell-$TS QUA=/root/quarantine-zmmail-jsp-webshell-$TS mkdir -p "$INC" "$QUA" # Save list and hashes find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jettybase/webapps/zimbra \ -xdev -type f \( -iname '.jsp' -o -iname '.jspx' \) -mtime -30 \ -print > "$INC/suspicious-jsp-list.txt" xargs -a "$INC/suspicious-jsp-list.txt" sha256sum > "$INC/suspicious-jsp-sha256.txt" # Backup samples while read f; do mkdir -p "$INC/files$(dirname "$f")" cp -a "$f" "$INC/files$f" done < "$INC/suspicious-jsp-list.txt" # Quarantine from webroot while read f; do mkdir -p "$QUA$(dirname "$f")" mv "$f" "$QUA$f" done < "$INC/suspicious-jsp-list.txt" # Verify find /opt/zimbra/jetty/webapps/zimbra /opt/zimbra/jettybase/webapps/zimbra \ -xdev -type f \( -iname '.jsp' -o -iname '.jspx' \) -mtime -30 -print

Risks:

If a file is a legitimate custom JSP, removing it may affect a custom webmail function. Random file names and content using exec, base64, AES or command execution are strong webshell indicators. This does not affect mailbox data. A restart is not always required immediately, but webmail should be verified after quarantine.

Important note: zmlogswatch/zmswatch may start again

After disabling SNMP/logwatch to mitigate CVE-2026-73570, zmlogswatch and zmswatch may start again after daily logrotate or after zmcontrol restart.

This happens because Zimbra logrotate configs often contain postrotate commands that restart zmlogswatchctl and zmswatchctl. Also, logger may still be listed in zimbraServiceEnabled.

So after temporary mitigation, check these services periodically, especially after midnight or after restarting Zimbra.

If you need a stronger temporary block before patching, back up the logrotate configs, comment the restart lines, and consider removing logger from zimbraServiceEnabled.

This can prevent logwatch from starting again and reopening the attack vector, but the Admin Console may lose part of its monitoring/statistics.

Disable zmlogswatch/zmswatch so they do not auto-start

Warning: disabling logger, zmlogswatch and zmswatch may make the Zimbra Admin Console show logger/monitoring as red, or remove some graphs/statistics.

During the unpatched phase, this is an acceptable temporary trade-off to prevent logwatch from restarting automatically.

After upgrading to a fixed version, restore the configuration from backup and re-enable logger if needed.

Back up Zimbra logrotate configs

cp -a /etc/logrotate.d/zimbra /etc/logrotate.d/zimbra.bak.$(date +%F-%H%M%S) cp -a /opt/zimbra/conf/zmlogrotate /opt/zimbra/conf/zmlogrotate.bak.$(date +%F-%H%M%S)

Open these two files:

/etc/logrotate.d/zimbra /opt/zimbra/conf/zmlogrotate

Find these lines, often around line 85 and 99:

su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Comment them:

# su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true # su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Remove logger from enabled services:

su - zimbra -c 'zmprov ms $(zmhostname) -zimbraServiceEnabled logger'

Stop current logwatch/swatch processes:

su - zimbra -c 'zmlogswatchctl stop' su - zimbra -c 'zmswatchctl stop' su - zimbra -c 'zmlocalconfig -e snmpnotify=no'

Verify:

su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status' su - zimbra -c 'zmlocalconfig snmpnotify' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp" || echo "LOGGERSNMPDISABLED"'

Expected result:

zmlogswatch is not running. zmswatch is not running. snmpnotify = no LOGGERSNMPDISABLED

Re-enable monitoring/logger after patching

Only do this after Zimbra is patched or upgraded.

su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled logger' su - zimbra -c 'zmlogswatchctl start' su - zimbra -c 'zmswatchctl start'

If you commented the logrotate files, open them again:

/etc/logrotate.d/zimbra /opt/zimbra/conf/zmlogrotate

Uncomment these lines:

su - zimbra -c "/opt/zimbra/bin/zmlogswatchctl restart" > /dev/null 2>&1 || true su - zimbra -c "/opt/zimbra/bin/zmswatchctl restart" > /dev/null 2>&1 || true

Re-enable SNMP only after patching

su - zimbra -c 'zmprov ms $(zmhostname) +zimbraServiceEnabled snmp' su - zimbra -c 'zmlocalconfig -e snmpnotify=yes' su - zimbra -c 'zmswatchctl start'

Verify after re-enabling:

su - zimbra -c 'zmcontrol status' su - zimbra -c 'zmlogswatchctl status' su - zimbra -c 'zmswatchctl status' su - zimbra -c 'zmlocalconfig snmpnotify' su - zimbra -c 'zmprov gs $(zmhostname) zimbraServiceEnabled | egrep "logger|snmp"'

Post-cleanup tasks

After the server is running again:

Keep SNMP/logwatch disabled until patched. Monitor /dev/shm for 30-60 minutes. Monitor the zimbra crontab. Monitor CPU/load and outbound connections. Check the mail queue. Patch or upgrade Zimbra to a fixed release. Only re-enable SNMP/logwatch after patching and verification.

Check queue:

/opt/zimbra/common/sbin/postqueue -p | tail -n 40

Summary workflow

1. Check /dev/shm, processes and crontab. 2. Stop cron, zmlogswatch and zmswatch. 3. Disable SNMP in Zimbra. 4. Preserve evidence. 5. Kill malware processes. 6. Remove malicious cron. 7. Quarantine malware files. 8. Start cron again. 9. Verify that malware does not respawn. 10. Recover MySQL/mailbox if needed. 11. Check JSP webshells in Zimbra webapps paths. 12. Monitor queue and services. 13. Prevent zmlogswatch/zmswatch from auto-starting before patching. 14. Patch or upgrade Zimbra. 15. Re-enable logger/SNMP only after patching and verification.

References

NVD: CVE-2026-73570 The Hacker News: attackers exploit Zimbra SNMP flaw Zimbra Security Center Zimbra Security Advisories

Conclusion

CVE-2026-73570 is serious because it can allow remote command execution as the zimbra user through SNMP notification/logwatch handling.

In observed incidents, attackers dropped malware into /dev/shm, added cron persistence, and ran a miner or backdoor.

The key point is this: do not only delete the malware file. Stop the reinfection path first.

A practical response order is:

stop cron + SNMP/logwatch -> preserve evidence -> kill malware -> remove malicious cron -> quarantine payloads -> check JSP webshells -> verify clean state -> recover Zimbra if needed -> block logwatch auto-restart before patching -> patch/upgrade Zimbra

Most important: do not re-enable SNMP/logwatch before Zimbra is patched, because that may allow the malware to return.

In Zimbra Collaboration (ZCS) before 10.1.17, weak cryptographic key generation vulnerability exists in the OnlyOffice integration. The zimbraDocumentEditingJwtSecret is generated using an insecure random number generator, resulting in insufficient entropy. An attacker who obtains a JWT signed with the generated secret may be able to recover the JWT signing secret through offline brute-force, potentially enabling JWT forgery.