Kiteworks: Hersteller empfiehlt Abschaltung am 26. September - Was bislang bekannt ist

Kiteworks hat seine Kunden am 25. September 2026 per E-Mail aufgefordert, alle Kiteworks-Systeme am Samstag, 26. September, von 04:00 bis 10:00 Uhr (mitteleuropäische Zeit) herunterzufahren. Laut dem Schreiben des CISO Frank Balonis liegen dem Hersteller Hinweise von Strafverfolgungsbehörden vor, dass an diesem Wochenende ein Angriff auf Kiteworks-Systeme bevorstehen könnte. Der Kundensupport begründet die Abschaltung mit dem Schutz vor möglichen Zero-Day-Angriffen. heise online hat die Echtheit der Nachricht telefonisch beim Support bestätigt.

Chronologie

Alle Zeiten in mitteleuropäischer Sommerzeit (MESZ). Wo keine Uhrzeit angegeben ist, liegt keine belastbare Zeitangabe vor.

1. Fr, 25. September

   Advisory an die Kunden

   CISO Frank Balonis informiert die Kunden per E-Mail über Hinweise von Strafverfolgungsbehörden auf einen möglichen Angriff an diesem Wochenende und empfiehlt eine Abschaltung für sechs Stunden. Laut Advisory sind alle bekannten Schwachstellen in Version 9.5.1 behoben.

2. Fr, 25. September

   Erste Medienberichte

   heise online berichtet, der Kiteworks-Support bestätigt die Echtheit der Nachricht und begründet die Abschaltung mit dem Schutz vor möglichen Zero-Day-Angriffen. Kurz darauf folgen TechCrunch, BleepingComputer, Computer Weekly und weitere.

3. Fr, 25. September, 17:41

   BKA äussert sich nicht

   heise ergänzt: Das BKA lehnt eine Stellungnahme aus ermittlungstaktischen Gründen ab. Das BSI antwortet nicht, das FBI verzichtet gegenüber TechCrunch auf einen Kommentar.

4. Fr, 25. September

   Stellungnahme und Pressemitteilung

   Kiteworks bezeichnet die Abschaltung als Vorsichtsmassnahme ohne bekannte Kompromittierung. Die Pressemitteilung nennt „federal intelligence authorities“ als Quelle und listet die nicht betroffenen Tochterfirmen auf, darunter totemo. Von Kiteworks gehostete Instanzen fährt der Hersteller selbst herunter.

5. Sa, 26. September, 04:00 bis 10:00

   Abschaltfenster

   Das Fenster liegt weltweit gleichzeitig: 02:00 bis 08:00 UTC, in Sydney 12:00 bis 18:00, in New York Freitag 22:00 bis Samstag 04:00.

6. Sa, 26. September, 10:00

   Ende des Fensters

   Das in der Kunden-E-Mail genannte Fenster endet. Die formelle Aufhebung der Empfehlung folgt am 27. September.

7. So, 27. September

   Empfehlung aufgehoben

   Kiteworks ergänzt die Pressemitteilung: Die Abschaltempfehlung ist für alle Kunden aufgehoben, die Systeme dürfen wieder laufen. Die gehosteten Instanzen sind wieder in Betrieb. Kunden mit selbst betriebenen Advanced Forms sollen sich an den Support wenden.

8. Stand Mo, 28. September

   Weiterhin offen

   Kein öffentliches Advisory, keine CVE-Nummer, keine neue Version, keine Indikatoren, keine Angaben zur Lücke und keine Berichte über einen erfolgten oder versuchten Angriff.

Was bekannt ist

Die Empfehlung gilt weltweit; die E-Mail nennt das Zeitfenster für alle Zeitzonen von AEST bis PDT. Kiteworks rät, die Systeme schon vor Beginn des Fensters herunterzufahren, und zwar auch dann, wenn sie nicht aus dem Internet erreichbar sind.

Offen ist bisher fast alles andere: Es gibt kein öffentliches Security Advisory, keine CVE-Nummer, keinen Patch und keine Angabe dazu, welche Produkte oder Versionen betroffen sind. Die Pressemitteilung nennt als Quelle „federal intelligence authorities“, vermutlich also US-Bundesbehörden; welche, ist nicht bekannt. Unter Security Updates und in den GitHub-Advisories von Kiteworks gibt es Stand 28. September keinen Eintrag; der letzte GitHub-Eintrag stammt vom 27. Mai 2026. Öffentlich sind die oben zitierte Stellungnahme und die Pressemitteilung vom 25. September.

Gegenüber TechCrunch hat Kiteworks-CISO Frank Balonis die Stellungnahme im selben Wortlaut abgegeben. Das BKA hat gegenüber heise eine Stellungnahme aus ermittlungstaktischen Gründen abgelehnt, das BSI hat nicht geantwortet. Das FBI wollte sich gegenüber TechCrunch nicht äussern, ein Sprecher der CISA wollte sich nicht öffentlich äussern. Ein Kunde aus dem Gesundheitswesen hat laut TechCrunch seinen Server sofort vom Netz genommen, mit spürbaren Einschränkungen im Betrieb: Ärzte konnten ihre Patienten zeitweise nur verzögert erreichen. Laut einem von TechCrunch zitierten Sicherheitsforscher sind mindestens 1000 Kiteworks-Systeme aus dem Internet erreichbar; BornCity spricht von mehr als 1000 Organisationen, die die Warnung erhalten haben.

Die Pressemitteilung weicht in einem Punkt von der Kunden-E-Mail ab: Sie spricht von einem Abschaltfenster von neun Stunden, die Advisory an die Kunden von sechs Stunden. Laut Pressemitteilung betrifft die Empfehlung nur selbst betriebene Installationen (On-Premises, AWS, Azure). Nicht betroffen sind nach Angaben des Herstellers die Tochterfirmen Zivver, DRACOON, totemo, ownCloud, WAMNET, Maytech, Bonfy.ai und 123FormBuilder.

Die Advisory an die Kunden

Die Kunden-E-Mail vom 25. September enthält neben der Warnung einen Zeitplan pro Zeitzone und eine Anleitung für Cluster. Rechnet man die Zeiten auf UTC um, ergibt sich für alle Regionen dasselbe Fenster von 02:00 bis 08:00 UTC.

Für Cluster mit mehreren Servern gibt Kiteworks eine feste Reihenfolge vor:

1. Wartungsmodus einschalten unter System Setup > Maintenance Mode, damit keine Benutzer mehr zugreifen.

2. Sicherung erstellen: einen Snapshot jedes Knotens oder ein Backup der Kiteworks-Datenbank (System Setup > Cluster Configuration > System Configuration). Es wird nur ein Datenbank-Backup vorgehalten; jedes neue ersetzt das vorherige.

3. Rollen erfassen: Unter System Setup > Locations zeigt die Spalte Assigned Roles, welche Knoten die Application-Rolle haben; der primäre Application-Knoten ist mit einem Stern markiert. Die Knoten und ihre IP-Adressen notieren, sie werden für den Neustart gebraucht.

4. Herunterfahren in dieser Reihenfolge: zuerst alle Knoten ohne Application-Rolle, dann die übrigen Application-Knoten, zuletzt den primären Application-Knoten. Das geht über den Reiter Shut Down des jeweiligen Knotens oder über die Konsole des Hypervisors (etwa VMware oder AWS), wenn die Kiteworks-Oberfläche nicht mehr erreichbar ist.

5. Neustart in umgekehrter Reihenfolge über den Hypervisor, da die Admin-Konsole erst erreichbar ist, wenn genügend Knoten laufen (Anhang E des Administrator Guide): zuerst den primären Application-Knoten, dann die übrigen Application-Knoten einzeln und jeweils erst, wenn der vorherige vollständig läuft, damit die Datenbank-Server ein Quorum bilden können. Danach die Storage-Server, dann die übrigen Rollen (Repositories Gateway, Search, SFTP, Antivirus), zuletzt die Web-Server.

6. Wartungsmodus ausschalten, sobald alle Knoten im Cluster Health Dashboard auf der Statusseite der Admin-Konsole grün sind.

Auf Nachfrage hat der Kiteworks-Support zudem bestätigt, dass keine der Tochterfirmen von Kiteworks betroffen ist.

Mögliche Ursachen: Theorien

Solange Kiteworks keine Details veröffentlicht, bleibt die Ursache offen. Die folgenden Erklärungen sind Hypothesen, die sich aus den bekannten Eckdaten ableiten lassen; einige davon werden auch in den Kommentaren zur heise-Meldung diskutiert. Keine davon ist bestätigt.

Drei Eckdaten schränken den Raum ein. Erstens nennt die Warnung ein festes Zeitfenster statt einer unbefristeten Abschaltung bis zum Patch. Zweitens sollen auch Systeme vom Netz, die nicht aus dem Internet erreichbar sind. Drittens liegt das Fenster weltweit auf derselben Uhrzeit (02:00 bis 08:00 UTC) statt jeweils in der lokalen Nacht. Eine klassische, über das Internet ausnutzbare Lücke würde die ersten beiden Punkte nicht erklären: Dagegen hilft es, das System vom Internet zu trennen, und zwar so lange, bis der Patch da ist.

1. Den Behörden ist ein geplanter Zeitpunkt bekannt

Strafverfolgungsbehörden erfahren den Zeitpunkt einer geplanten Kampagne gelegentlich vorab, etwa aus überwachter Kommunikation einer Tätergruppe oder aus beschlagnahmter Infrastruktur. Massenhafte Ausnutzungen von Dateiaustausch-Produkten laufen typischerweise in einem kurzen, koordinierten Fenster ab, oft an Wochenenden oder Feiertagen, wenn weniger Personal im Einsatz ist. Kiteworks ist der Nachfolger von Accellion, dessen File Transfer Appliance 2020 und 2021 genau so angegriffen wurde, damals der Gruppe Clop zugeordnet: Über mehrere Lücken wurden Daten abgezogen, anschliessend wurden die betroffenen Organisationen erpresst.

Dafür spricht das eng umrissene Fenster am Wochenende. Dagegen spricht der Einwand, den mehrere Kommentatoren bei heise erheben: Die Warnung ging an alle Kunden, die Angreifer dürften also davon wissen und können den Angriff einfach verschieben. Eine Verschiebung würde dem Hersteller aber Zeit für einen Patch verschaffen.

2. Der Hersteller kennt die Lücke selbst noch nicht

Möglich ist auch, dass Kiteworks ausser dem Hinweis der Behörden keine technischen Details hat, also weder die betroffene Komponente kennt noch einen Patch oder eine Konfigurationsänderung empfehlen kann. Dann ist die Abschaltung die einzige Massnahme, die ohne Kenntnis der Lücke wirkt, und das feste Ende ein Kompromiss, den die Kunden eher mittragen. In den heise-Kommentaren wird dazu die Vermutung geäussert, der Hersteller könnte während des Fensters einzelne Systeme als Köder online lassen, um den Angriff zu beobachten. Belege dafür gibt es keine.

Dafür spricht, dass weder ein Advisory noch eine Mitigation genannt wird. Dagegen spricht, dass Kiteworks nach eigenen Angaben mit Mandiant zusammenarbeitet und bei einer Warnung von Behörden in der Regel zumindest Indikatoren zur Verfügung stehen.

3. Eine bereits platzierte Hintertür mit Zeitauslöser

Die Empfehlung, auch interne Systeme herunterzufahren, passt zu einem Szenario, in dem der Angriff nicht von aussen kommt, sondern auf den Appliances bereits vorbereitet ist: etwa eine Hintertür aus einer früheren Kompromittierung, die zu einem festen Zeitpunkt aktiv wird oder Kontakt zu einem Kontrollserver aufnimmt. Ein ausgeschaltetes System kann zu diesem Zeitpunkt nichts ausführen.

Dafür spricht, dass die Erreichbarkeit aus dem Internet bei diesem Szenario keine Rolle spielt. Dagegen spricht, dass ein Hersteller in diesem Fall eher eine Prüfung auf Kompromittierung und eine Neuinstallation empfehlen würde als einen Neustart nach sechs Stunden.

4. Kompromittierung auf Herstellerseite

Ein weiterer Weg, der interne Systeme erreicht, sind Verbindungen, die von der Appliance zum Hersteller aufgebaut werden, etwa für Updates, Lizenzprüfung oder Fernwartung. Ist ein solcher Kanal kompromittiert, schützt eine Firewall vor eingehendem Verkehr nicht. Die Abschaltung würde dem Hersteller in diesem Szenario ein Fenster verschaffen, um die eigene Infrastruktur zu bereinigen, Schlüssel oder Zertifikate zu tauschen und erst danach wieder Verbindungen zuzulassen.

Dafür spricht der weltweit einheitliche Zeitpunkt, der zu einer koordinierten Aktion auf Herstellerseite passt. Dagegen spricht, dass der Hersteller dann eher empfehlen würde, die ausgehenden Verbindungen zu sperren, statt die Systeme ganz abzuschalten.

5. Begleitmassnahme zu einer Behördenaktion

Denkbar ist schliesslich, dass die Behörden im selben Zeitraum gegen die Infrastruktur der Angreifer vorgehen und verhindern wollen, dass diese als Reaktion noch schnell zuschlagen. Das würde das kurze Fenster und die Rolle der Strafverfolgung erklären. Dass das BKA eine Stellungnahme aus ermittlungstaktischen Gründen ablehnt, deutet auf laufende Ermittlungen hin, belegt diese Variante aber nicht.

Kritik an der Kommunikation

In den heise-Kommentaren überwiegt Skepsis, und die Einwände sind sachlich nachvollziehbar: Ohne Angaben zur Lücke lässt sich nicht beurteilen, ob eine Trennung vom Internet per Firewall genügt hätte. Ein Zeitfenster ohne angekündigten Patch lässt offen, was nach 10:00 Uhr gilt. Und eine Warnung, die nur per E-Mail an Kunden geht, erreicht nicht alle Betreiber, etwa bei Partnern, Dienstleistern oder nach Personalwechseln. Unabhängig davon, welche Theorie zutrifft: Wer Kiteworks betreibt, sollte nach dem Wiederhochfahren die Protokolle prüfen und die Kanäle des Herstellers beobachten, bis ein Advisory vorliegt.

Nach dem Fenster: Was Betreiber jetzt tun können

Kiteworks hat die Abschaltempfehlung am 27. September aufgehoben, aber keine technischen Details veröffentlicht. Ob und wie die Gefahr beseitigt wurde, lässt sich daher nicht beurteilen. Beim Wiederhochfahren und danach sind folgende Schritte sinnvoll:

1. Version prüfen: Läuft auf allen Knoten Version 9.5.1? Laut Hersteller sind darin alle bekannten Schwachstellen behoben.

2. Cluster-Zustand prüfen: Im Cluster Health Dashboard sollten alle Knoten grün sein und der Wartungsmodus ausgeschaltet.

3. Protokolle auswerten: Anmeldungen, Administrator-Aktionen und ungewöhnliche Datei-Downloads um das Abschaltfenster herum sichten, insbesondere bei Systemen, die nicht oder erst spät heruntergefahren wurden.

4. Erreichbarkeit einschränken: Wo möglich, den Zugriff aus dem Internet auf die Administrationsoberfläche sperren und nur benötigte Dienste freigeben.

5. Advanced Forms: Wer das Modul selbst betreibt, klärt den Neustart vorher mit dem Kiteworks-Support.

6. Kanäle beobachten: Security Updates, GitHub-Advisories, Newsroom und Kunden-E-Mails von Kiteworks, bis ein Advisory mit technischen Details vorliegt.