Zimbra – Version 8.8.15 under attack and exploited

I have to confess: Zimbra 8.8.15 lasted much longer than I ever imagined. But it seems that its final days have arrived, and the platform is now being actively and severely exploited.

A CVE has even been published for one of the vulnerabilities involved — CVE-2026-73570 — which you can read about here. But there is much more going on than a single CVE.

I probably don’t need to tell you that Zimbra 8.8.15 is at the end of its life. Migrating to a stable, actively maintained, and trustworthy platform is no longer something that can be postponed.

At this point, it is only a matter of time before attackers move beyond simply gaining access and start encrypting, corrupting, or destroying data. When that happens, your mailboxes and the data they contain may be at serious risk.

Pick your path: Carbonio CE or Zimbra NE. Just do it. And do it ASAP.

That said, I want to share with you the measures I have been implementing to keep Zimbra 8.8.15 as safe as possible against these exploits — at least for now.

I have seen several different attack techniques, but they have a few things in common. In particular, attackers attempt to write malicious files and binaries into locations such as:

/tmp
/var/tmp
/opt/zimbra/mailboxd/webapps/zimbra/public/

They also appear to target specific services, especially SNMP.

So, in the next sections, I will walk through the steps I have been taking to harden Zimbra 8.8.15: restricting write permissions, protecting vulnerable directories, disabling unnecessary services, and fixing permissions where necessary — while keeping Zimbra functioning as expected.

This is not a replacement for migration, and it should not be treated as one.

It is simply a set of defensive measures to buy some time while you plan — and execute — the migration away from Zimbra 8.8.15.

Disabling SNMP

su - zimbra
zmprov ms "$(zmhostname)" -zimbraServiceEnabled snmp
zmcontrol restart

Zimbra crontab

Chech in there is anything at the end of zimbra’s cron file file. There should be nothing after

# ZIMBRAEND — DO NOT EDIT ANYTHING BETWEEN THIS LINE AND ZIMBRASTART

If so, remove it.

# Ubuntu
cat /var/spool/cron/crontabs/zimbra

# Centos
cat /var/spool/cron/zimbra

Then change its attributes, making it immutable:

# Ubuntu
chattr +i /var/spool/cron/crontabs/zimbra

# Centos
chattr +i /var/spool/cron/zimbra

Making public not public

chattr +i -R /opt/zimbra/mailboxd/webapps/zimbra/public/

Protecting /tmp and /var/tmp

These exploits wanna write or create files in those public directories, so let’s not allow it

setfacl -m u:zimbra:rx /tmp
setfacl -m u:zimbra:rx /var/tmp

This has consequences because some services must write in a “tmp” directory… so let’s give it to them

Creating our own tmp

mkdir /opt/tmp

Fixing cbpolicyd

This will add “TMPDIR=/opt/tmp” to zmcbpolicydctl, allowing it to run properly

cp -a /opt/zimbra/bin/zmcbpolicydctl /opt/zimbra/bin/zmcbpolicydctl.bak

sed -i '/\/opt\/zimbra\/common\/bin\/cbpolicyd --config/i\      export TMPDIR=/opt/tmp' /opt/zimbra/bin/zmcbpolicydctl

su - zimbra
zmcbpolicydctl restart

Fixing zmstat-mysql

This will change “my $tempFile” from /tmp to /opt/tmp

cp -a /opt/zimbra/common/lib/perl5/Zimbra/DB/DB.pm /opt/zimbra/common/lib/perl5/Zimbra/DB/DB.pm.bak

sed -i 's#my \$tempFile = "/tmp/mysql.out\.\$\$";#my $tempFile = "/opt/tmp/mysql.out.$$";#'  /opt/zimbra/common/lib/perl5/Zimbra/DB/DB.pm

su - zimbra
zmstatctl restart

Conclusion

su - zimbra
zmcontrol status

All these changes keep Zimbra running well enough to give you time to migrate. Remember: you’re running against the clock.

For now, that’s all, but I have the feeling more is coming. If so, I’ll upgrade this article.

Published: 23/08/2026 | Updated: 25/08/2026