Cloudflare-Ausfall am 18. November 2025

Am 18. November 2025 um 11:20 Uhr UTC (alle Zeiten in diesem Blog sind in UTC angegeben) begannen im Cloudflare-Netzwerk erhebliche Ausfälle bei der Übermittlung des zentralen Netzwerk-Traffics. Dies wurde Internetnutzern, die auf die Websites unserer Kunden zugreifen wollten, als Fehlerseite angezeigt, was auf einen Ausfall im Cloudflare-Netzwerk hinwies.

Das Problem wurde weder direkt noch indirekt durch einen Cyberangriff oder böswillige Aktivität jeglicher Art verursacht. Stattdessen wurde dies durch eine Änderung der Berechtigungen eines unserer Datenbanksysteme ausgelöst, wodurch die Datenbank mehrere Einträge in eine „Feature-Datei“ ausgab, die von unserem Bot-Management-System verwendet wird. Diese Feature-Datei hat sich dadurch in ihrer Größe verdoppelt. Die Feature-Datei, die größer als erwartet war, wurde dann an alle Rechner unseres Netzwerks weitergegeben.

Die Software, die auf diesen Maschinen läuft, um den Datenverkehr in unserem Netzwerk zu leiten, liest diese Feature-Datei, um unser Bot-Management-System mit den sich ständig ändernden Bedrohungen aktuell zu halten. Die Software hatte eine Größenbeschränkung für die Feature-Datei, die kleiner als ihre doppelte Größe war. Dies führte zum Ausfall der Software.

Nachdem wir anfänglich fälschlicherweise vermutet hatten, dass die beobachteten Symptome durch einen großangelegten DDoS-Angriff verursacht wurden, konnten wir das Kernproblem korrekt identifizieren, die Verbreitung der unerwartet großen Feature-Datei stoppen und sie durch eine frühere Version ersetzen. Um 14:30 Uhr floss der Kerntraffic weitgehend normal. In den folgenden Stunden arbeiteten wir daran, die erhöhte Last auf verschiedene Teile unseres Netzwerks zu reduzieren, als der Datenverkehr wieder online ging. Um 17:06 Uhr funktionierten alle Systeme bei Cloudflare normal.

Wir entschuldigen uns aufrichtig für die Beeinträchtigungen, die sowohl unsere Kunden als auch das Internet als Ganzes betroffen haben. Angesichts der Bedeutung von Cloudflare im Internet-Ökosystem ist jeder Ausfall unserer Systeme inakzeptabel. Dass unser Netzwerk zeitweise keinen Datenverkehr weiterleiten konnte, schmerzt jedes Mitglied unseres Teams zutiefst. Wir wissen, dass wir Sie heute enttäuscht haben.

Dieser Beitrag ist eine ausführliche Schilderung dessen, was genau passiert ist und welche Systeme und Prozesse versagt haben. Es ist auch der Anfang, aber nicht das Ende dessen, was wir planen, um sicherzustellen, dass ein solcher Ausfall sich nicht wiederholt.

Die nachstehende Grafik zeigt das Volumen der vom Cloudflare-Netzwerk bereitgestellten 5xx-Fehler-HTTP-Statuscodes. Normalerweise sollte dieser Wert sehr niedrig sein, und das war er auch bis zum Beginn des Ausfalls.

Vor 11:20 bewegte sich die Zahl der 5xx-Fehler im gesamten Netzwerk auf dem erwarteten Normalniveau. Der Spitzenwert und die anschließenden Schwankungen zeigen, dass unser System aufgrund des Ladens der falschen Feature-Datei ausfällt. Bemerkenswert ist, dass sich das System anschließend zeitweise wieder erholte – ein sehr ungewöhnliches Verhalten für einen internen Fehler.

Die Erklärung war, dass die Datei alle fünf Minuten durch eine Abfrage generiert wurde, die auf einem ClickHouse-Datenbankcluster lief, welcher schrittweise aktualisiert wurde, um die Berechtigungsverwaltung zu verbessern. Fehlerhafte Daten wurden nur generiert, wenn die Abfrage auf einem Teil des Clusters ausgeführt wurde, der aktualisiert worden war. Infolgedessen bestand alle fünf Minuten die Möglichkeit, dass entweder gute oder schlechte Konfigurationsdateien generiert und schnell im Netzwerk verbreitet wurden.

Diese Schwankungen erschwerten das Verständnis der Lage, da sich das gesamte System zunächst erholte, um dann erneut auszufallen – je nachdem, ob funktionierende oder fehlerhafte Konfigurationsdateien im Netzwerk verteilt wurden. Anfangs vermuteten wir sogar einen Angriff als Ursache. Letztlich erzeugte jedoch jeder ClickHouse-Knoten die fehlerhafte Konfiguration, und die Schwankung stabilisierte sich im fehlerhaften Zustand.

Die Fehler traten weiterhin auf, bis das zugrunde liegende Problem ab 14:30 erkannt und behoben wurde. Wir lösten das Problem, indem wir die Erzeugung und Verbreitung der fehlerhaften Feature-Datei stoppten, eine bekannte, funktionierende Datei manuell in die Verteilungswarteschlange einfügten und anschließend einen Neustart unseres zentralen Proxys erzwangen.

Der verbleibende lange Nachlauf in der obigen Grafik zeigt, wie unser Team nach und nach die verbleibenden Dienste neu startete, die sich in einem fehlerhaften Zustand befanden. Das Volumen der 5xx-Fehlercodes kehrte um 17:06 auf den Normalwert zurück.

Die folgenden Dienste waren betroffen:

Neben der Rückgabe von HTTP-5xx-Fehlern stellten wir während des Vorfallszeitraums auch eine deutliche Erhöhung der Latenzzeiten bei Antworten unseres CDN fest. Ursache hierfür war ein hoher CPU-Verbrauch durch unsere Debugging- und Observability-Systeme, die unbehandelte Fehler automatisch mit zusätzlichen Diagnosedaten anreicherten.

Jede Anfrage an Cloudflare nimmt einen klar definierten Pfad durch unser Netzwerk. Sie kann aus einem Browser stammen, der eine Webseite lädt, aus einer mobilen App, die eine API aufruft, oder aus automatisiertem Traffic eines anderen Dienstes. Diese Anfragen treffen zuerst auf unserer HTTP- und TLS-Schicht ein, fließen dann in unser zentrales Proxy-System (das wir FL für „Frontline“ nennen) und schließlich durch Pingora, das Cache-Abfragen durchführt oder bei Bedarf Daten vom Ursprung abruft.

Wir haben bereits zuvor an dieser Stelle nähere Informationen über die Funktionsweise des Core-Proxys veröffentlicht. 

Während eine Anfrage den Core-Proxy durchläuft, führen wir die verschiedenen Sicherheits- und Performance-Produkte aus, die in unserem Netzwerk verfügbar sind. Dabei werden die individuellen Konfigurationen und Einstellungen jedes Kunden berücksichtigt, von der Durchsetzung von WAF-Regeln und DDoS-Schutz bis hin zur Weiterleitung des Datenverkehrs an die Entwicklerplattform und R2. Dies wird durch eine Reihe von bereichspezifischen Modulen erreicht, die die Konfigurations- und Richtlinienregeln auf den Datenverkehr anwenden, der unseren Proxy durchläuft.

Eines dieser Module, Bot-Management, war die Ursache für den heutigen Ausfall. 

Das Bot-Management von Cloudflare umfasst unter anderem ein Machine-Learning-Modell, mit dem wir Bot-Scores für jede Anfrage, die unser Netzwerk durchläuft, generieren. Mithilfe von Bot-Scores steuern unsere Kunden, welche Bots Zugriff auf ihre Websites erhalten – oder eben nicht.

Das Modell nimmt als Eingabe eine „Feature“-Konfigurationsdatei. Ein Feature ist in diesem Kontext ein individuelles Merkmal, das vom Machine-Learning-Modell verwendet wird, um vorherzusagen, ob die Anfrage automatisiert wurde oder nicht. Die Feature-Konfigurationsdatei ist eine Sammlung einzelner Features.

Diese Feature-Datei wird alle paar Minuten aktualisiert und in unserem gesamten Netzwerk veröffentlicht. Dies ermöglicht es uns, auf Schwankungen der Traffic-Flüsse im Internet zu reagieren. Es lässt uns auch auf neue Arten von Bots und Bot-Angriffen reagieren. Daher ist es entscheidend, dass sie regelmäßig und schnell ausgerollt wird, da böswillige Akteure ihre Taktiken ständig ändern.

Eine Änderung im zugrunde liegenden ClickHouse-Abfrageverhalten (weiter unten erläutert) führte dazu, dass die generierte Datei eine große Anzahl doppelter „Feature“-Zeilen enthielt. Dadurch änderte sich die Größe der zuvor fest definierten Feature-Konfigurationsdatei, was im Bots-Modul einen Fehler auslöste.

Infolgedessen gab das zentrale Proxy-System, das den Datenverkehr für unsere Kunden verarbeitet, HTTP-5xx-Fehlercodes für jeglichen Traffic zurück, der vom Bots-Modul abhängig war. Davon waren auch Workers KV und Access betroffen, die sich auf den Core-Proxy verlassen.

Unabhängig von diesem Vorfall migrieren wir derzeit den Kundenverkehr auf eine neue Version unseres Proxy-Dienstes, intern als FL2 bezeichnet. Beide Versionen waren von dem Problem betroffen, jedoch in unterschiedlichem Ausmaß.

Kunden, die die neue FL2-Proxy-Engine einsetzten, beobachteten HTTP-5xx-Fehler. Kunden unserer alten Proxy-Engine, bekannt als FL, verzeichneten keine Fehler, aber die Bot-Bewertungen wurden nicht korrekt generiert, was dazu führte, dass der gesamte Traffic eine Bot-Bewertung von Null erhielt. Kunden, die Regeln zur Blockierung von Bots eingerichtet hatten, registrierten eine große Anzahl falscher Positivmeldungen. Kunden, die den Bot-Score nicht in ihren Regeln verwendeten, hatten keine Auswirkungen.

Was uns zusätzlich in die Irre führte und den Verdacht auf einen Angriff lenkte, war ein weiteres auffälliges Symptom: die Statusseite von Cloudflare war nicht erreichbar. Die Statusseite wird vollständig außerhalb der Cloudflare-Infrastruktur gehostet und weist keinerlei Abhängigkeiten zu Cloudflare auf. Auch wenn sich dies später als bloßer Zufall herausstellte, ließ es einige Mitglieder des Diagnose-Teams vermuten, dass ein Angreifer sowohl unsere Systeme als auch die Statusseite ins Visier genommen haben könnte. Besucher der Statusseite sahen zu diesem Zeitpunkt eine Fehlermeldung:

Im internen Chat-Raum für den Vorfall waren wir besorgt, dass sich die jüngste Flut von Aisuru-DDoS-Angriffen mit hohem Volumen fortsetzen könnte:

Wie oben erwähnt, führte eine Änderung im zugrunde liegenden Abfrageverhalten dazu, dass die Feature-Datei eine große Anzahl doppelter Zeilen enthielt. Das verwendete Datenbanksystem basiert auf der Software von ClickHouse.

Zum besseren Verständnis ist es hilfreich zu wissen, wie verteilte Abfragen in ClickHouse funktionieren. Ein ClickHouse-Cluster besteht aus mehreren Shards. Um Daten aus allen Shards abzufragen, verwenden wir sogenannte Distributed-Tabellen (basierend auf der Tabellen-Engine Distributed) in einer Datenbank mit dem Namen default. Die Distributed-Engine greift auf zugrunde liegende Tabellen in der Datenbank r0 zu. Diese Tabellen enthalten die Daten, die auf jedem Shard eines ClickHouse-Clusters gespeichert sind.

Abfragen an die Distributed-Tabellen werden derzeit über ein gemeinsames Systemkonto ausgeführt. Im Rahmen unserer Bemühungen zur Verbesserung der Sicherheit und Zuverlässigkeit verteilter Abfragen arbeiten wir daran, diese künftig unter den ursprünglichen Benutzerkonten auszuführen.

Bis heute konnten ClickHouse-Nutzer beim Abfragen von Tabellen-Metadaten über Systemtabellen wie system.tables oder system.columns ausschließlich die Tabellen in der Datenbank default sehen.

Da die Nutzer bereits impliziten Zugriff auf die zugrunde liegenden Tabellen in r0 haben, haben wir um 11:05 Uhr eine Änderung vorgenommen, um diesen Zugriff explizit zu gestalten, sodass die Nutzer auch die Metadaten dieser Tabellen einsehen können. Indem sichergestellt wird, dass alle verteilten Unterabfragen mit den Berechtigungen des ursprünglichen Benutzers ausgeführt werden können, lassen sich Abfragelimits und Zugriffsberechtigungen detaillierter auswerten. Dadurch wird vermieden, dass eine fehlerhafte Unterabfrage eines Benutzers andere beeinträchtigt.

Die oben erklärte Änderung führte dazu, dass alle Benutzer nun präzise Metadaten zu den Tabellen erhalten, auf die sie Zugriff haben. Leider wurde in der Vergangenheit angenommen, dass eine Abfrage dieser Art nur Spalten aus der Datenbank „default“ zurückliefern würde.

SELECT name, type FROM system.columns WHERE table = 'http_requests_features' order by name;

Beachten Sie, dass die Abfrage keinen Filter auf den Datenbanknamen anwendet. Mit der schrittweisen Einführung expliziter Berechtigungen für Nutzer eines bestimmten ClickHouse-Clusters begann die Abfrage nach der Änderung um 11:05 damit, „Duplikate“ von Spalten zurückzugeben – diese stammten aus den zugrunde liegenden Tabellen in der Datenbank r0.

Dies war leider die Art von Abfrage, die von der Logik zur Feature-Dateigenerierung im Bot-Management ausgeführt wurde, um jedes Eingabe-„Feature“ für die am Anfang dieses Abschnitts erwähnte Datei zu erstellen. 

Die obige Abfrage würde eine Tabelle mit Spalten ähnlich der angezeigten zurückgeben (vereinfachtes Beispiel):

Im Rahmen der zusätzlichen Berechtigungen, die dem Benutzer gewährt wurden, enthielt die Antwort nun jedoch alle Metadaten des r0-Schemas, wodurch sich die Anzahl der Zeilen in der Antwort mehr als verdoppelte, was sich letztendlich auf die Anzahl der Zeilen (d. h. Features) in der endgültigen Dateiausgabe auswirkte. 

Jedes Modul, das auf unserem Proxy-Dienst ausgeführt wird, verfügt über eine Reihe von Beschränkungen, um einen unbegrenzten Speicherverbrauch zu vermeiden und Speicher zur Performance-Optimierung vorab zuzuweisen. In diesem speziellen Fall ist die Anzahl der Machine-Learning-Funktionen, die zur Laufzeit von dem Bot-Management-System verwendet werden können, begrenzt. Derzeit liegt diese Grenze bei 200, was deutlich über unserer aktuellen Nutzung von ca. 60 Features liegt. Auch hier besteht die Beschränkung, da wir aus Performance-Gründen Speicher für die Features vorab zuweisen.

Als die fehlerhafte Datei mit mehr als 200 Funktionen auf unsere Server übertragen wurde, wurde dieses Limit erreicht, was zu einem Systemabsturz führte. Der FL2-Rust-Code, der die Prüfung durchführt und die Ursache des unbehandelten Fehlers war, wird im Folgenden dargestellt:

Dies führte zu folgender Panik, die wiederum zu einem 5xx-Fehler führte:

thread fl2_worker_thread panicked: called Result::unwrap() on an Err value

Andere Systeme, die auf unseren Core-Proxy angewiesen sind, waren während des Vorfalls betroffen. Dies umfasste Workers KV und Cloudflare Access. Das Team konnte die Auswirkungen auf diese Systeme um 13:04 Uhr reduzieren, als ein Patch für Workers KV erstellt wurde, um den Core-Proxy zu umgehen. In der Folge verzeichneten alle nachgelagerten Systeme, die auf Workers KV angewiesen sind (wie beispielsweise Access), eine reduzierte Fehlerrate. 

Das Cloudflare-Dashboard war ebenfalls beeinträchtigt, da sowohl Workers KV intern verwendet wurde als auch Cloudflare Turnstile im Rahmen unseres Anmeldevorgangs eingesetzt wurde.

Turnstile war von diesem Ausfall betroffen, wodurch sich Kunden ohne aktive Dashboard-Sitzung nicht anmelden konnten. Dies zeigte sich in einer eingeschränkten Verfügbarkeit während zweier Zeiträume: von 11:30 Uhr bis 13:10 Uhr und zwischen 14:40 Uhr und 15:30 Uhr, wie die folgende Grafik verdeutlicht.

Der erste Zeitraum von 11:30 bis 13:10 Uhr wurde durch die Auswirkungen auf Workers KV verursacht, von dem einige Funktionen der Steuerungsebene und des Dashboards abhängen. Dies wurde um 13:10 Uhr wiederhergestellt, als Workers KV das zentrale Proxy-System umging. Der zweite Beeinträchtigungszeitraum des Dashboards trat nach der Wiederherstellung der Feature-Konfigurationsdaten auf. Ein Rückstau von Anmeldeversuchen begann, das Dashboard zu überlasten. Dieser Rückstau führte in Kombination mit Wiederholungsversuchen zu erhöhter Latenzzeit, wodurch die Dashboard-Verfügbarkeit reduziert wurde. Durch die Skalierung der Steuerungsebenen-Konkurrenzfähigkeit wurde die Verfügbarkeit um ca. 15:30 Uhr wiederhergestellt.

Jetzt, da unsere Systeme wieder online sind und normal funktionieren, wurde bereits damit begonnen, sie zukünftig besser vor solchen Ausfällen zu schützen. Insbesondere machen wir Folgendes:

• Härtung der Erfassung von Cloudflare-generierten Konfigurationsdateien auf die gleiche Weise wie bei benutzergenerierten Eingaben

• Aktivierung von mehr globalen Kill-Switches für Funktionen

• Verhindern, dass Core-Dumps oder andere Fehlerberichte die Systemressourcen überlasten

• Überprüfung der Fehlermodi auf Fehlerbedingungen in allen Core-Proxy-Modulen

Der heutige Tag war der schlimmste Ausfall von Cloudflare seit 2019. Es kam zu solchen Ausfällen, die dazu führten, dass unser Dashboard nicht verfügbar war. Einige Probleme haben dazu geführt, dass neuere Funktionen für einen bestimmten Zeitraum nicht verfügbar waren. Aber in den letzten mehr als sechs Jahren hatten wir keinen weiteren Ausfall, der dazu geführt hätte, dass der Großteil des Kernnetzwerkverkehrs durch unser Netzwerk unterbrochen wurde.

Ein Ausfall wie der heutige ist inakzeptabel. Wir haben unsere Systeme so konzipiert, dass sie äußerst ausfallsicher sind, um sicherzustellen, dass der Traffic immer fließt. Wenn es in der Vergangenheit zu Ausfällen kam, führte dies immer dazu, dass wir neue, resilientere Systeme entwickelten.

Im Namen des gesamten Teams bei Cloudflare möchte ich mich für die Unannehmlichkeiten entschuldigen, die wir dem Internet heute bereitet haben.