Wer seine E-Mails lieber selbst hostet statt sie Google oder Microsoft anzuvertrauen, landet fast zwangsläufig bei Zimbra Collaboration Suite. Und wer in diesem Jahr mitgezählt hat, kennt das Muster schon: Es ist bereits die dritte gravierende Zimbra-Lücke seit Juli. Diesmal trifft es die Anbindung an OnlyOffice, die Dokumentenbearbeitung direkt im Postfach ermöglicht — und sie ist am 25. September 2026 unter der Kennung CVE-2026-93643 öffentlich geworden.
DAS PROBLEM: Ungeprüfte Speicherorte in Dokumenten
Die Lücke steckt in der Art, wie Zimbra Änderungen aus dem OnlyOffice-Dokumenteneditor zurücknimmt und speichert. Genauer gesagt in sogenannten „unsigned save fields“ — also Feldern, die eigentlich signiert und damit gegen Manipulation abgesichert sein sollten, es in der Praxis aber nicht ausreichend sind. Ein Angreifer kann dort Pfad-Traversal-Sequenzen wie ../ einschleusen und damit Zimbra dazu bringen, eine Datei nicht im vorgesehenen Dokumentenordner zu speichern, sondern an einer frei wählbaren Stelle im Dateisystem.
Die CVSS-Wertung liegt bei 9,8 von 10 — und das aus gutem Grund: Für den Angriff reicht der Zugriff auf ein einziges, öffentlich freigegebenes Briefcase-Dokument. Eine echte Anmeldung am System ist dafür nicht nötig.
VOM DATEISCHREIBEN ZUR KOMPLETTEN ÜBERNAHME
Ein beliebiger Dateischreibzugriff klingt zunächst abstrakt — wird aber schnell konkret, sobald man bedenkt, was auf einem Mailserver sonst noch liegt: Konfigurationsdateien, Startskripte, Cron-Jobs. Landet eine bösartige Datei an der richtigen Stelle, kann daraus Codeausführung mit den Rechten des Systembenutzers zimbra werden. Genau das ist der Endpunkt, den Sicherheitsforscher für diese Lücke beschreiben — auch wenn der exakte letzte Schritt von der Dateischreib-Lücke zur Codeausführung öffentlich noch nicht bis ins letzte Detail dokumentiert ist.
Zur Ehrlichkeit gehört: Bislang ist kein eigenständiger, öffentlich verfügbarer Exploit-Code in offenen Repositories aufgetaucht. Das ist kein Grund zur Entwarnung, aber auch keine Situation wie bei den Fällen weiter oben in diesem Artikel, wo Angreifer innerhalb von Stunden aktiv wurden.
DAS DRITTE MAL IN ZWEI MONATEN
Wer im August und Juli mitgelesen hat, kennt das Muster: Erst eine Lücke, über die eine einzige E-Mail das Postfach kapern konnte, dann eine Frist-Warnung zu einer bereits aktiv ausgenutzten Schwachstelle — und jetzt die OnlyOffice-Anbindung. Zimbra ist damit kein Einzelfall-Problem, sondern ein System, das gerade regelmäßig neue kritische Lücken produziert. Für Betreiber heißt das: Sicherheitsupdates dürfen hier nicht mehr auf die lange Bank geschoben werden, sondern gehören auf die Liste der Dinge, die man mindestens wöchentlich prüft.
SO SCHÜTZT DU DEINEN MAILSERVER — in 10 MINUTEN
- Bestandsaufnahme: Läuft auf deinem Zimbra-Server die OnlyOffice- beziehungsweise Document-Editing-Integration? Nur dann bist du überhaupt betroffen.
- Zimbra-Sicherheitshinweis lesen: Zimbra veröffentlicht zu jeder CVE einen eigenen Advisory mit der exakten Fix-Version für deinen Zweig (Network Edition oder Open-Source-Ausgabe unterscheiden sich).
- Sofort aktualisieren, sobald der Patch für deine Version vorliegt — bei einer unauthentifizierten 9,8er-Lücke zählt jeder Tag.
- Übergangsweise absichern: Wer nicht sofort patchen kann, sollte die OnlyOffice-Integration vorübergehend deaktivieren oder den Zugriff auf öffentlich freigegebene Briefcase-Dokumente einschränken.
- Logs prüfen: Ungewöhnliche Schreibzugriffe außerhalb der üblichen Dokumentenordner sowie neue oder veränderte Dateien in Systemverzeichnissen sind ein Warnsignal.
FAZIT: Mailserver brauchen jetzt mehr Aufmerksamkeit
Ein selbst gehosteter Mailserver ist eine der wertvollsten Datenquellen im ganzen Netzwerk — Passwort-Resets, interne Kommunikation, oft auch Zugangsdaten laufen dort durch. Dass ausgerechnet die komfortable Dokumentenbearbeitung zum dritten Mal in Folge zum Einfallstor wird, ist ein deutliches Signal: Wer Komfortfunktionen wie OnlyOffice aktiviert, erweitert damit automatisch auch die Angriffsfläche seines Mailservers — und sollte das Sicherheits-Patchmanagement entsprechend ernst nehmen.