Internet-facing Zimbra mail servers are being actively targeted through a flaw that needs no password, no account, and no user interaction — just a request crafted to reach the server's SNMP notification handling.
What happened
Zimbra's monitoring process builds an snmptrap command whenever a service-state change needs to be reported, and it runs that command as the zimbra service account. Researchers found that shell characters smuggled into the data feeding that notification get executed along with it, handing an unauthenticated attacker code execution on the mail server itself.
Microsoft, which investigated the campaign, observed intrusion activity in the window after the fixed release (version 10.1.20) had already shipped but before the flaw was disclosed publicly — a stretch where patched servers existed but most administrators had no reason yet to prioritize the update.
Once inside, operators moved fast and methodically: they rewrote web-directory permissions, dropped JSP web shells into public application folders, then quietly removed the staging artifacts and re-planted alternate shells on other mail nodes. Encrypted reverse shells over named pipes gave them interactive access, and on multi-server deployments they reused Zimbra's own internal SSH trust relationships with rsync to move laterally across the mail cluster — turning one compromised box into an organization-wide foothold.
The credential theft went well beyond individual mailboxes. Using Zimbra's own configuration and directory-query tools, attackers pulled LDAP, MySQL, and Postfix service credentials, pre-authentication keys, token-signing material, and two-factor secrets — the kind of material that unlocks systems far outside a single inbox. A purpose-built collection tool read local configuration files, exported database tables, and staged certificates and private keys for transfer. On at least one server, attackers archived mailbox backup data locally and attempted to push it to cloud storage. Separately, a privilege-escalation technique abused a writable log location together with the PAM configuration to grant the service account passwordless, administrator-level access. Investigators also found a disguised system service installed outside Zimbra's normal directories, set to launch at boot with falsified timestamps, plus a cryptominer running alongside the more targeted tooling.
Why it matters
Mail servers sit at the center of an organization's identity and communication infrastructure. Compromising one doesn't just expose a mailbox — it can hand over the credentials and signing keys that unlock directories, databases, and federated services across the whole environment. Because this flaw requires no login and no user interaction, any internet-reachable Zimbra instance that hasn't been patched is exposed regardless of how strong individual account security is.
What to do
- Upgrade to Zimbra 10.1.20 or later immediately — this closes the flaw at the source.
- If patching isn't immediately possible, remove the SNMP component, disable SNMP notifications, and restrict SNMP/SMTP access to trusted hosts only.
- Audit every mail node for unexpected JSP files, generated servlet artifacts, and recent permission changes.
- Rotate Zimbra pre-authentication keys and any token-signing material that may have been exposed.
- Review system services, cron jobs, and startup files for suspicious ownership, unexpected enablement, or altered timestamps.
- Treat any reverse-shell alert or unexpected outbound connection from an internet-facing mail server as a priority incident, and preserve logs before containment so the full scope of access can be reconstructed.