Zimbra Mail Servers Are Being Hijacked — One Crafted Email Can Trigger Command Execution

• The Mess: Attackers are actively exploiting CVE-2026-73570 in Zimbra Collaboration Suite. A crafted email can reach an unauthenticated command-injection path and hand attackers shell access to the mail server.
• The Damage: Attackers have deployed web shells, reverse shells, stolen authentication secrets, escalated to root and accessed mailbox data.
• The Fix: Upgrade Zimbra to 10.1.20 or later immediately, or remove zimbra-snmp and disable SNMP notifications until patching is possible.

Email servers are boring until they aren’t.

Microsoft Threat Intelligence has now documented active exploitation of CVE-2026-73570, an unauthenticated operating-system command injection vulnerability in Zimbra Collaboration Suite.

The interesting part isn’t the CVSS number.

It’s what attackers did after getting the first shell.

They didn’t stop at command execution.

They installed JSP web shells, established reverse shells, escalated privileges, created persistence, harvested Zimbra credentials and authentication secrets, and attempted to extract mailbox data.

This is a complete server takeover chain.

The bug lives in Zimbra’s SNMP notification path

CVE-2026-73570 affects Zimbra installations where the optional zimbra-snmp package is installed and SNMP notifications are enabled.

The vulnerable path processes attacker-controlled input in a way that allows shell commands to reach the underlying operating system.

No authenticated Zimbra account is required.

The attacker sends a specially crafted SMTP request. When the relevant service-state event is processed, attacker-controlled data reaches the SNMP notification mechanism and eventually gets passed into a shell command.

The result is command execution as the zimbra service account.

That account isn’t root.

But it has enough access to make the next stage particularly unpleasant.

Attackers turned the first shell into a web shell

Microsoft observed attackers using the initial command execution to deploy JSP web shells into Zimbra’s application directories.

The attackers temporarily changed permissions on web-accessible directories, reconstructed encoded payloads and wrote the resulting JSP files into locations that could later be accessed through HTTP.

After deployment, the temporary staging material was removed.

This matters because the attacker doesn’t need to keep exploiting the original vulnerability once the web shell is installed.

The vulnerability becomes the entry point.

The web shell becomes the remote-control mechanism.

Microsoft also observed multiple copies of JSP web shells across Zimbra application and mailbox-server paths.

That gives attackers redundancy.

Kill one shell and another may still be alive.

Reverse shells were next

The attackers also used ordinary Linux utilities to establish interactive shells.

Tools such as curl, wget, Python and Perl were used to retrieve or execute additional payloads.

In some cases, attackers used an OpenSSL-based encrypted connection to maintain a reverse shell.

That is a useful reminder for defenders.

You don’t necessarily need a recognizable malware family to compromise a Linux mail server.

A shell, standard utilities and a network connection can be enough.

Microsoft explicitly noted that some of the most consequential activity involved no traditional malware at all.

Just commands.

Then they went for root

The Zimbra service account wasn’t the final target.

Microsoft observed a privilege-escalation chain involving legitimate Zimbra helper programs, writable log paths, PAM configuration and sudo-authorized components.

The attacker manipulated a writable Zimbra log path and used a symbolic link to redirect it toward the system’s PAM configuration.

A privileged Zimbra process could then modify that configuration.

The attackers added a PAM hook that executed a local script when a sudo session was triggered.

The end result was root-level access.

At that point, the original Zimbra vulnerability was almost irrelevant.

The attacker owned the operating system.

Persistence was built into the server

After obtaining elevated privileges, attackers didn’t simply leave.

Microsoft observed a malicious systemd service named zimlog.service.

The name was designed to look like a legitimate Zimbra logging component.

The service was installed under /etc/systemd/system/, enabled for automatic execution and given timestamps designed to resemble existing system services.

That is classic persistence with a little camouflage.

If an administrator simply checks running processes, the malicious service may not immediately stand out.

The attacker can reboot the machine and still get execution.

Zimbra credentials became the next prize

Once inside the server, attackers targeted Zimbra’s own configuration and authentication material.

Microsoft observed the use of:

zmlocalconfig -s

The command exposes local Zimbra configuration values, including service credentials.

Attackers then used recovered credentials for LDAP queries targeting sensitive attributes.

Among the targeted information were:

• zimbraPreAuthKey
• zimbraAuthTokenKey
• zimbraTwoFactorAuthSecret

Those aren’t random configuration values.

They can provide access to authentication mechanisms and internal Zimbra services.

A compromised mail server therefore becomes more than a place to send and receive email.

It becomes a credential store.

Mailbox data was targeted too

Microsoft observed attempts to access and collect mailbox information.

One observed implant specifically targeted Zimbra configuration credentials and mailbox-related data.

The malware accessed /opt/zimbra/conf/localconfig.xml and extracted multiple service credentials.

The same activity included database and LDAP access.

Attackers attempted to dump data from tables containing mailbox information, mobile-device data and other Zimbra records.

In other words:

The attacker gets shell access.

Then credentials.

Then LDAP.

Then database access.

Then mailbox data.

That’s a much bigger incident than “one RCE vulnerability.”

The vulnerability was patched before public disclosure

Zimbra released version 10.1.20 on July 20, 2026, containing the fix for CVE-2026-73570.

The vulnerability was publicly disclosed on August 13.

Microsoft says it observed probing activity between the release of the fix and public disclosure.

That means attackers were already looking for vulnerable systems during the window when administrators had a patch available but may not yet have known why it mattered.

This is exactly why internet-facing infrastructure needs a short patch window.

Waiting for a public exploit write-up is increasingly a bad strategy.

Who is actually exposed?

The vulnerability is not automatically exploitable against every Zimbra installation.

The attack path requires:

• Zimbra Collaboration Suite before the fixed release
• the optional zimbra-snmp package
• SNMP notifications enabled
• an internet-accessible attack path to the relevant mail infrastructure

That doesn’t make the issue harmless for installations that don’t meet all conditions.

It makes asset discovery important.

Administrators should verify whether zimbra-snmp is installed rather than assuming it isn’t being used.

What administrators should do now

Upgrade to Zimbra 10.1.20 or later.

That’s the primary fix.

If immediate patching isn’t possible, Microsoft recommends removing the optional zimbra-snmp package and disabling SNMP notifications.

Network exposure should also be reduced wherever possible.

But patching alone isn’t enough if the server may already have been compromised.

Check for:

• unexpected JSP files
• unknown systemd services
• suspicious cron entries
• unexpected changes under Zimbra web directories
• reverse-shell activity
• unusual outbound connections
• suspicious curl, wget, Python or Perl execution
• modifications to /etc/pam.d/
• unexpected sudo configuration
• new or modified SSH keys
• suspicious LDAP queries
• unexpected access to localconfig.xml

Also rotate sensitive Zimbra authentication material if compromise is confirmed or strongly suspected.

Don’t trust a clean malware scan

This is one of the most important lessons from Microsoft’s investigation.

Several stages of the attack used legitimate operating-system utilities.

An attacker doesn’t need to drop a spectacular Linux backdoor onto disk when they already have:

sh

curl

wget

perl

python

openssl

and the privileges required to use them.

A traditional malware scanner can miss an intrusion where the attacker mainly uses legitimate binaries and modifies configuration files.

For a compromised mail server, process history, authentication logs, network connections, file changes and persistence mechanisms can be more valuable than searching for a single malware hash.

Bugstoday opinion

This is exactly why internet-facing mail servers deserve a different patching mindset.

CVE-2026-73570 isn’t interesting because it has another scary vulnerability score.

It’s interesting because Microsoft has shown what happens after exploitation.

One unauthenticated command injection became a web shell.

The web shell became persistence.

Persistence became privilege escalation.

Root became credential theft.

Credential theft became mailbox access.

That’s the real severity.

A mail server is one of the worst places to discover that your patch cycle is measured in weeks instead of hours.

Today’s Bugs. Tomorrow’s Breaches.

Technical Sources

• Microsoft Threat Intelligence — “Unauthenticated command injection on internet-facing mail servers: tracking CVE-2026-73570”
• Zimbra Security Advisory — CVE-2026-73570
• NIST National Vulnerability Database — CVE-2026-73570
• CISA Known Exploited Vulnerabilities Catalog
• Zimbra Collaboration Suite Security Advisories