Cloudflare-Ausfall November 2025: Wie eine Datenbankänderung das Internet lahmlegte

Massenausfall durch interne Konfigurationspanne

Der 18. November 2025 wird in die Geschichte der Internet-Infrastruktur eingehen. Ab 11:20 UTC verzeichnete Cloudflare massive Ausfälle, die sich über mehrere Stunden erstreckten. Websites, die auf die CDN- und Sicherheitsdienste des Unternehmens setzen, zeigten nur noch Fehlermeldungen an. Die Ursache war weder ein Cyberangriff noch böswillige Aktivitäten – sondern eine interne Änderung am ClickHouse-Datenbanksystem.

Die Modifikation der Zugriffsberechtigungen sollte eigentlich die Sicherheit erhöhen. Stattdessen löste sie eine verhängnisvolle Kettenreaktion aus. Eine zentrale Konfigurationsdatei für das Bot-Management-System begann plötzlich, doppelte Einträge zu generieren. Die Datei, die üblicherweise rund 60 Machine-Learning-Features enthält, schwoll auf mehr als 200 Einträge an.

Wenn Größenlimits zum Verhängnis werden

Die aufgeblähte Konfigurationsdatei sprengte die fest programmierten Speichergrenzen der Proxy-Software. Das Resultat: Systemabstürze auf breiter Front. Jedes Mal, wenn die Software versuchte, die überdimensionierte Datei zu laden, kapitulierte sie.

Die Situation wurde durch ein besonders heimtückisches Muster verschärft. Da die fehlerhafte Datei automatisch alle fünf Minuten regeneriert wurde und die Datenbankknoten schrittweise aktualisiert wurden, entstanden fehlerhafte Daten nur sporadisch. Systeme fielen aus, schienen sich zu erholen und brachen dann erneut zusammen – ein Auf und Ab, das die Fehlersuche massiv erschwerte.

Fehlalarm DDoS-Attacke verzögerte Lösung

Das oszillierende Verhalten der Systeme brachte die Cloudflare-Techniker zunächst auf eine falsche Spur. Die Anzeichen deuteten für sie auf einen großangelegten DDoS-Angriff hin – zumal zeitgleich auch die externe Statusseite des Unternehmens nicht erreichbar war. In internen Kommunikationskanälen wurde über mögliche Verbindungen zu den kürzlich beobachteten Aisuru-Angriffen spekuliert.

Wertvolle Zeit verging, während das Team Angriffsszenarien untersuchte, bevor es das eigentliche Problem erkannte: eine selbst verschuldete Konfigurationskrise.

Dominoeffekt durch die gesamte Infrastruktur

Die Auswirkungen zogen weite Kreise durch das Cloudflare-Ökosystem. Das Kern-CDN lieferte HTTP-5xx-Fehler aus, die Turnstile-Authentifizierung versagte ihren Dienst und verhinderte Dashboard-Logins. Workers KV meldete drastisch erhöhte Fehlerraten, die Access-Authentifizierung funktionierte nur noch für bereits angemeldete Nutzer.

Selbst das E-Mail-Security-System litt unter Kollateralschäden: Ohne Zugriff auf Reputationsdatenbanken sank vorübergehend die Präzision der Spam-Erkennung.

Notfallmaßnahmen und schrittweise Erholung

Die Reaktionskette begann um 11:32 UTC mit automatisierten Alarmmeldungen, doch das volle Ausmaß der Katastrophe wurde erst allmählich sichtbar. Zunächst konzentrierten sich die Teams auf Workers KV und versuchten verschiedene Gegenmaßnahmen – von Traffic-Umleitung bis zu Account-Limitierungen.

Der Durchbruch gelang um 13:37 UTC mit der Identifizierung der Grundursache. Um 14:24 UTC stoppten die Ingenieure die automatische Generierung der problematischen Konfigurationsdateien. Sie spielten manuell eine getestete, funktionierende Version ein und erzwangen einen umfassenden Proxy-Neustart.

Um 14:30 UTC normalisierte sich der Hauptverkehr wieder. Die komplette Wiederherstellung aller Dienste zog sich jedoch bis 17:06 UTC hin, während nacheinander betroffene Systeme neu gestartet und Warteschlangen abgearbeitet wurden.

Versprechen für mehr Resilienz

Cloudflare gestand öffentlich ein, dass dies der gravierendste Ausfall seit dem Jahr 2019 war. Das Unternehmen kündigte einen umfassenden Maßnahmenkatalog an: Konfigurationsdateien sollen künftig denselben strengen Validierungsprozessen unterliegen wie externe Benutzereingaben. Zusätzliche globale Notausschalter für Features werden implementiert. Error-Handling-Mechanismen werden überarbeitet, um zu verhindern, dass Fehlerberichte selbst zum Ressourcenproblem werden.

Die Lehre: Vertrauen ist gut, Validierung ist besser

Der Vorfall offenbart eine unbequeme Wahrheit über moderne Internet-Infrastruktur: Selbst minimal erscheinende Änderungen können katastrophale Auswirkungen haben, wenn sie nicht in allen Dimensionen durchdacht sind. Hardcodierte Limits, fehlende Validierung interner Datenquellen und unzureichende Testabdeckung für Randfälle – all das summierte sich zu einem perfekten Sturm.

Für ein Unternehmen, das einen substanziellen Teil der globalen Internet-Infrastruktur betreibt, ist dies mehr als nur ein technisches Versagen. Es ist eine nachdrückliche Mahnung, dass mit großer Marktmacht auch eine außergewöhnliche Verantwortung einhergeht – und dass diese Verantwortung robuste Sicherungsmechanismen auf allen Ebenen erfordert.