Zimbra Flaw Exploited Before Disclosure

Patches are supposed to close a window. In the case of one high-severity flaw in Zimbra Collaboration Suite, that window stayed open — and according to Microsoft, someone walked through it. The company reported that attackers began exploiting the bug shortly after a fix shipped, but before the vulnerability was made public.

The episode highlights a gap that defenders rarely see: the stretch of time between a vendor publishing a patch and that patch being described in detail to the world.

A critical bug in SNMP handling

The vulnerability is tracked as CVE-2026-73570 and carries a CVSS score of 8.9. It is an OS command injection flaw that exists because, in ZCS before version 10.1.20, untrusted input during SNMP notification processing is improperly sanitized.

Exploitation requires a specific configuration. If the zimbra-snmp package has been installed and SNMP notifications have been enabled, an attacker can trigger the defect using specially crafted SMTP requests.

When successful, the bug lets unauthenticated attackers achieve remote code execution with the privileges of the Zimbra user. No credentials are needed to start the chain — only reachability and the right feature turned on.

The patching and disclosure timeline

Patches for CVE-2026-73570 were rolled out on July 20 in ZCS version 10.1.20. The vulnerability was publicly disclosed on August 13.

Poland's CERT Polska flagged the defect as exploited and released indicators of compromise on August 17. But the exploitation itself began earlier than any public warning.

Microsoft's own observation places reconnaissance between July 28 and August 7 — after the July 20 fix became available, and before the August 13 disclosure.

That gap is the crux of the story: a fix existed, but the description of what it fixed did not, leaving anyone watching only public advisories without a signal during those weeks.

Scanning before the strike

Microsoft reported that during that window it observed two distinct out-of-band scanning tools probing the vulnerable injection point. The reconnaissance activity used an execution path that was later seen during exploitation.

The probes were designed to validate command execution via lightweight out-of-band mechanisms, without delivering a payload. In other words, the reconnaissance phase was about confirming reach and control, not yet about installing anything.

That distinction matters for defenders reviewing logs. A probe that confirms command execution may look very different from a full webshell deployment, and it may be easy to miss if no payload ever lands.

Only after that validation did the follow-up exploitation activity appear, according to Microsoft's account.

Webshells across Jetty and mailboxd

As part of the observed exploitation, attackers deployed JSP webshells to publicly accessible application directories. They executed content through wget or curl, launched background processes, and established interactive reverse shells.

Microsoft described a deliberate spread of access points. "Multiple JSP webshells were deployed across Jetty and mailboxd application paths, including additional copies on peer mailbox nodes. This provided alternative access paths across different Zimbra configurations and reduced reliance on a single webshell," the company said.

Deploying multiple webshells across nodes means that removing one file does not necessarily end an intrusion. Each path offers a separate route back into the application.

Mapping the cluster and escalating

From there, Microsoft reported that the attackers mapped clusters, fingerprinted the environment, and checked for the Zimbra SSH identity. They escalated privileges to root using legitimate Zimbra tools.

They also deployed a secondary persistence mechanism: a systemd service named zimlog.service.

According to Microsoft, the hackers targeted Zimbra's centralized service and authentication secrets for credential exfiltration, then used that login material for authenticated LDAP queries that allowed them to retrieve high-value secrets.

They also used Zimbra's existing SSH identity to access other nodes in the cluster, and used HTTP and HTTPS callbacks to validate command execution.

Finally, they deployed a full remote-access agent providing interactive shell access, bidirectional file operations, and SOCKS5 proxying, according to Microsoft.

What defenders should check

Zimbra Collaboration Suite users are advised to update their instances to version 10.1.20 or later, uninstall the optional package, disable the vulnerable configuration, restrict SNMP and SMTP access, and review their environments for signs of compromise.

Those steps map directly onto the configuration the flaw depends on. If the zimbra-snmp package was never installed, the vulnerable code path may not be reachable in a given deployment. But administrators who enabled it and exposed SNMP and SMTP access should treat the affected window as a period of elevated risk.

Microsoft's report also gives defenders concrete artifacts to hunt for. The webshells in Jetty and mailboxd application paths, the systemd service zimlog.service, outbound HTTP and HTTPS callbacks tied to command validation, and authenticated LDAP queries using Zimbra service credentials are all behaviors described in the report.

Because the campaign involved access to peer mailbox nodes, checking only the initially identified host may not be enough. Administrators should look across the cluster, not just at the entry point.

The gap between patch and advisory

The most uncomfortable detail is timing. Microsoft said the probing ran between July 28 and August 7, while the patch arrived on July 20 and public disclosure came on August 13. CERT Polska's indicators of compromise, which flagged the flaw as exploited, appeared on August 17.

For organizations that track vendor releases closely, a patch on July 20 is itself a signal that something needed fixing. But without an advisory explaining which component and which configuration were affected, prioritizing that patch against the rest of a monthly workload is harder.

Microsoft's report shows that attackers did not wait for the advisory. The reconnaissance used an execution path that later appeared in exploitation, and the follow-up activity included webshells, reverse shells, and a persistence service.

The full sequence Microsoft described: out-of-band scanning without payload delivery, JSP webshells in publicly accessible directories, execution through wget or curl, background processes, interactive reverse shells, cluster mapping, environment fingerprinting, checks for the Zimbra SSH identity, privilege escalation to root using legitimate Zimbra tools, a systemd persistence service, credential exfiltration from Zimbra's centralized service and authentication secrets, authenticated LDAP queries for high-value secrets, SSH-based access to other nodes, HTTP and HTTPS callbacks, and a remote-access agent with SOCKS5 proxying.

Why this matters to anyone running Zimbra

The practical takeaway is that patching speed and patching visibility are not the same thing. A fix that ships quietly still leaves a stretch of time in which exploitation can occur without public warning, and this case suggests an attacker can find and use that stretch.

For businesses running Zimbra Collaboration Suite, the immediate question is which version is deployed and whether the zimbra-snmp package is installed with SNMP notifications enabled. If that configuration is present, the report's recommended steps — update to 10.1.20 or later, remove the optional package, disable the vulnerable setting, restrict SNMP and SMTP access, and check for compromise — are the ones to follow.

For security teams more broadly, the case is a reminder that the period between a patch and its public explanation can be an active one. Logs from late July and early August may deserve a second look, particularly any evidence of out-of-band command validation, unexpected JSP files in application directories, or a systemd service named zimlog.service.

The single-source nature of this reporting means some details of the campaign may still be corroborated or refined elsewhere. What Microsoft has described, however, is a full chain from reconnaissance to persistence — and a timeline that shows the chain started before most defenders had a name for the bug.