Cloudflares schlimmster Ausfall seit 2019: Wie eine einzige Feature-Datei das halbe Internet lahmlegte

An einem Dienstagmorgen Ende November brach das Web zusammen. Es gab keine blinkenden roten Karten und keine unheilvollen Warnungen wie im Hollywood-Cyber-Crash, sondern die leisere, nervigere Variante, die die meisten Menschen kennen: Seiten, die nicht laden, Apps, die endlos laden, und Login-Bildschirme, die plötzlich aufhören zu funktionieren. Wer am 18. November 2025 gegen 11:20 UTC online war, dachte vielleicht, das WLAN habe einen Anfall. Tatsächlich spielte gerade ein Teil des Kreislaufsystems des Internets verrückt, und zwar überall gleichzeitig.

Cloudflare betreibt das, was das Unternehmen selbst „Connectivity Cloud“ nennt: ein weitläufiges globales Netzwerk, das Websites beschleunigt, Angriffe filtert, APIs antreibt, Authentifizierung übernimmt, DNS verwaltet und als Bindegewebe für einen erschreckend großen Teil des globalen Traffics dient. An diesem Tag erlebte der Gigant seinen größten Ausfall seit sechs Jahren. Ein paar Stunden lang tat Cloudflare nichts davon und warf stattdessen 5xx-Fehler wie Konfetti.

Sobald es losging, gerieten alle in Aufruhr: Site-Betreiber, Dev-Teams und normale Nutzer, die die Login-Seite ihrer Bank laden wollten. Auch Cloudflares eigene Ingenieure waren in heller Aufregung. Sie wollten herausfinden, warum die zentralen Proxy-Systeme außer Kontrolle gerieten, warum Bots nicht korrekt bewertet wurden und warum der Traffic alle fünf Minuten zwischen gesundem und kaputtem Zustand hin- und herpendelte.

Von außen fühlte es sich wie ein großer Angriff an, und Cloudflares interne Teams hielten es ebenfalls für einen. Sogar die externe Statusseite fiel aus, obwohl sie außerhalb von Cloudflares Infrastruktur gehostet wird. Dieser Zufall fühlte sich nicht wie Zufall an.

Der Bösewicht war aber weder eine DDoS-Bande noch ein Staatsakteur oder ein neues Botnet, das seine Muskeln spielen ließ. Es war eine Feature-Datei, eine Textdatei, die sich in ihrer Größe verdoppelte und dabei eine Grenze überschritt, die lange unbemerkt auf genau diesen Moment gewartet hatte.

In dieser Datei steckte ein Cluster duplizierter Features, erzeugt durch eine gut gemeinte Änderung an Datenbankberechtigungen. Die Änderung war klein, routinemäßig und theoretisch harmlos, löste aber eine Kettenreaktion aus, die einen gewaltigen Teil des globalen Internet-Traffics lahmlegte. Im Folgenden geht es darum, wie ein einziges Konfigurationsartefakt im Bot-Management-System von Cloudflare das größte Edge-Netzwerk des Planeten lahmlegte.

Der Morgen, an dem das Internet hustete

Das erste Anzeichen von Ärger zeigte sich gegen 11:20 UTC: ein globaler Spike an HTTP-5xx-Fehlern im gesamten Cloudflare-Netzwerk. Solche Fehler sind in freier Wildbahn nicht selten, im Backbone von Cloudflare sollten sie aber niedrig und stabil bleiben. Eine plötzliche Explosion bedeutete, dass sich etwas Ernstes nicht so verhielt, wie es sollte.

Seltsam war neben dem Spike vor allem die Schwingung. Das System fiel aus, erholte sich und fiel wieder aus, in Fünf-Minuten-Intervallen, wie ein merkwürdiger Herzschlag.

Die Ingenieure zogen sofort Metriken, Logs und Traces heran und verfolgten die Idee, dass es sich um einen massiven verteilten Angriff handeln könnte. Sie hatten zuletzt einige gesehen, darunter Hyperscale-Ereignisse im Aisuru-Stil. Die Fehler passten allerdings nicht sauber zu einer klaren Traffic-Signatur. Irgendetwas Internes schlug wild um sich.

Währenddessen sahen Cloudflare-Kunden Fehlerseiten, die so aussahen, als wären ihre Sites innerhalb der Cloudflare-Infrastruktur kaputt. Apps, die von Cloudflare Workers KV abhingen, warfen Fehler. Turnstile lud auf Login-Seiten nicht mehr. Die Authentifizierung in Cloudflare Access funktionierte für alle nicht mehr, die nicht bereits eingeloggt waren. Wer Seiten neu lud, sah kein normales Retry-Verhalten, sondern lief einfach gegen eine Wand.

Im Unternehmen flog eine Flut an Incident-Nachrichten hin und her. Dass zufällig auch Cloudflares externe Statusseite ausfiel, befeuerte den Verdacht auf einen laufenden Angriff. Es war keiner, aber in diesem Moment liefen die Fantasien heiß.

Was noch niemand wusste: Alle fünf Minuten warf Cloudflares Netzwerk eine Münze. Mit einer guten Konfigurationsdatei funktionierte alles, mit einer schlechten geriet der Proxy-Kern in Panik. Welche Datei herauskam, hing davon ab, welcher Datenbank-Node die nächste Query bearbeitete.

Der Auslöser: ein Update der Datenbankberechtigungen, das harmlos wirkte

Die ganze Episode beginnt mit einem ClickHouse-Cluster, also der Datenbank-Engine, die einen Teil von Cloudflares Analytics- und Machine-Learning-Feature-Pipeline antreibt.

ClickHouse-Cluster sind gesharded. Cloudflares Setup umfasst zwei zentrale Datenbankschichten: In default liegen die verteilten Queries, in r0 liegen die zugrunde liegenden Tabellen pro Shard.

Bisher sahen Nutzer, die Metadaten über System-Tabellen (wie system.columns) abfragten, nur die Tabellen im default-Schema. Cloudflares Ingenieure rollten dann eine Änderung aus, damit verteilte Queries im Kontext des auslösenden Nutzers laufen statt unter einem gemeinsamen Systemkonto. Das Ziel war vernünftig: weniger breite Berechtigungen, bessere Isolation und engere Kontrolle.

Um 11:05 UTC ging ein Berechtigungs-Update live, durch das Datenbanknutzer die zugrunde liegenden Tabellen in r0 nun ebenfalls explizit sehen konnten. Genau an dieser Stelle lief es aus dem Ruder.

Die Query, mit der Cloudflares Bot-Management-Feature-Datei erzeugt wurde, sah so aus:

SELECT name, type
FROM system.columns
WHERE table = 'http_requests_features'
ORDER BY name;

Ihr fehlt ein Filter auf die Datenbank. Vor der Berechtigungsänderung spielte das keine Rolle, weil das System nur die Metadaten einer Tabelle zeigte. Nach der Änderung lieferte die Query plötzlich zwei Sätze identisch aussehender Features, einen aus dem default-Schema und einen aus r0.

Damit gab es jedes Feature doppelt, und die resultierende Feature-Datei war praktisch doppelt so groß.

Diese Datei ist kein obskurer Log-Dump, den niemand liest. Sie speist das Machine-Learning-Modell, das beim Bot-Scoring jede Cloudflare-Anfrage bewertet, und der Kern-Proxy auf jeder Cloudflare-Maschine lädt sie häufig in den Speicher. Sie gehört zu den zeitkritischsten Konfigurationsstücken, die Cloudflare erzeugt, ständig aktualisiert und überallhin ausliefert.

Jeder Proxy-Worker-Prozess hatte eine strikte Grenze von 200 Features. Normale Modelle nutzten ~60, die Ingenieure hatten also reichlich Spielraum, bis dieser Spielraum plötzlich weg war.

Sobald die Datei diese Obergrenze überschritt, rannte der Proxy im Feature-Loader frontal in eine unbehandelte Fehlerbedingung und löste einen Rust-Panic in FL2 aus, der neueren Generation von Cloudflares Frontline-Proxy-Engine. Auf den Panic folgte der Absturz und darauf überall 5xx-Fehler.

Warum das Netzwerk weiter flackerte

Alle fünf Minuten baute ein geplanter Job die Bot-Feature-Datei neu auf. Nur manche Nodes im ClickHouse-Cluster hatten aber schon die neuen Berechtigungen. Je nachdem, welcher Node die Query gerade bearbeitete, erzeugte Cloudflare also entweder:

• eine gültige Feature-Konfigurationsdatei

oder

• eine schlechte, die zu groß zum Laden war

Mit der guten Datei erholte sich das Netz weltweit, mit der schlechten fiel es weltweit aus.

Dieser Roulette-Effekt machte die frühe Untersuchung extrem verwirrend. Immer wenn ein Team glaubte, das Problem stabilisiere sich, konnte der nächste Verteilungs-Tick das Netzwerk sofort wieder zum Absturz bringen.

Irgendwann hatte das Rollout der Berechtigungen jeden Node erreicht. Ab dann hörte das Netzwerk auf zu flackern, weil die Feature-Datei jedes Mal schlecht war und jedes Mal alles zum Absturz brachte. Erst in diesem Moment pendelte sich der Ausfall in einen stabilen, klaren Fehlerzustand ein.

Die Kaskade: KV-Ausfälle, Login-Ausfälle, fehlende Bot-Scores

Als der Kern-Proxy erstickte, fielen die nachgelagerten Subsysteme wie Dominosteine um.

Bei Workers KV hängt das Frontend-Gateway vom Proxy-Pfad ab, und die 5xx-Fehler schossen in die Höhe.

Turnstile, Cloudflares Widget zur menschlichen Verifizierung, lud schlicht nicht mehr. Wer sich bei einem Dashboard mit Turnstile auf der Seite anmelden wollte, wurde blockiert.

In Access brach die Authentifizierung für neue Sessions zusammen. Bereits eingeloggte Nutzer waren in Ordnung, alle anderen bekamen Fehlerseiten.

Beim Cloudflare-Dashboard konnten sich die meisten Nutzer während großer Teile des Ausfalls nicht einloggen. Als die Lage später teilweise wiederhergestellt war, erzeugte ein Ansturm an Wiederholungsversuchen seinen eigenen kleinen Verkehrsstau.

Und Bot Management selbst? Auf der älteren FL-Proxy-Engine schlugen die Bot-Scores nicht fehl, sie fielen auf null. Kunden, die auf Basis des Bot-Scores blockierten, blockierten dadurch plötzlich alles, mit Falsch-Positiven überall.

Hier spann also nicht irgendein Randbereich von Cloudflare, sondern der Kern des Kerns.

Die Diagnose: der lange Weg vom Verdacht zur Grundursache

Die Ingenieure bemerkten Lastspitzen, Wiederholungsversuche und merkwürdiges Verhalten. Sie versuchten es mit Rate-Limiting und Traffic-Verschiebungen, um das System zu stabilisieren, doch nichts half.

Um 13:05 UTC, fast zwei Stunden nach Beginn der Auswirkungen, begann das Team, den Kern-Proxy für Workers KV und Access zu umgehen. Das linderte manche Symptome und verschaffte Luft.

Bis 13:37 UTC hatten die Teams die Bot-Management-Konfigurationsdatei als Auslöser im Visier. Mehrere Workstreams liefen parallel an: ClickHouse untersuchen, Datenbankänderungen zurückrollen, Gerätelogs studieren und die Pipeline zur Erzeugung der Feature-Datei zurückverfolgen.

Um 14:24 UTC stoppte Cloudflare schließlich die Erzeugung und Verteilung neuer Feature-Dateien, spielte eine bekanntermaßen gute Version ein und verteilte sie global.

Um 14:30 atmete das Internet auf, und der Kern-Traffic floss wieder.

Der Rest des Ausfalls bis 17:06 UTC bestand aus Aufräumarbeiten: Dienste neu starten, Warteschlangen leeren, Caches stabilisieren und fehlerhafte Zustände bereinigen.

Die Grundursache war da längst gefunden. Tief in einem Skript zur Feature-Generierung steckte die unausgesprochene Annahme, dass eine Query immer eine Spaltenliste fester Größe zurückgibt.

Cloudflare redete nichts schön: Das hätte nie passieren dürfen

Cloudflares CEO schrieb die Aufschlüsselung nach dem Vorfall selbst. Das ist ungewöhnlich und zeigt, wie ernst die Sache war.

Es war der schlimmste Ausfall des Unternehmens seit 2019, und Cloudflare versuchte nicht, ihn schönzureden. Die Fehler lagen offen:

• Eine Änderung an Datenbankberechtigungen veränderte das Query-Verhalten auf unerwartete Weise.

• Einer kritischen ML-Konfigurationsdatei fehlten Schutzmechanismen gegen fehlerhaften Inhalt.

• Der Kern-Proxy scheiterte nicht kontrolliert, als Grenzwerte überschritten wurden; er geriet in Panik.

• Die Systeme zur Fehlerdiagnose verbrauchten selbst genug CPU, um Ausfälle zu verschlimmern.

• Kein Kill-Switch verhinderte die Verteilung der defekten Konfiguration.

• Die Rollout-Pipeline für die Feature-Datei vertraute internen Daten ungeprüft.

Für ein Unternehmen, das sich Resilienz, Redundanz und Fehlerisolation auf Netzwerkebene auf die Fahnen schreibt, tut diese Liste weh.

Ein sehr menschlicher Moment: die Angst vor einem koordinierten Angriff

Ein Detail fiel in der Diskussion der Community besonders auf: Cloudflares Ingenieure hielten den Ausfall ernsthaft für einen möglichen Angriff. Die Statusseite fiel unabhängig davon und rein zufällig aus, was so aussah, als greife jemand Cloudflare und dessen externen Health-Checker gleichzeitig an. Das stimmte nicht, machte die ersten Minuten aber chaotisch.

Kunden äußerten online denselben Verdacht. Nach einem Jahr voller massiver Cloud-Ausfälle bilden sich die Leute keine Bedrohungen ein. Sie haben genug erlebt, um zu wissen, dass es oft kein Zufall ist, wenn das Internet aufstöhnt.

Reaktionen der Community: Frust, Verwirrung und einige scharfe Fragen

In den Diskussionen rund um den Ausfall kamen handfeste Bedenken auf.

Warum dauerte die Diagnose so lange? Kommentatoren fragten sich, warum das Change-Management das ClickHouse-Update nicht sofort sichtbar machte.

Sollte Cloudflare Kunden entschädigen? Das SLA sieht technisch gesehen Gutschriften vor, doch Nutzer halten dagegen, dass diese die tatsächlichen geschäftlichen Auswirkungen nicht abdecken.

Warum wirken Cloudflare-Ausfälle in letzter Zeit häufiger? Manche verwiesen auf jüngste Probleme bei anderen großen Clouds und meinten, die Zuverlässigkeit der ganzen Branche wirke wackliger.

Warum liegt Bot Management im kritischen Anfragepfad? Technisch ergibt das Sinn, es schafft aber einen Single Point of Misconfiguration, den kaum ein Kunde auf dem Schirm hat.

Wutkommentare waren das nicht. Es waren praktische Fragen von Menschen, die darauf angewiesen sind, dass Cloudflare langweilig, konsistent und unsichtbar bleibt.

Die Lösung und der Weg nach vorn

Cloudflare legte die Maßnahmen aus dem Post-Mortem klar dar:

• Interne Konfigurationsdateien beim Einlesen genauso streng prüfen wie nicht vertrauenswürdige Nutzereingaben

• Globale Kill-Switches hinzufügen, um außer Kontrolle geratene Config-Rollouts zu verhindern

• Fehlerbehandlung über alle Proxy-Module hinweg verbessern

• Sicherstellen, dass Debug-Systeme die CPUs während Ausfällen nicht überlasten

• Grenzwerte und Annahmen zur Speicherzuweisung überdenken

Die Liste ist ambitioniert, aber Cloudflare hat eine Vorgeschichte: Auf jeden größeren Ausfall folgte eine architektonische Verbesserung. Gerade wegen vergangener Ausfälle ist das Netzwerk heute widerstandsfähiger als 2019, und nach diesem wird es noch kampferprobter sein.

Eine einzige Datei, eine globale Kettenreaktion

Man muss sich das vorstellen: Eine verdoppelte Feature-Datei, ein einfaches Datenartefakt und kein Code, konnte Workloads über Kontinente hinweg zu Fall bringen. So sieht die Welt vernetzter Systeme aus, in der die kleinste interne Annahme einen planetaren Explosionsradius haben kann.

Hinter diesem Ausfall steckten kein Hacker und kein außer Kontrolle geratenes Botnet. Eine routinemäßige Berechtigungsänderung legte eine versteckte Abhängigkeit frei, und die Folgen vervielfachten sich innerhalb von Minuten über Zehntausende Maschinen.

Cloudflare entschuldigte sich, übernahm die Verantwortung für den Fehler und begann mit der Post-Mortem-Arbeit. Die Lehre daraus gilt aber weit über Cloudflare hinaus. Das Internet besteht heute aus verteilten Systemen, die alle den Daten, Pipelines und selbstaktualisierenden Agenten der jeweils anderen vertrauen, und wenn eine Annahme bricht, spürt alles dahinter die Folgen. Beruhigend ist das nicht, aber so funktioniert das moderne Web.

Am 18. November 2025 verdoppelte sich eine Feature-Datei in ihrer Größe, und für ein paar Stunden schrumpfte das Internet mit ihr.