Zimbra-Zero-Click: Laundry Bear liest E-Mails ohne Klick mit

Eine E-Mail kommt an, wird im Zimbra-Postfach angezeigt – und schon läuft im Hintergrund Schadcode. Kein Klick, kein Download, kein Moment der Unachtsamkeit nötig. Genau dieses Szenario beschreiben CISA und internationale Partnerbehörden in ihrem Advisory AA26-204A, veröffentlicht am 23. und 24. Juli 2026: Die als Laundry Bear bekannte Gruppe nutzt eine Zimbra-Schwachstelle, um in Mailserver von Behörden, Energieversorgern und Medienhäusern einzudringen. Für die Betroffenen bedeutet das: E-Mail-Spionage, die niemand anklicken musste.

Wichtig zum Verständnis: Die Lücke selbst ist nicht neu. CVE-2025-66376 steht seit März 2026 im Known Exploited Vulnerabilities Catalog der CISA, Patches gibt es seit den Zimbra-Releases 10.0.18 und 10.1.13. Neu ist die behördenübergreifende Warnung mit konkretem Kampagnenkontext, Zuordnung zu einem staatsnahen Akteur und Indicators of Compromise. Wer die Lücke bislang für erledigt hielt, weil der Patch schon länger draußen ist, bekommt jetzt den Beweis, dass sie munter weiter ausgenutzt wird.

Was CVE-2025-66376 technisch anrichtet

Die Schwachstelle sitzt im Classic UI von Zimbra Collaboration und ist eine gespeicherte Cross-Site-Scripting-Lücke. Der Auslöser: CSS-@import-Direktiven in HTML-E-Mails. Klingt nach Detail-Nerdkram, ist aber der Kern des Problems. Zimbra rendert HTML-Mails im Webinterface, und wenn dabei CSS-Importe unzureichend gefiltert werden, kann eingeschleuster Code im Kontext der Anwendung ausgeführt werden. Betroffen sind laut NVD-Eintrag zu CVE-2025-66376 die Versionen Zimbra Collaboration 10 vor 10.0.18 sowie 10.1 vor 10.1.13.

Bei der Bewertung lohnt ein genauer Blick, weil zwei Institutionen zu unterschiedlichen Ergebnissen kommen. MITRE vergibt einen CVSS-Wert von 7.2 und stuft die Lücke damit als High ein – ausdrücklich ohne dass eine Nutzerinteraktion erforderlich wäre. NVD setzt eigenständig 6.1 an. Beide Werte beziehen sich auf dieselbe Lücke, sollten aber nicht vermischt werden, weil sie unterschiedliche Bewertungsmodelle nutzen. Für die Praxis zählt ohnehin weniger die Dezimalstelle als die Tatsache: Eine gespeicherte XSS-Lücke im Mail-Client, die ohne Klick auslöst, ist ein ernstes Einfallstor in Mailserver-Umgebungen.

Technisch betrachtet ist gespeichertes XSS deshalb so unangenehm, weil der Schadcode nicht flüchtig im Browserverlauf verschwindet, sondern dauerhaft in der Anwendung liegt – in diesem Fall vermutlich in einer gespeicherten E-Mail oder einem zugehörigen Objekt. Jedes Mal, wenn das Postfach die betroffene Nachricht rendert, greift der Code erneut. Ein einmaliges Löschen der Mail reicht nicht automatisch aus, wenn zwischenzeitlich Sitzungsdaten, Tokens oder Weiterleitungsregeln manipuliert wurden. Genau deshalb reicht bei der forensischen Prüfung ein Blick auf den E-Mail-Eingang nicht aus; auch Postfachregeln, OAuth-Berechtigungen und aktive Sitzungen gehören auf die Kontrollliste.

Laundry Bear: viele Namen, ein Ziel

Der Angreifer hinter der aktuellen Kampagne trägt gleich mehrere Aliase. Das CISA Advisory AA26-204A führt die Gruppe unter den Namen Laundry Bear, Void Blizzard, CL-STA-1114, TA488 und UNK_PitStop und ordnet die Aktivität russischer Informationsbeschaffung zu. Mehrere Namen für dieselbe Gruppe sind in der Bedrohungsanalyse Alltag – verschiedene Sicherheitsfirmen tracken dieselben Cluster unabhängig voneinander und vergeben eigene Bezeichnungen, bis sich die Zuordnung als identisch herausstellt.

Nach aktuellem Kenntnisstand laufen die Kampagnen mindestens seit Juli 2025. Die Zielgruppen lesen sich wie eine Liste kritischer Infrastruktur: Regierungen, Bildungseinrichtungen, Energieversorger, Strafverfolgungsbehörden, Medien, Nichtregierungsorganisationen und Technologieunternehmen. Das Muster ist klassische Spionage, nicht Sabotage – es geht ums Mitlesen, nicht ums Lahmlegen. Von einer eskalierenden Konfrontation im großen Stil zu sprechen, wäre daher übertrieben; es handelt sich um gezielte, geduldige Informationsbeschaffung, die genau deshalb so lange unter dem Radar läuft.

Diese Geduld ist Teil der Strategie. Wer über Monate hinweg systematisch Postfächer mitliest, statt Systeme lahmzulegen, verrät sich seltener durch spektakuläre Ausfälle. Genau deshalb brauchte es ein behördenübergreifendes Advisory, um das Muster überhaupt sichtbar zu machen – einzelne betroffene Organisationen hätten die Zusammenhänge kaum isoliert erkannt.

Die typische Angriffskette lässt sich in wenigen Schritten skizzieren: Zunächst wird eine präparierte HTML-Mail mit manipuliertem CSS an ein Zielpostfach zugestellt. Öffnet oder rendert das Zimbra-Interface diese Nachricht, greift die gespeicherte XSS-Lücke, und im Kontext der eingeloggten Sitzung wird Code ausgeführt. Von dort aus folgt in der Regel das Auslesen von Sitzungscookies oder Zugangstoken, häufig ergänzt durch das Anlegen unauffälliger Weiterleitungsregeln, die Kopien eingehender Mails an eine externe Adresse senden. Der eigentliche Datenabfluss läuft dann leise im Hintergrund weiter, oft über Wochen, ohne dass die betroffene Person etwas bemerkt. Erst der Abgleich mit IOC-Listen oder ungewöhnlichen Login-Mustern deckt solche Zugriffe später auf.

Warum Zero-Click bei Mailservern besonders unangenehm ist

Bei klassischem Phishing braucht es einen Klick, einen Anhang, eine Unachtsamkeit. Genau diese Schwelle fällt hier weg. Für die Ausnutzung reicht laut aktuellem Bericht die reine Darstellung einer präparierten E-Mail im Zimbra-Interface – ein Klick auf einen Link ist nicht erforderlich. Das Postfach öffnen, die Vorschau laden, fertig. Awareness-Schulungen, so wichtig sie sind, greifen hier ins Leere. Niemand kann trainiert werden, eine E-Mail nicht zu öffnen, wenn genau das Öffnen der Job des Postfachs ist.

Das erhöht die Angriffsfläche von E-Mail-Systemen strukturell und rückt Mailserver noch stärker in den Fokus von Angreifern, die auf leise, dauerhafte Zugänge setzen statt auf lauten Lärm. Mehr dazu, warum sich die Angriffsfläche in diesem Bereich messbar vergrößert hat, lesen Sie in unserem Beitrag zur E-Mail-Sicherheit am Endpunkt.

Wer jetzt an Browser-Rendering-Probleme denkt, liegt nicht falsch – ähnliche Mechanismen sorgen auch anderswo für Kopfschmerzen. Wie eine Lücke im Zusammenspiel von KI-Erweiterungen und Webdiensten aussieht, zeigt der Fall rund um Claude für Chrome und die Gefährdung von Gmail und Google Docs. Das Grundproblem ist ähnlich: Inhalte werden verarbeitet, bevor jemand bewusst entscheidet, ob er ihnen vertraut. Bei Zimbra ist es CSS in einer HTML-Mail, dort war es die Verarbeitung von Webinhalten durch eine KI-Erweiterung – die Angriffsfläche verschiebt sich, das Grundprinzip bleibt.

Ein weiterer Aspekt, der bei Zero-Click-Lücken oft unterschätzt wird: Sie funktionieren unabhängig vom Endgerät. Ob eine Mitarbeiterin die Mail am Desktop, im Homeoffice oder über ein Tablet abruft, spielt für die Ausnutzung keine Rolle, solange das Zimbra-Webinterface die Nachricht rendert. Klassische Endpoint-Schutzmaßnahmen, die auf verdächtige Downloads oder Makros in Anhängen abzielen, laufen hier komplett ins Leere, weil kein Anhang und kein Download im klassischen Sinn beteiligt ist. Die Schwachstelle liegt in der Serveranwendung selbst, nicht im Verhalten der Nutzerin oder des Nutzers.

Die Patch-Historie: alt, aber nicht erledigt

Zimbra hat den Fix für CVE-2025-66376 längst veröffentlicht. Laut den Zimbra Security Advisories ist die Lücke in den Releases 10.1.13 und 10.0.18 geschlossen. CISA nahm die Schwachstelle bereits am 18. März 2026 in den Known Exploited Vulnerabilities Catalog auf, mit einer damaligen Abhilfefrist zum 1. April 2026. Wer als Bundesbehörde in den USA damals gepatcht hat, ist fein. Wer nicht – und das dürfte der eigentliche Nährboden für die aktuelle Kampagne sein – bietet Laundry Bear bis heute eine offene Tür.

Genau das ist der Kern dieser Meldung: kein neuer Zero-Day, sondern der Beleg, dass eine seit Monaten bekannte und patchbare Lücke weiterhin aktiv ausgenutzt wird. Der KEV-Katalog listet solche Fälle nicht zum Spaß, sondern weil erfahrungsgemäß genau diese Lücken am längsten offenstehen.

Wie hoch der Patchdruck bei aktiv ausgenutzten Lücken generell inzwischen liegt, zeigt der Vergleich mit dem Fall rund um die Langflow-Lücke und GhostLock. Auch dort galt: Sobald eine Schwachstelle im KEV-Katalog landet, ist Zögern keine Option mehr, sondern ein Risiko mit Ablaufdatum. Der Unterschied zwischen einer gepatchten und einer ungepatchten Installation ist in solchen Fällen selten graduell – er ist binär.

Für die Patchstrategie ergibt sich daraus eine klare Reihenfolge. Zuerst zählt die Versionsprüfung: Jede Zimbra-Instanz unterhalb von 10.0.18 beziehungsweise 10.1.13 gilt als verwundbar und sollte mit höchster Priorität aktualisiert werden, unabhängig davon, ob bereits konkrete Anzeichen einer Kompromittierung vorliegen. Danach folgt die Aktualisierung auf den aktuell empfohlenen Stand, weil einzelne Sicherheitsflicken selten isoliert bleiben und spätere Versionen zusätzliche Härtungsmaßnahmen mitbringen. Erst im dritten Schritt folgt die rückwirkende forensische Prüfung, ob die Lücke in der Vergangenheit bereits ausgenutzt wurde. Diese Reihenfolge – patchen, aktualisieren, dann erst forensisch prüfen – verhindert, dass während einer aufwendigen Analyse weiterhin ungeschützte Systeme im Netz stehen.

Der aktuelle Stand: 10.1.20 und was jetzt zu tun ist

Wer auf Zimbra Collaboration setzt, sollte nicht bei den Mindestversionen 10.0.18 oder 10.1.13 stehen bleiben. Die offizielle Zimbra-Advisory-Seite führt aktuell 10.1.20 als jüngste Release-Version, die zusätzliche Sicherheitskorrekturen enthält. Zimbra selbst empfiehlt grundsätzlich die Aktualisierung auf die neuesten unterstützten Versionen – nicht nur wegen dieser einen Lücke, sondern weil sich Sicherheitskorrekturen in der Praxis selten einzeln stapeln lassen.

Konkrete Sofortmaßnahmen für IT-Teams, die ihre Zimbra-Instanzen betreiben:

• Zimbra-Version prüfen und auf mindestens 10.0.18 beziehungsweise 10.1.13 anheben, im besten Fall direkt auf 10.1.20.
• Logs auf verdächtige Zugriffsmuster im Classic UI und ungewöhnliche Mailverarbeitung prüfen.
• IOC-Listen aus dem CISA-Advisory mit eigenen Systemen abgleichen.
• Zugriffsrechte auf Mailserver-Administrationsoberflächen einschränken und Multi-Faktor-Authentifizierung durchsetzen, sofern noch nicht geschehen.
• Classic-UI-Zugänge dort deaktivieren, wo sie nicht zwingend benötigt werden, um die Angriffsfläche zusätzlich zu verkleinern.

Bei der Log-Prüfung lohnt sich ein systematischer Blick auf mehrere Ebenen gleichzeitig. Zunächst die Webserver- und Applikationslogs von Zimbra selbst: Ungewöhnlich viele Zugriffe auf Classic-UI-Endpunkte, insbesondere aus IP-Bereichen, die sonst nicht zum üblichen Nutzerkreis gehören, sind ein erstes Warnsignal. Zweitens die Authentifizierungslogs: Anmeldungen zu untypischen Zeiten, aus neuen Regionen oder mit ungewöhnlich häufigen Session-Erneuerungen deuten auf gestohlene Tokens hin. Drittens die Konfiguration von Postfächern selbst – automatische Weiterleitungsregeln, die nicht von der jeweiligen Person eingerichtet wurden, sind ein klassisches Nachnutzungsmuster bei kompromittierten Mailkonten. Wer zusätzlich Zugangsdaten-Diebstahl als Bedrohungsszenario ernst nimmt, findet ergänzende Hinweise im Beitrag zum ClickLock Stealer und seiner Jagd auf Zugangsdaten – auch dort zeigt sich, wie wenig Interaktion Angreifer heute noch benötigen, um an Zugangsdaten zu kommen.

Wie dringlich Patchpriorisierung in solchen Fällen sein kann, zeigt der Vergleich mit der jüngst bekannt gewordenen Linux-Schwachstelle, bei der Distributionen zu Eil-Patches gezwungen waren.

Für die Priorisierung innerhalb größerer IT-Landschaften empfiehlt sich ein einfaches, aber wirksames Raster: Systeme mit direktem Internetzugriff und öffentlich erreichbarem Zimbra-Webinterface zuerst, interne Mailserver mit eingeschränktem Zugriff danach, Testumgebungen zuletzt. Wer mehrere Zimbra-Instanzen betreibt – etwa in unterschiedlichen Abteilungen oder Tochtergesellschaften – sollte zudem eine zentrale Übersicht über Versionsstände pflegen. Genau an dieser Stelle scheitert Patch-Management in der Praxis häufig: nicht am fehlenden Patch, sondern am fehlenden Überblick, welche Instanz überhaupt existiert.

Was die Warnung für Betreiber von Mailservern bedeutet

CISA-Advisories wie AA26-204A sind keine Panikknöpfe, sondern Lagebilder. Sie fassen zusammen, was Threat-Intelligence-Teams über Wochen und Monate beobachtet haben, und liefern IOCs, damit Verteidiger konkret nachschauen können, ob sie betroffen sind. Dass Laundry Bear seit mindestens Juli 2025 aktiv ist und mehrere Aliase trägt, zeigt: Diese Gruppe operiert nicht spontan, sondern systematisch. Wer als Organisation zu den genannten Zielbranchen zählt – Regierung, Bildung, Energie, Strafverfolgung, Medien, NGOs, Tech – sollte den Patchstatus seiner Zimbra-Installation nicht dem Zufall überlassen.

Sicherheitslücken wie CVE-2025-66376 verschwinden nicht, weil ein Patch existiert. Sie verschwinden, wenn der Patch installiert wird. Zwischen diesen beiden Sätzen liegt der gesamte Unterschied zwischen einer geschlossenen Akte und einer laufenden Spionagekampagne. Eine restlos abgesicherte Mailumgebung gibt es ohnehin nicht – aber eine aktualisierte Zimbra-Instanz schließt zumindest die Tür, die hier seit Monaten offensteht.

Organisatorisch lohnt sich außerdem ein Blick auf die Prozesse rund um Advisories selbst. Wer erst reagiert, wenn ein Medienbericht die Runde macht, hat den eigentlichen Vorsprung bereits verloren. Sinnvoller ist ein fester Ablauf: Ein zuständiges Team abonniert relevante Behördenwarnungen und Herstelleradvisories aktiv, bewertet neue Einträge innerhalb eines festen Zeitfensters – etwa 24 bis 48 Stunden – und dokumentiert die Entscheidung, ob und wann gepatcht wird, nachvollziehbar. Diese Dokumentation ist im Ernstfall nicht nur für die eigene Nachvollziehbarkeit wichtig, sondern auch gegenüber Aufsichtsbehörden, falls es doch zu einem Vorfall kommt. Wer belegen kann, dass ein KEV-Eintrag innerhalb der empfohlenen Frist abgearbeitet wurde, steht in jeder Nachbetrachtung besser da als jemand, der schlicht nichts dokumentiert hat.

Ein Blick auf die Verantwortung jenseits der IT-Abteilung

Ein Detail geht in der Debatte um CVSS-Werte und Patchstände oft unter: Diese Lücke betrifft nicht nur IT-Abteilungen, sondern jede Person, die ein Zimbra-Postfach nutzt. Niemand muss dabei etwas falsch machen. Genau das macht Zero-Click-Schwachstellen aus Sicht der Kommunikation so unangenehm zu erklären – es gibt keine Verhaltensregel, die dagegen hilft. Umso mehr Gewicht liegt auf der technischen Seite: Wer patcht, entzieht dem Angriff die Grundlage. Wer nicht patcht, verlässt sich auf Glück, und Glück ist bekanntlich keine Sicherheitsstrategie.

Auf organisatorischer Ebene bedeutet das auch, Verantwortlichkeiten klar zu benennen. Zu oft liegt der Betrieb eines Mailservers formal bei der IT-Abteilung, während die eigentliche Entscheidungsgewalt über Budget und Zeitfenster für Wartungsarbeiten bei der Geschäftsführung liegt. Genau in dieser Schnittstelle versanden Patches häufig – nicht aus Unwissen, sondern weil niemand die Verantwortung final trägt. Ein klar benannter Ansprechpartner für Schwachstellenmanagement, mit direktem Durchgriff auf Wartungsfenster, verkürzt die Reaktionszeit erheblich. Für kleinere Organisationen kann das eine einzelne Person sein, für größere ein festes Gremium, das sich regelmäßig mit offenen Advisories befasst.

Für Administratoren bleibt die Lage überschaubar, wenn sie handeln: Version prüfen, aktualisieren, IOCs abgleichen, fertig. Für alle, die es bislang aufgeschoben haben, liefert die aktuelle Warnung den unbequemen, aber klaren Anstoß, das jetzt endlich zu erledigen – bevor aus einer bekannten Lücke ein bekannter Datenverlust wird.