/
← Voltar ao feed
critical

Zimbra CVE-2026-73570: unauthenticated zero-click command injection via Swatchdog/SNMP exploited to take over email servers

2 fonte(s) · 2 atualização(ões) · publicado 20/10/2026 05:52 · coletado há 14 horas

Matéria consolidada. Reúne 2 matérias que o Tifon tinha publicado separadamente sobre a mesma história. A IA reescreveu o relatório com o que as 2 fontes trouxeram em 24/10/2026 00:05; os links antigos trazem para cá.

Fontes: elastic.co ↗ gbhackers.com ↗

CVE-2026-73570 is an unauthenticated command injection flaw in Zimbra Collaboration Suite that gives remote code execution as the zimbra service account through a single malformed SMTP recipient address. Microsoft Threat Intelligence, as relayed by gbhackers.com, reports active exploitation against internet-facing mail servers in several regions and industries. Attackers deployed webshells, escalated privileges, stole authentication secrets and staged mailbox data. Zimbra fixed the flaw in version 10.1.20 on July 20, 2026. Exploitation probing was seen between July 28 and August 7, before public disclosure on August 13 (gbhackers.com). Elastic Security Labs later reproduced the bug and published a detection rule (elastic.co, October 23). Its article does not itself report in-the-wild exploitation. Because the zimbra account can read every mailbox and send as any local identity, a compromised server also compromises the identities it serves (elastic.co).

Entenda a falha

A vulnerabilidade

CVE-2026-73570 is an unauthenticated command injection in Zimbra Collaboration Suite, in the Swatchdog monitoring daemon that Zimbra bundles. It only works when the optional zimbra-snmp package is installed and SNMP notifications are enabled. An attacker needs only SMTP reach to the server and one malformed recipient address, with no credentials or user interaction. They get remote code execution as the zimbra account, which can read every mailbox and send as any local identity. Versions before 10.1.20 are affected, and 10.1.20 (released July 20, 2026) fixes it. Microsoft Threat Intelligence, as relayed by gbhackers.com, reports active exploitation.

Como funciona

The attacker sends an SMTP RCPT TO whose address is not closed with the final angle bracket. Postfix rejects it and logs an Illegal address syntax warning to /var/log/zimbra.log, echoing the attacker-controlled text. Swatchdog tails that log and matches lines that look like a Zimbra service status change. If the injected text imitates such a line, Swatchdog calls its SNMP notification routine, which builds a command to send an snmptrap and includes the service name taken from the log line. That command runs through /bin/sh, so shell syntax hidden in the service field is executed.

Por que é vulnerável

The root cause is unsafe construction of a shell command from untrusted data. The service name taken from the log line is interpolated directly into a backticked Perl string without validation or escaping. The log is also trusted as if only Zimbra's own components wrote to it, yet Postfix copies fragments of what any SMTP client sent into it. The articles do not describe the details of the fix beyond saying that 10.1.20 resolves the issue.

Onde está

Elastic points to /opt/zimbra/conf/swatchrc.in, which Swatchdog compiles into a Perl script, specifically the dosnmp function (line 26 in build 10.1.16 Ubuntu 24 FOSS), where $args{SERVICE} goes into the backticked command; the log source is /var/log/zimbra.log.

Como foi descoberta

The articles do not say who first found or reported the flaw. Zimbra fixed it in 10.1.20 on July 20, 2026, and it was publicly disclosed on August 13. Microsoft Threat Intelligence, per gbhackers.com, saw probing of the injection vector between July 28 and August 7, after the patch but before disclosure, followed by webshells, privilege escalation, theft of authentication secrets and staging of mailbox data. Elastic Security Labs reproduced the bug while building detections and published its analysis on October 23; its article does not itself report exploitation in the wild.

PoC pública

Elastic says several public PoCs exist, but many write a line to the log that Swatchdog never matches, so a failed test can wrongly look like a patched server. Elastic built its own PoC, which runs several commands and confirmed code execution as the zimbra user through an out-of-band callback, leaving no on-disk changes. The chain is working and reproducible, and Microsoft reports real attacks, so treat unpatched servers with SNMP notifications as exposed and patch to 10.1.20 rather than relying on a failed public PoC test.

Publicada em: www.elastic.co/security-labs/threat-command/command-injection-zimbra-cve-2026-73570 ↗

Explicação gerada por IA a partir da matéria e dos artigos, em 24/10/2026 00:20.

Detalhes técnicos

  • Precondition: the optional zimbra-snmp package is installed and SNMP notifications are enabled (gbhackers.com, elastic.co).
  • Root cause: the attacker sends an SMTP RCPT TO with an unclosed address (missing the final >). Postfix logs it in /var/log/zimbra.log as an "Illegal address syntax" warning. The address embeds a line matching Service status change: <host> <service> changed from stopped to running, with the service field replaced by a shell substitution such as $(touch /tmp/manual_test.txt) (elastic.co).
  • The Swatchdog daemon, a Perl program bundled with Zimbra, tails the log and compiles /opt/zimbra/conf/swatchrc.in into a Perl script. The dosnmp function interpolates $args{SERVICE} into a backticked string run via /bin/sh, which calls snmptrap. Elastic cites line 26 of the 10.1.16 Ubuntu 24 FOSS build (elastic.co).
  • Reproduction: Elastic's PoC confirmed execution with an out-of-band callback returning uid=997(zimbra) and left no on-disk changes. Several public PoCs write a payload that Swatchdog never matches, so a failed test can look like a patched server (elastic.co).
  • Validation by attackers: HTTP, DNS and ICMP callbacks to interaction services with randomized subdomains. Some HTTP probes carried the ZB73570 User-Agent (gbhackers.com).
  • Post-exploitation: encoded payloads were reconstructed and JSP webshells placed in Jetty and mailboxd directories. Webroot permissions were temporarily altered and then restored to evade basic checks. Other activity included script downloads, reverse shells and in-memory command execution (gbhackers.com).
  • Privilege escalation: abuse of legitimate Zimbra service helpers, a writable mailbox-manager log directory and the sudo PAM configuration. A pam_exec hook gave passwordless sudo, after which the configuration was restored (gbhackers.com).
  • Persistence and lateral movement: a disguised systemd unit, zimlog.service, sits outside the Zimbra directories with modified timestamps and runs at boot. Zimbra's SSH identity and rsync were reused to spread tools and webshells to trusted cluster nodes (gbhackers.com).
  • Payload chain: the Go-based zimdown2 installer and the zimclient2 remote-access agent. zimclient2 supports interactive shells, file transfer, SOCKS5 proxying and WebSocket, TLS or raw TCP communication (gbhackers.com).
  • Credential and data theft: targeted zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret in LDAP, plus certificates, private keys, configuration files and database content. Stolen token-signing material could allow account impersonation without passwords. Mailbox backups were archived, and an AzCopy transfer to an Azure Blob destination was attempted but failed (gbhackers.com).
  • Individual hosts may not show every stage of the chain (gbhackers.com).
  • Detection: the Elastic rule "Zimbra Swatchdog SNMP Command Injection Execution" is an EQL sequence. A shell spawned by a Perl .swatchdog_script parent with snmptrap, zmservicename and zmservicestatus in its command line is followed by a child of that shell other than snmptrap (elastic.co).

Remediação

  • Upgrade to Zimbra 10.1.20 or later, the only complete fix (elastic.co, gbhackers.com).
  • If patching is not immediately possible, remove the zimbra-snmp package and disable SNMP notifications (gbhackers.com).
  • Investigate reverse-shell alerts and inspect all mailbox nodes for redundant JSP webshells (gbhackers.com). The source text is truncated after this point, so further guidance is not captured here.
  • Deploy Elastic Defend with the Swatchdog rule, including retroactive hunting for pre-patch attempts (elastic.co).
  • On suspected compromise, hunt for standard RCE indicators, phishing emails originating from the server, compromise of local databases, signing keys and LDAP exports, and indirect surfaces beyond the mail store (elastic.co). Also check for zimlog.service, zimdown2 and zimclient2 (gbhackers.com).

Relatos divergentes

  • Exploitation status: gbhackers.com, citing Microsoft Threat Intelligence, reports active in-the-wild exploitation. elastic.co, the more recent source (October 23), does not report in-the-wild exploitation, but it focuses on reproduction and detection and does not contradict the Microsoft findings.

Linha do tempo

  1. elastic.co ↗ · pub. 22/10/2026 21:00 · coletado 23/10 12:00

    Zimbra CVE-2026-73570: unauthenticated command injection via Swatchdog/SNMP log injection allows RCE; fixed in 10.1.20

    ler a análise desta fonte

    Elastic Security Labs reproduced CVE-2026-73570, an unauthenticated command injection flaw in Zimbra that leads to remote code execution as the zimbra user through one malformed SMTP recipient address. The zimbra account can read every mailbox and send as any local identity, so a compromised mail server also compromises the identities it serves. Elastic found that several public PoCs write a payload that Swatchdog never matches, so a failed test can look like a patched server. The flaw is fixed in Zimbra 10.1.20. The article does not report in-the-wild exploitation.

    Technical Details

    • An attacker sends an SMTP RCPT TO with an unclosed address (missing the final >). Postfix logs it to /var/log/zimbra.log as an "Illegal address syntax" warning.
    • The crafted address embeds a line matching the pattern Service status change: <host> <service> changed from stopped to running, with the service field replaced by a shell substitution such as $(touch /tmp/manual_test.txt).
    • The Swatchdog daemon, a Perl program bundled with Zimbra, tails the log and compiles /opt/zimbra/conf/swatchrc.in into a Perl script. When SNMP notifications are enabled, the dosnmp function interpolates $args{SERVICE} into a backticked string that is executed via /bin/sh. Elastic cites line 26 of the 10.1.16 Ubuntu 24 FOSS build.
    • Elastic's PoC confirmed execution with an out-of-band callback, returning uid=997(zimbra), with no on-disk changes on the target.
    • Detection: the Elastic rule "Zimbra Swatchdog SNMP Command Injection Execution" is an EQL sequence. A shell spawned by a Perl .swatchdog_script parent with snmptrap, zmservicename and zmservicestatus in its command line is followed by a child of that shell other than snmptrap.

    Remediation

    • Upgrade to Zimbra 10.1.20 or later, which is the only complete fix.
    • Deploy Elastic Defend and enable the Swatchdog detection rule, including to hunt retroactively for pre-patch attempts.
    • On suspected compromise, hunt for standard indicators of RCE, phishing emails originating from the server, compromise of local databases, signing keys and LDAP exports, and less direct surfaces beyond the mail store.
  2. gbhackers.com ↗ · pub. 20/10/2026 05:52 · coletado 20/10 07:00 primeiro registro

    Zimbra Collaboration Suite zero-click command injection CVE-2026-73570 exploited to take over email servers

    ler a análise desta fonte

    Microsoft Threat Intelligence reports active exploitation of CVE-2026-73570, a command injection flaw in Zimbra Collaboration Suite that allows unauthenticated, zero-click compromise of internet-facing email servers. Attackers deployed webshells, escalated privileges, harvested authentication secrets and staged mailbox data across organizations in various regions and industries. Probing of the injection vector was observed between July 28 and August 7, after Zimbra released the fix in version 10.1.20 on July 20, 2026 but before public disclosure on August 13. The activity included a persistent zimlog.service unit, the Go-based zimdown2 and zimclient2 tools, and an attempted exfiltration of mailbox backups to Azure Blob storage.

    Technical Details

    • Precondition: the optional zimbra-snmp package is installed and SNMP notifications are enabled. A crafted email with shell metacharacters in attacker-controlled SMTP input reaches SNMP notification processing. The swatchdog utility passes it into an snmptrap shell invocation, executing commands as the Zimbra service account.
    • Validation: HTTP, DNS and ICMP callbacks to interaction services, with randomized subdomains. Some HTTP probes carried the ZB73570 User-Agent.
    • Post-exploitation: encoded payloads reconstructed and JSP webshells placed in Jetty and mailboxd directories. Webroot permissions were temporarily altered and then restored to evade basic permission checks. Other activity included script downloads, reverse shells and in-memory command execution.
    • Privilege escalation: abuse of legitimate Zimbra service helpers, a writable mailbox-manager log directory and the sudo PAM configuration. A pam_exec hook was used for passwordless sudo, after which the configuration was restored.
    • Persistence and lateral movement: disguised systemd unit zimlog.service outside Zimbra directories with modified timestamps and boot execution. Zimbra's SSH identity and rsync were reused to spread tools and webshells to trusted cluster nodes.
    • Payload chain: Go-based zimdown2 installer and zimclient2 remote-access agent supporting interactive shells, file transfer, SOCKS5 proxying and WebSocket, TLS or raw TCP communication.
    • Credential and data theft: targeted zimbraPreAuthKey, zimbraAuthTokenKey and zimbraTwoFactorAuthSecret in LDAP, plus certificates, private keys, configuration files and database content. Stolen token-signing material could enable account impersonation without passwords. Mailbox backups were archived and an AzCopy transfer to an Azure Blob destination was attempted but failed.
    • Individual hosts may not show every stage of the chain.

    Remediation

    • Upgrade to Zimbra 10.1.20 or later.
    • If patching is not immediately possible, remove the zimbra-snmp package and disable SNMP notifications.
    • Investigate reverse-shell alerts and inspect all mailbox nodes for redundant JSP webshells.
    • Review unexpected systemd services and sudo/PAM changes.
    • Rotate Zimbra authentication secrets.