Zimbra Sicherheitslücke CVE-2026-73570 aktiv ausgenutzt

Die Zimbra Sicherheitslücke CVE-2026-73570 wird aktiv ausgenutzt. Was betroffen ist, warum Port 25 der Weg hinein ist und was Admins jetzt prüfen sollten.

Die Zimbra Sicherheitslücke CVE-2026-73570 wird aktiv ausgenutzt. CERT Polska hat am 17. August eine Warnung veröffentlicht, nachdem Angriffe auf Zimbra-Collaboration-Server beobachtet wurden. Der Patch liegt seit dem 20. Juli bereit. Wer ihn nicht eingespielt hat und das SNMP-Paket im Einsatz hat, ist derzeit angreifbar.

Was an der Zimbra Sicherheitslücke gefährlich ist

CVE-2026-73570 betrifft Zimbra Collaboration (ZCS) in allen Versionen vor 10.1.20. Der CNA MITRE bewertet die Lücke mit CVSS 8.9 und damit als „hoch”; die NVD hat noch keine eigene Bewertung vergeben und führt den Eintrag als „Awaiting Enrichment”.

Newsletter

Klartext ins Postfach

KI, Security & Crypto – die wichtigsten Analysen, kein Spam. Jederzeit abbestellbar.

Verwundbar bist du nur, wenn drei Dinge zusammenkommen: Das optionale Paket zimbra-snmp ist installiert, SNMP-Benachrichtigungen sind über den Parameter snmp_notify aktiviert, und der Dienst swatchdog läuft. Letzterer ist standardmäßig aktiv – das ist der Grund, warum die Kombination in der Praxis häufiger vorkommt, als es zunächst klingt.

Sind diese Bedingungen erfüllt, kann ein nicht angemeldeter Angreifer beliebige Betriebssystembefehle im Kontext des Benutzers zimbra ausführen. Ursache ist eine mangelhafte Bereinigung nicht vertrauenswürdiger Eingaben bei der Verarbeitung der SNMP-Benachrichtigung.

Der Angriff kommt über Port 25, nicht über SNMP

Ein Detail, das in vielen Meldungen untergeht: Der Fehler steckt zwar in der SNMP-Verarbeitung, ausgelöst wird er laut NVD-Beschreibung aber über präparierte SMTP-Anfragen. Die Kette läuft also so: Angreiferdaten landen per Mail-Zustellung im Log, swatchdog liest dieses Log, stößt daraufhin die SNMP-Benachrichtigung an – und dabei wird die Nutzlast ausgeführt.

Für die Praxis ist das entscheidend. Der Weg hinein führt über Port 25, den jeder Mailserver zwangsläufig offen im Internet hat. Wer SNMP lediglich per Firewall abschottet und sich deshalb sicher fühlt, ist nicht geschützt.

Der Patch ist alt, die Angriffe sind neu

Zimbra hat die Schwachstelle bereits am 20. Juli mit Version 10.1.20 dauerhaft geschlossen; ein erstes Advisory dazu stammt vom 26. Juni. Neu ist nicht die Lücke, sondern dass sie jetzt in freier Wildbahn benutzt wird. Genau dieses Muster kennen wir aus vielen Fällen – zuletzt bei der SharePoint-Lücke CVE-2026-55040, wo der Patch ebenfalls seit Juli bereitlag.

Was das für dich bedeutet

Aus CISO-Sicht ist das der unangenehmste Fall überhaupt: Es gibt keine Ausrede. Kein Zero-Day, keine fehlende Herstellerreaktion, kein Workaround-Gebastel. Seit dem Patch waren es rund vier Wochen, seit dem ersten Advisory sogar rund sieben. Wer diese Zeit nicht genutzt hat, hat ein Patchmanagement-Problem – kein Zimbra-Problem.

Der zweite Punkt trifft besonders kleinere Betriebe und Vereine. Zimbra läuft oft dort, wo bewusst kein Microsoft 365 gewollt ist: selbst gehostet, gewachsen, vom Dienstleister vor Jahren aufgesetzt und seitdem kaum angefasst. Genau solche Systeme haben das SNMP-Paket häufig aus Monitoring-Gründen installiert und niemanden, der Advisories liest.

Und der Mailserver ist kein beliebiger Dienst. Wer dort Code ausführen kann, liest mit, fälscht Absender und greift Passwort-Reset-Mails ab. Damit hat er einen Hebel auf sämtliche anderen Konten. Ein kompromittierter Mailserver ist deshalb praktisch immer ein Identitätsproblem, nicht bloß ein Serverproblem.

Was jetzt konkret zu tun ist

Version prüfen. Alles unterhalb von 10.1.20 gilt als verwundbar. Update auf 10.1.20 oder neuer, ohne lange Wartungsfenster-Diskussion.
Angriffsfläche verkleinern. Brauchst du zimbra-snmp überhaupt? Wenn das Monitoring längst über einen anderen Weg läuft, gehört das Paket deinstalliert. Alternativ deaktivierst du zumindest snmp_notify.
Auf Kompromittierung prüfen. CERT Polska nennt konkrete Anhaltspunkte: In /var/log/zimbra.log tauchen Zeilen der Form Service status change: <Nutzlast> changed from stopped to running auf – der Schadcode steht also direkt im Logeintrag. Zusätzlich prüfst du Dateien, die in den letzten 30 Tagen vom Benutzer zimbra in /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ oder /tmp/ angelegt wurden.
Nicht nur patchen, auch nachsehen. Ein Patch schließt die Tür – er wirft niemanden hinaus, der schon drin ist. Findest du Auffälligkeiten, ist das ein Incident und keine Wartungsaufgabe.
Wiederherstellung vorbereiten. Ein sauberes, offline gehaltenes Backup ist bei einem RCE auf dem Mailserver der Unterschied zwischen einem langen Wochenende und einem Totalverlust. Wie du Sicherungen und sensible Daten sinnvoll verschlüsselt ablegst, habe ich im Ratgeber zu verschlüsselten USB-Sticks und externen SSDs beschrieben.

Zimbra bleibt ein beliebtes Ziel

Diese Lücke ist kein Ausrutscher. Zimbra-Server stehen seit Jahren im Fokus staatsnaher Gruppen – dokumentiert sind unter anderem Kampagnen von Winter Vivern, APT29 und APT28 gegen Regierungs- und NATO-nahe Postfächer. Der Grund ist simpel: Mailserver liefern Kommunikation, und sie sind oft schlecht gepflegt.

Das Shadowserver-Projekt zählt derzeit über 12.100 im Internet erreichbare Zimbra-Server, davon rund 4.400 in Europa. Wie viele davon tatsächlich verwundbar konfiguriert oder längst gepatcht sind, lässt sich von außen nicht sagen – die Größenordnung zeigt aber, wie breit die Angriffsfläche ist. Wenn du Zimbra betreibst, gehört es auf die Liste der Systeme, deren Advisories du aktiv verfolgst, statt sie im Jahresrhythmus zu aktualisieren.

Quellen

Dranbleiben

Diese Analysen als Newsletter

Ein Mal pro Woche Klartext zu KI, Security & Crypto – direkt in dein Postfach.

Jetzt anmelden