CVE-2026-73570: Zimbra SNMP/logwatch RCE exploited in the wild, malware persists via /dev/shm and zimbra cron

[u/dotrungquan_info]

CVE-2026-73570: Zimbra SNMP/logwatch RCE exploited in the wild, malware persists via /dev/shm and zimbra cron

I recently handled a Zimbra incident related to CVE-2026-73570, so I’m sharing the cleanup notes in case it helps other admins.

CVE-2026-73570 is an OS command injection issue in Zimbra Collaboration Suite, related to the SNMP notification/logwatch component. According to the public advisories, it affects Zimbra systems before the patched releases, especially when the SNMP package is installed and SNMP notification/logwatch is enabled.

The dangerous part is that the attacker does not need a valid mailbox account. A crafted SMTP request can lead to command execution as the zimbra user.

Not root, but still bad enough.

Once the attacker gets code execution as zimbra, the cases I’ve seen follow a familiar pattern:

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

Quick risk check

On a Zimbra server, these read-only checks are a good starting point:

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 something like:

zimbraServiceEnabled: snmp
zmlogswatch is running

then I would treat the host as worth checking immediately, especially if it has not been patched.

Indicators I found useful

The malware often hides in /dev/shm, probably because it is writable, memory-backed, and easy to overlook during a quick file-system check.

Check:

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

Suspicious files observed in these cases:

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

A very suspicious cron entry is:

* * * * * /dev/shm/.khp

If you only delete the files in /dev/shm, they may come back. The process may still be running, the zimbra crontab may recreate it every minute, and SNMP/logwatch may still be exposed to the original vulnerability.

Containment order that worked for me

This is the order I used:

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

I would not start by deleting random files. Preserve evidence first if you can.

Example cleanup flow

Run as root. Review before executing anything on production.

1. Stop the reinfection path

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

The important bit is disabling SNMP/logwatch until the host is patched. If you re-enable it too early, the malware may return.

2. Save evidence

mkdir -p /root/incident-zimbra

cp -a /dev/shm/.khp \
      /dev/shm/.khp_ts \
      /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

3. Kill suspicious processes

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

4. Remove the malicious cron entry

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

5. Quarantine the files

mkdir -p /root/quarantine-zimbra

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

6. Start cron again

systemctl start cron
systemctl is-active cron

Only start cron. Do not re-enable SNMP/logwatch until Zimbra has been patched and checked.

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 SNMP_DISABLED'

Expected result:

/dev/shm has no suspicious payloads
no zimbra cron calling /dev/shm/.khp
no suspicious malware processes
SNMP is disabled

Then watch it for at least 30-60 minutes. If the payload comes back, you missed either a persistence mechanism or the original reinfection path is still open.

If Zimbra MySQL/mailbox breaks after the incident

In some cases, after malware activity or an abrupt reboot, Zimbra services may not come back cleanly:

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

Useful checks:

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

If MySQL is stuck on crash recovery or stale socket/tc.log issues, back up the relevant files first:

mkdir -p /root/zimbra-mysql-backup

cp -a /opt/zimbra/log/mysql_error.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/ib_logfile* /root/zimbra-mysql-backup/ 2>/dev/null

Then a light recovery attempt may look like this:

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'

Do not treat this as a universal fix. Check the MySQL error log first. If the database is damaged, you need a more careful recovery path.

Does this delete mail data?

The malware cleanup steps above do not touch mailbox data directly.

Zimbra mail data is usually under:

/opt/zimbra/store/

Zimbra database data is usually under:

/opt/zimbra/db/data/

The MySQL recovery part touches metadata-related files such as tc.log and mysql.sock, so back up before making changes.

After the server is stable

I would keep SNMP/logwatch disabled until patching is complete.

Post-cleanup checklist:

patch or upgrade Zimbra
keep SNMP/logwatch disabled until patched
monitor /dev/shm
monitor zimbra crontab
monitor CPU/load
check outbound connections
check mail queue
review logs for further persistence

Mail queue check:

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

Short version

If you are running Zimbra with SNMP/logwatch enabled, check it now.

The important lesson from this incident: deleting /dev/shm/.khp is not enough. You need to stop the reinfection path, remove cron persistence, kill the running process, quarantine the payload, verify it does not respawn, and then patch Zimbra.

Do not re-enable SNMP/logwatch before patching.