274 Zimbra-Server kompromittiert – der Patch war längst verfügbar

Am 26. August 2026 wurde öffentlich, dass mindestens 274 über das Internet erreichbare Zimbra-Instanzen Kompromittierungsspuren im Zusammenhang mit CVE-2026-73570 aufweisen. Wie der Bericht von IT Pro festhält, war die Schwachstelle bereits mit Zimbra Collaboration 10.1.20 vom 20. Juli behoben worden.

Betroffen sind ältere Installationen nur unter bestimmten Bedingungen: Das optionale Paket zimbra-snmp muss installiert und die SNMP-Benachrichtigung aktiviert sein. Betreiber solcher Systeme müssen deshalb auf Version 10.1.20 oder neuer aktualisieren und zugleich untersuchen, ob ihr zuvor erreichbarer Server bereits angegriffen wurde. Der neue Versionsstand beantwortet diese zweite Frage nicht.

Welche Zimbra-Systeme angreifbar sind

CVE-2026-73570 betrifft Zimbra Collaboration vor Version 10.1.20, sofern zimbra-snmp installiert ist und SNMP-Benachrichtigungen eingeschaltet sind. Damit ist weder jeder ungepatchte Zimbra-Server automatisch über diese Lücke ausnutzbar noch jede aktuelle Installation sicher, falls das Update erst nach einem möglichen Angriff eingespielt wurde.

Der NVD-Eintrag zu CVE-2026-73570 beschreibt eine unzureichende Bereinigung nicht vertrauenswürdiger Eingaben bei der Verarbeitung der Benachrichtigungen. Ein Angreifer kann ohne vorherige Anmeldung speziell präparierte SMTP-Anfragen senden und dadurch Betriebssystembefehle mit den Rechten des Zimbra-Benutzers ausführen. Die NVD nennt Versionen vor 10.1.20 als betroffen und führt die Schwachstelle im Katalog aktiv ausgenutzter Sicherheitslücken.

Die entscheidende Prüfung besteht daher aus mehreren Angaben, die zusammengehören: installierte Zimbra-Version, Vorhandensein des optionalen SNMP-Pakets und Status der Benachrichtigungsfunktion. Eine reine Versionsinventur zeigt den Patchbedarf, erfasst aber nicht vollständig, welche Server während des verwundbaren Zeitraums tatsächlich angreifbar waren.

Was die Zahl 274 tatsächlich bezeichnet

Die 274 gezählten Instanzen sind nicht einfach alle gefundenen Zimbra-Server mit einer alten Version. Shadowserver ordnete sie anhand aus der Ferne erkannter Artefakte als kompromittiert ein. Das ist eine engere Kategorie als „erreichbar“, „ungepatcht“ oder „potenziell verwundbar“.

Diese Abgrenzung ist für die Reaktion wesentlich. Bei einem ungepatchten, aber nicht nachweislich angegriffenen System steht zunächst das Schließen der Schwachstelle im Vordergrund. Werden hingegen Kompromittierungsspuren gefunden, liegt ein Sicherheitsvorfall vor: Der Angreifer konnte bereits Befehle als Zimbra-Benutzer ausführen und damit Dateien oder andere für dieses Konto zugängliche Bestandteile des Systems verändern.

Der zeitliche Abstand bestätigt den zweiten Teil des Titels. Zwischen der Veröffentlichung von Version 10.1.20 am 20. Juli und dem Bericht über mindestens 274 kompromittierte Instanzen am 26. August lagen mehr als fünf Wochen. Die beobachteten Einbrüche entstanden somit nicht in einem Zeitraum ohne verfügbaren Fix, sondern während eine bereinigte Version bereits bereitstand.

Welche Spuren Betreiber prüfen sollten

CERT Polska warnte am 17. August vor aktiver Ausnutzung. Die technische Meldung von CERT Polska nennt den Parameter snmp_notify und den laufenden Dienst swatchdog als relevante Bedingungen und führt konkrete lokale Prüfstellen auf.

• Konfiguration erfassen: Feststellen, ob zimbra-snmp installiert, snmp_notify aktiviert und swatchdog in Betrieb ist.
• Patchstand korrigieren: Eine betroffene Installation auf Zimbra Collaboration 10.1.20 oder eine neuere bereinigte Version aktualisieren.
• Frühere Exposition bestimmen: Klären, in welchem Zeitraum der verwundbare SMTP-Dienst aus dem Internet erreichbar war.
• Protokolle kontrollieren: In /var/log/zimbra.log nach unerwarteten Einträgen zu Statuswechseln suchen, deren Inhalt eine verdächtige Nutzlast erkennen lässt.
• Neue Dateien untersuchen: Vom Benutzer zimbra innerhalb der vergangenen 30 Tage angelegte Dateien unter /opt/zimbra/jetty/webapps/, /opt/zimbra/jetty_base/webapps/ und /tmp/ prüfen.

Externe Erreichbarkeit allein beweist keinen erfolgreichen Angriff. Umgekehrt kann eine unauffällige Prüfung von außen einen Vorfall nicht sicher ausschließen, weil lokal hinterlassene oder später entfernte Artefakte dabei unsichtbar bleiben können. Für zuvor exponierte Systeme ist deshalb die Untersuchung auf dem Host aussagekräftiger als eine bloße erneute Fernabfrage.

Warum das Update keine abgeschlossene Bereinigung belegt

Version 10.1.20 oder neuer verhindert die beschriebene Befehlsinjektion über den SNMP-Mechanismus. Das Update stellt jedoch nicht rückwirkend fest, ob vor seiner Installation bereits Befehle ausgeführt oder Dateien angelegt wurden. Patchen und Vorfallsanalyse beantworten damit zwei unterschiedliche Fragen.

Findet die Untersuchung belastbare Angriffsspuren, sollte das System als kompromittiert behandelt werden. Dann sind der Zeitraum und die Reichweite des Zugriffs zu bestimmen; ebenso müssen Veränderungen in den Bereichen bewertet werden, auf die der Zimbra-Benutzer zugreifen konnte. Erst diese Analyse zeigt, ob eine Aktualisierung genügt oder eine kontrollierte Wiederherstellung und der Austausch betroffener Zugangsdaten erforderlich sind.

Bestätigt sind derzeit die aktive Ausnutzung, mindestens 274 von Shadowserver erkannte Instanzen mit Kompromittierungsartefakten und die Verfügbarkeit des Fixes seit dem 20. Juli. Nicht bekannt ist, wer hinter den Angriffen steht und wie viele weitere Systeme betroffen sind, ohne aus der Ferne erkennbare Spuren zu zeigen. Die öffentlich sichtbare Zahl markiert deshalb eine bestätigte Untergrenze, nicht den abschließenden Umfang des Vorfalls.