Kiteworks: Kunden sollen Server am 26. September wegen Angriffswarnung abschalten

Wer Kiteworks selbst betreibt, also on-premises, als virtuelle Appliance oder in einer eigenen AWS- oder Azure-Umgebung, muss heute handeln: Der Hersteller rät allen Kunden weltweit, ihre Kiteworks-Systeme am Samstag, 26. September 2026, vorsorglich herunterzufahren. Für Mitteleuropa nennt die Kunden-E-Mail laut heise security das Fenster von 4:00 bis 10:00 Uhr MESZ, empfohlen wird das Abschalten schon vorher und ausdrücklich auch für Systeme, die nicht aus dem Internet erreichbar sind. Anlass ist nach Angaben von Kiteworks ein glaubwürdiger Hinweis von Bundesbehörden auf einen möglicherweise bevorstehenden Angriff.

Wer Kiteworks nicht einsetzt, ist von dieser Warnung nicht betroffen. Kunden mit einer von Kiteworks gehosteten Instanz müssen laut Hersteller nichts tun, weil Kiteworks diese Systeme im selben Zeitraum selbst abschaltet. Ebenfalls ausdrücklich nicht betroffen sind laut Kiteworks die Tochterfirmen und deren Produkte, darunter DRACOON, totemo, ownCloud, Zivver, WAMNET und 123Formbuilder. Gerade im deutschsprachigen Raum ist diese Abgrenzung wichtig, denn DRACOON und ownCloud sind hier verbreitet und werden in dieser Meldung nicht zur Abschaltung aufgefordert.

Was ist passiert?

Am Freitag, 25. September 2026, hat Kiteworks seine Kunden per E-Mail gewarnt. Zuerst berichtete heise security, dem die Nachricht von Kiteworks-CISO Frank Balonis vorliegt. Darin heißt es sinngemäß, man habe von Strafverfolgungsbehörden glaubwürdige Informationen erhalten, dass an diesem Wochenende ein Angriff auf Kiteworks-Systeme unmittelbar bevorstehen könnte, und empfehle dringend, das eigene Kiteworks-System für sechs Stunden herunterzufahren. Die Liste der Zeitzonen in der E-Mail reicht laut heise von AEST in Australien bis PDT an der US-Westküste, die Warnung gilt also weltweit.

Kiteworks hat den Vorgang gegenüber BleepingComputer und TechCrunch bestätigt. Am späten Freitagabend folgte eine offizielle Pressemitteilung. Darin spricht Kiteworks von einem vorsorglichen Abschaltfenster an diesem Wochenende in der jeweiligen lokalen Zeitzone. Auffällig: Die Pressemitteilung nennt ein neunstündiges Fenster, während die von heise und BleepingComputer zitierte Kunden-E-Mail sechs Stunden nennt. Die genauen Uhrzeiten pro Zeitzone stehen laut Kiteworks in der E-Mail an die Kunden. Maßgeblich ist deshalb die E-Mail, die im eigenen Postfach angekommen ist.

Als Grund nannte der Kiteworks-Support gegenüber heise den Schutz vor möglichen Zero-Day-Angriffen. Zugleich betont Kiteworks, dass keine Kompromittierung von Kiteworks- oder Kundensystemen bekannt sei. Alle bekannten Schwachstellen seien in der aktuellen Version 9.5.1 behoben. Welche Behörde gewarnt hat und welche Angreifergruppe dahinterstehen könnte, sagte das Unternehmen auf Nachfrage von TechCrunch nicht. Das FBI lehnte gegenüber TechCrunch einen Kommentar ab, das Bundeskriminalamt äußerte sich gegenüber heise zunächst aus ermittlungstaktischen Gründen nicht.

Wer ist betroffen?

Die Warnung richtet sich an alle Kunden der Kiteworks-Plattform, also an Umgebungen für sichere Dateiübertragung (Managed File Transfer), Filesharing, geschützte E-Mail und Web-Formulare. Laut heise gehören in Deutschland mehrere Landesbanken, Versicherungen, ein Medienkonzern, Beratungsunternehmen und Automobilzulieferer zu den Kunden.

• Selbst betriebene Kiteworks-Systeme on-premises oder in eigenen AWS- und Azure-Konten: betroffen, Abschaltung durch den eigenen Admin.
• Von Kiteworks gehostete Instanzen: laut Hersteller keine Aktion nötig, Kiteworks schaltet selbst ab. Mit Ausfall der Plattform im Zeitfenster ist trotzdem zu rechnen.
• Interne, nicht aus dem Internet erreichbare Systeme: ebenfalls abschalten. Kiteworks begründet das damit, dass man nicht sicher sagen könne, welche Zugriffswege es gebe.
• Nicht betroffen: DRACOON, totemo, ownCloud, Zivver, WAMNET und 123Formbuilder, laut Pressemitteilung ausdrücklich ausgenommen.
• Nicht betroffen: Unternehmen ohne Kiteworks, auch wenn sie andere Dateitransfer-Lösungen einsetzen. Für andere Produkte gibt es aus dieser Meldung keinen Handlungsbedarf.

Wie kritisch ist das?

Für Kiteworks-Betreiber ist die Lage heute akut, auch wenn technisch vieles unklar ist. Es gibt keine CVE, kein Advisory mit betroffenen Versionen, keinen Patch speziell für diese Bedrohung und keine öffentlichen Details zum Angriffsweg. Ob ein Angreifer bereits eine unbekannte Lücke ausnutzt oder nur ein Angriff angekündigt wurde, ist öffentlich nicht belegt. Jake Knott von watchTowr sagte Computer Weekly, niemand fordere seine gesamte Kundschaft wegen einer bloßen Ahnung auf, Produktivsysteme übers Wochenende vom Netz zu nehmen.

Der wahrscheinlichste Schaden bei einem erfolgreichen Angriff wäre Datenabfluss. Plattformen für Dateiübertragung bündeln vertrauliche Dokumente an einem Ort und sind deshalb ein bevorzugtes Ziel für Erpressergruppen. Die Clop-Bande hat in der Vergangenheit genau solche Produkte massenhaft angegriffen, darunter Accellion FTA, GoAnywhere MFT, Cleo und MOVEit Transfer. Kiteworks hieß bis Ende 2021 Accellion, die Angriffe auf das alte Accellion-FTA-Produkt trafen damals Hunderte Organisationen. Eine Verbindung der aktuellen Warnung zu Clop oder einer anderen Gruppe ist jedoch nicht belegt, auch nicht durch die berichtenden Medien.

Unser Urteil: Wer Kiteworks selbst betreibt, folgt der Empfehlung vollständig und unabhängig von Version und Netzwerktopologie. Ein Ausfall von sechs bis neun Stunden am Samstagvormittag ist planbar, ein Datenabfluss aus der Plattform für vertrauliche Dateien ist es nicht.

Was sollten Admins jetzt tun?

• Inventar prüfen: Alle Kiteworks-Instanzen erfassen, auch Test-, DR- und Altsysteme, und für jede notieren, ob sie selbst betrieben oder von Kiteworks gehostet ist und welche Version läuft. Ziel ist Version 9.5.1.
• Kunden-E-Mail suchen: Die Warnung von Kiteworks im Postfach der hinterlegten Kontakte finden und die dort genannten Uhrzeiten für die eigene Zeitzone übernehmen. Bei Abweichungen zwischen sechs und neun Stunden das längere Fenster wählen oder beim Support nachfragen.
• Vor dem Fenster abschalten: Selbst betriebene Systeme sauber herunterfahren, nicht nur die Firewall-Freigabe schließen. Kiteworks empfiehlt das Abschalten ausdrücklich schon vor 4:00 Uhr MESZ und auch für interne Systeme.
• Automatische Neustarts verhindern: Prüfen, ob Hypervisor, Cloud-Autoscaling oder Monitoring-Automatik die VM selbstständig wieder startet, und das für den Zeitraum deaktivieren.
• Geschäftspartner informieren: Interne Fachbereiche und externe Partner, die Dateien über Kiteworks austauschen, über den Ausfall informieren. Automatisierte Transfers (SFTP, API, geplante Jobs) für den Zeitraum pausieren.
• Keine unsicheren Ausweichwege: Vertrauliche Dateien während des Ausfalls nicht per unverschlüsselter E-Mail oder privatem Cloud-Speicher verschicken. Nicht dringende Übertragungen verschieben.
• Logs sichern: Vor dem Herunterfahren Audit- und Zugriffsprotokolle exportieren oder sicherstellen, dass sie an ein SIEM weitergeleitet wurden. So lassen sich auffällige Admin-Anmeldungen oder ungewöhnlich große Downloads später prüfen.
• Nicht einfach wieder hochfahren: Vor dem Wiederanlauf auf aktualisierte Hinweise von Kiteworks über Support-Portal und Community achten. Sollte ein Patch oder eine Konfigurationsempfehlung erscheinen, diese vor dem Freischalten nach außen umsetzen.
• Nach dem Wiederanlauf prüfen: Version kontrollieren, Admin-Konten und API-Schlüssel auf unbekannte Einträge durchsehen, Protokolle auf Anmeldungen aus unbekannten Netzen und Massen-Downloads prüfen.
• Notfallkontakte bereithalten: Kiteworks-Support, eigenen Incident-Response-Dienstleister und Datenschutzbeauftragten erreichbar halten, falls sich Hinweise auf eine Kompromittierung ergeben.

Einordnung für Unternehmen

Dass ein Hersteller seine gesamte Kundschaft zur Abschaltung auffordert, ist ungewöhnlich. Üblich sind Notfall-Patches oder Workarounds, nachdem eine Lücke bekannt ist. Hier gibt es die Warnung vor der technischen Beschreibung. Das macht die Lage schwer einzuschätzen, spricht aber eher für eine ernst zu nehmende Quelle als für übertriebene Vorsicht. Heise bezeichnet die Echtheit der Warnung als außer Frage.

Für kleine und mittlere Unternehmen ist Kiteworks eher selten, weil sich die Plattform vor allem an Konzerne, Banken, Behörden und das Gesundheitswesen richtet. KMU können aber indirekt betroffen sein: Wer mit einer Bank, Versicherung oder einem Großkunden Dateien über dessen Kiteworks-Portal austauscht, muss am Samstag mit Ausfällen rechnen und sollte Übergaben entsprechend planen. Eigenen Handlungsbedarf gibt es dann nicht.

Unabhängig von Kiteworks zeigt der Fall, wie wichtig ein geübter Ablauf für das kontrollierte Abschalten eines zentralen Dienstes ist: Wer darf entscheiden, wer informiert Partner, wo liegen Logs, wie läuft der Wiederanlauf. Unternehmen, die heute zum ersten Mal über diese Fragen nachdenken, sollten sie nach dem Wochenende im Notfallhandbuch festhalten. Sobald Kiteworks technische Details, eine CVE oder einen Patch veröffentlicht, ist die Lage neu zu bewerten.

Passende Anleitungen auf S-EDV

• Cybervorfall: die ersten Stunden und Spuren richtig sichern, falls sich nach dem Wiederanlauf Hinweise auf einen Zugriff ergeben.
• IT-Notfallhandbuch nach BSI 200-4 als Vorlage, um geplante Notabschaltungen und Wiederanlauf künftig festzuhalten.
• Ransomware-Notfallplan für die ersten 60 Minuten, für den Fall eines Datenabflusses mit Erpressung.

Quellen

• Kiteworks: Precautionary Shutdown Advisory (Pressemitteilung, 25.09.2026)
• heise security: Kiteworks warnt Admins vor Zero-Day (25.09.2026)
• BleepingComputer: Kiteworks urges 6-hour server shutdown (25.09.2026)
• TechCrunch: Kiteworks urges customers to shut down their servers (25.09.2026)
• Computer Weekly: Expecting cyber attack, Kiteworks tells users to turn off servers (25.09.2026)