CVE-2026-73570: Zimbra Command Injection über SNMP wird ausgenutzt - Update auf 10.1.20 und Prüfung auf Kompromittierung

In Zimbra Collaboration (ZCS) vor Version 10.1.20 kann ein Angreifer ohne Anmeldung Betriebssystembefehle mit den Rechten des Benutzers zimbra ausführen, wenn das optionale Paket zimbra-snmp installiert und SNMP-Benachrichtigungen aktiviert sind. Auslöser ist eine präparierte SMTP-Anfrage, also eine E-Mail an den Server, deren Inhalte ungefiltert in die Verarbeitung der SNMP-Benachrichtigungen gelangen. Die Lücke trägt die Kennung CVE-2026-73570 und eine CVSS-Bewertung von 8.9. Zimbra hat sie am 26. Juni 2026 gemeldet und am 20. Juli 2026 mit Version 10.1.20 behoben. CERT Polska hat am 17. August 2026 vor einer laufenden Angriffskampagne gewarnt; die US-Behörde CISA hat die Lücke am 21. August 2026 in ihren Katalog ausgenutzter Schwachstellen (KEV) aufgenommen. Das Update ist verfügbar.

Das Wichtigste in Kürze

Betroffene Versionen und Updates

Betroffen sind nur Installationen, auf denen zimbra-snmp installiert ist und SNMP-Benachrichtigungen aktiviert sind. Laut CERT Polska läuft der Dienst swatchdog, der die Benachrichtigungen verarbeitet, standardmässig. Ohne zimbra-snmp ist ein Server laut Advisory-Beschreibung nicht über diesen Weg angreifbar; das Update auf 10.1.20 behebt daneben weitere Lücken (XSS im Classic Web Client, Umgehung von Weiterleitungsbeschränkungen, SSRF in der Nextcloud-Integration, Zugriffskontrollen in EWS und bei der Postfach-Delegation) und ist deshalb auch ohne SNMP sinnvoll.

Die installierte Version zeigt zmcontrol -v als Benutzer zimbra (Release-Nummer, Build, Plattform, Build-Datum laut Zimbra-Wiki):

su - zimbra
zmcontrol -v

Ob die verwundbare Konfiguration aktiv ist, lässt sich nach der Analyse von SecureLayer7 so prüfen:

su - zimbra
zmlocalconfig snmp_notify
zmswatchctl status
grep dosnmp /opt/zimbra/conf/swatchrc

Sind snmp_notify auf true und swatchdog aktiv, ist der Server auf einer Version vor 10.1.20 angreifbar.

Was über die Ausnutzung bekannt ist

Microsoft beschreibt den Ablauf so: swatchdog überwacht /var/log/zimbra.log und löst bei Statuswechseln von Diensten einen SNMP-Trap aus. Über eine präparierte SMTP-Anfrage gelangen Shell-Metazeichen in diese Verarbeitung; bei einem Statuswechsel übernimmt swatchdog den vom Angreifer kontrollierten Wert in einen Aufruf von snmptrap, der über eine Shell läuft. Die Befehle laufen mit den Rechten des Dienstkontos zimbra.

Chronologie laut den Quellen:

1. 26. Juni 2026: Zimbra meldet die Lücke in einem Security Advisory mit einer temporären Massnahme.

2. 20. Juli 2026: ZCS 10.1.20 erscheint mit dem dauerhaften Fix.

3. 28. Juli bis 7. August 2026: Microsoft beobachtet Sondierungen der Injektionsstelle mit zwei unterschiedlichen Werkzeugen.

4. 13. August 2026: Der CVE-Eintrag wird veröffentlicht.

5. 17. August 2026: CERT Polska warnt vor einer laufenden Kampagne und veröffentlicht Prüfhinweise.

6. 21. August 2026: CISA nimmt die Lücke in den KEV-Katalog auf, mit Frist bis zum 24. August 2026.

7. 30. September 2026: Microsoft veröffentlicht eine Analyse der Angriffe mit Indikatoren.

Laut Help Net Security zählte die Shadowserver Foundation am 20. August 2026 155 kompromittierte Zimbra-Instanzen im Internet, wenige Tage später 274. Mehr als 8200 Instanzen waren zu diesem Zeitpunkt nicht aktualisiert, wobei nicht alle die verwundbare SNMP-Konfiguration haben.

Nach der Ausnutzung haben die Angreifer laut Microsoft JSP-Webshells in mehreren Verzeichnissen von Jetty und mailboxd abgelegt, Persistenz über einen systemd-Dienst, Cron-Einträge und SSH-Schlüssel eingerichtet und über eine Manipulation der PAM-Konfiguration Root-Rechte erlangt. Sie haben mit zmlocalconfig -s Zugangsdaten ausgelesen, per LDAP die Attribute zimbraPreAuthKey, zimbraAuthTokenKey und zimbraTwoFactorAuthSecret abgefragt, den Mail-Store mit tar archiviert und einen Abfluss über AzCopy nach Azure Blob Storage versucht; ob die Übertragung abgeschlossen wurde, ist laut Microsoft nicht bestätigt. Microsoft nennt ausserdem einen Coin-Miner. Wer hinter den Angriffen steht, ist nicht bekannt.

Sofortmassnahmen

1. Version und Konfiguration feststellen mit zmcontrol -v, zmlocalconfig snmp_notify und zmswatchctl status (siehe oben).

2. Vor Änderungen auf Kompromittierung prüfen und Logs sichern, damit eine Auswertung möglich bleibt (siehe nächster Abschnitt).

3. Auf ZCS 10.1.20 oder neuer aktualisieren. Das empfehlen Zimbra, CERT Polska, CISA und Microsoft übereinstimmend. Installationen auf älteren Zweigen müssen auf 10.1.20 oder neuer wechseln.

4. Bis zum Update den Workaround umsetzen: Microsoft empfiehlt, das Paket zimbra-snmp zu deinstallieren oder die SNMP-Benachrichtigungen abzuschalten. Die Befehle dafür stehen unterhalb dieser Liste.

5. Exponierung reduzieren: SNMP und SMTP laut Microsoft auf vertrauenswürdige Hosts beschränken, soweit der Mailbetrieb das zulässt. Auf einem MTA mit Mailempfang aus dem Internet bleibt SMTP erreichbar; dort sind Update oder Workaround die wirksamen Massnahmen.

Für das Abschalten der SNMP-Benachrichtigungen nennt SecureLayer7 folgende Befehle als Benutzer zimbra:

zmlocalconfig -e snmp_notify=false
zmswatchctl stop

Danach fehlen SNMP-Traps bei Dienstausfällen; die Überwachung sollte bis zum Update auf anderem Weg erfolgen.

Prüfung auf Kompromittierung

Die Lücke wurde vor dem Update vieler Systeme ausgenutzt. Ein Update auf 10.1.20 schliesst den Angriffsweg, entfernt aber keine bereits abgelegten Webshells, systemd-Dienste oder SSH-Schlüssel. Microsoft empfiehlt ausdrücklich, nach redundanter Persistenz zu suchen und die Authentifizierungsschlüssel von Zimbra zu wechseln.

Logs und Verzeichnisse nach CERT Polska

CERT Polska nennt zwei Prüfungen:

1. /var/log/zimbra.log auf Einträge der Form Service status change: [Payload] changed from stopped to running bzw. changed from running to stopped, bei denen an der Stelle des Dienstnamens auffällige Zeichenfolgen stehen.

2. Dateien, die der Benutzer zimbra in den letzten 30 Tagen angelegt hat, in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ und /tmp/. Hive Security nennt dafür:

find /opt/zimbra/jetty/webapps /opt/zimbra/jetty_base/webapps /tmp -user zimbra -mtime -30 -ls

Da die Angriffe laut Microsoft bereits Ende Juli begannen, kann ein längerer Zeitraum als 30 Tage sinnvoll sein.

Weitere Spuren nach Microsoft

Netzwerk-Indikatoren

Die Adressen sind wie in der Microsoft-Analyse entschärft geschrieben.

Datei-Hashes (SHA-256)

Bei einem Fund

Ein Treffer bedeutet, dass das System als kompromittiert gilt. Sichern Sie Logs und betroffene Dateien, bevor Sie etwas löschen. Weil die Angreifer laut Microsoft Root-Rechte erlangt und Persistenz an mehreren Stellen eingerichtet haben, ist ein Neuaufbau auf 10.1.20 oder neuer sicherer als das Entfernen einzelner Dateien. Danach sind die ausgelesenen Geheimnisse zu wechseln: die Werte aus zmlocalconfig -s (unter anderem LDAP- und Datenbank-Passwörter), zimbraPreAuthKey, zimbraAuthTokenKey und die SSH-Schlüssel des Benutzers zimbra. Laut Microsoft wurde auch zimbraTwoFactorAuthSecret abgefragt; die Zwei-Faktor-Registrierungen der Benutzer sollten deshalb neu eingerichtet werden. Bei Multi-Server-Installationen gilt die Prüfung für alle Knoten, da die Angreifer laut Microsoft mit zmprov Mailbox- und MTA-Server ermittelt und den SSH-Schlüssel für Bewegungen zwischen den Servern genutzt haben.

Einordnung

Betroffen sind Organisationen, die Zimbra als eigenen Mailserver betreiben und Mail direkt aus dem Internet annehmen. Die Lücke ist über den regulären Mailempfang erreichbar, ohne Anmeldung und ohne Zutun eines Benutzers. Die Einschränkung auf zimbra-snmp mit aktiven Benachrichtigungen reduziert die Zahl der angreifbaren Systeme; wer SNMP-Überwachung eingerichtet hat, ist aber genau in dieser Konfiguration. Laut SecurityWeek führt CISA im KEV-Katalog 18 Zimbra-Lücken, vier davon aus dem Jahr 2026; frühere Kampagnen gegen Zimbra wurden staatlich unterstützten Gruppen und finanziell motivierten Kriminellen zugeordnet. CERT-FR hat die Lücke am 19. August 2026 zusammen mit drei weiteren in Zimbra behobenen CVEs gemeldet. Eine Meldung des NCSC Schweiz zu CVE-2026-73570 lag bei der Recherche nicht vor.