Zimbra Exploited in the 24-Day Silence Between Patch and Bulletin

A Zimbra flaw patched on July 20 sat unmentioned for three weeks. Attackers found it first.

Microsoft says hackers began exploiting CVE-2026-73570, a high-severity OS command injection bug in Zimbra Collaboration Suite, between the patch release and public disclosure. The gap between fix and bulletin was 24 days. Two out-of-band scanning tools were observed probing the vulnerable code path between July 28 and August 7, before anyone outside the vendor knew the bug existed.

For the African banks, fintechs and government departments that run Zimbra as their mail backbone, this is a bad kind of vulnerability timeline. The fix existed. Nobody could justify deploying it, because there was nothing to deploy it against yet. The attackers simply read the patch diff.

The bug itself

CVE-2026-73570 carries a CVSS score of 8.9. It lives in ZCS versions before 10.1.20, where untrusted input during SNMP notification processing is improperly sanitized. Two conditions make it reachable: the optional zimbra-snmp package must be installed, and SNMP notifications must be enabled. When they are, an attacker can trigger the flaw with specially crafted SMTP requests. No login and no user interaction are needed; a crafted email arriving on the mail port is enough.

Successful exploitation gives unauthenticated remote code execution running as the zimbra user. On a mail server that is already serious trouble, because the zimbra account can read mail flow and reach the LDAP directory that stores the organization’s credentials.

What the attackers did after they landed

The post-exploitation chain Microsoft observed reads like an email-server takeover playbook:

• JSP webshells deployed across Jetty and mailboxd application paths, with extra copies on peer mailbox nodes, so losing one webshell meant nothing
• Content executed through wget or curl, background processes launched, interactive reverse shells established
• Clusters mapped and environments fingerprinted; Zimbra’s own SSH identity was checked, then used to move laterally to other nodes
• Privilege escalation to root using legitimate Zimbra tooling, not exotic exploits
• A systemd service named zimlog.service installed for persistence, disguised as a logging daemon
• Credential material pulled from Zimbra’s centralized service and authentication secrets, then used for authenticated LDAP queries to harvest more high-value secrets
• A full remote-access agent installed, offering interactive shell access, bidirectional file operations and SOCKS5 proxying, which turns your mail server into the attacker’s exit node

CERT Polska flagged the defect as exploited in the wild and published indicators of compromise on August 17, days after disclosure. By then the scanning phase Microsoft captured in late July was already history.

The quiet window is the real story

I keep coming back to the July 28 to August 7 reconnaissance. That activity used the same execution path later seen in exploitation, but delivered no payload, only lightweight out-of-band probes to validate command execution. Someone was quietly walking a target list, confirming which Zimbra boxes had the SNMP package enabled, weeks before the CVE number was public. Security by nondisclosure failed the way it always does: the vendor’s own patch told the attackers where to look.

There is a structural lesson here for anyone who runs patch cycles on change-control windows. If your policy is to deploy when the bulletin lands, you inherit every blind gap between fix and disclosure. Hotfix-on-release, before the write-up exists, is the only stance that closes it.

What to do now

Zimbra’s guidance, echoed by Microsoft: update to ZCS 10.1.20 or later. If you cannot patch immediately, uninstall the optional zimbra-snmp package or disable SNMP notifications, and restrict SNMP and SMTP access paths. Then hunt. Look for unexpected files under Jetty and mailboxd web paths, a zimlog.service unit you did not create, outbound SSH between mailbox nodes, and LDAP binds from the zimbra account that don’t match your integrations.

Where eHawu fits

You cannot always patch a mail server the day a fix drops, but you can refuse the request at the network layer. eHawu inspects SMTP and SNMP traffic at the edge and drops crafted payloads before they reach an unpatched ZCS instance, with a full audit trail of who probed you and when. The quiet window stops being undefended. Threat intelligence and virtual patching for African enterprises, from the eHawu security team.