Cloudflare: Globaler Ausfall verursacht durch Bot-Management-Konfigurationsdatei

Unternehmen und Produkt

Cloudflare betreibt eine globale Connectivity Cloud, die Internetverkehr für Millionen von Properties absichert und beschleunigt – CDN, DDoS-Schutz, Zero-Trust-Zugriff, DNS und Developer-Services. Cloudflares Reichweite ist schwer zu überschätzen. Stand Dezember 2025 laufen rund ein Fünftel aller Websites (20,5 %) hinter Cloudflares Reverse Proxy, was laut W3Techs etwa 81 % Anteil am Reverse-Proxy-Markt bedeutet. Das Anycast-Netz des Unternehmens umfasst 300+ Städte, ist mit 12.000+ Netzwerken verbunden und erreicht bis zu 95 % der Weltbevölkerung innerhalb von rund 50 ms. Eine Verteilung, die Cloudflare faktisch zu einer Edge-Schicht für einen massiven Teil des Internets macht.

‍

An gewöhnlichen Tagen verarbeitet Cloudflare zig Millionen HTTP-Requests pro Sekunde und nimmt Hunderte Millionen Events pro Sekunde in seine Analytics-Pipelines auf – Zahlen, die unterstreichen, wie tief die Services auf dem Hot Path des globalen Traffics sitzen. Über CDN und Security hinaus betreibt Cloudflare auch den öffentlichen DNS-Resolver 1.1.1.1 und veröffentlicht aggregierte Einblicke über Cloudflare Radar – ein Hinweis auf die Doppelrolle der Plattform als Delivery-Fabric und Observability-Vantage-Point für das Internet.

‍

Die Netto-Wirkung: Wenn Cloudflare niest, spürt das Web es – jüngste Ausfälle beeinträchtigten kurzzeitig prominente Apps und Sites weltweit, darunter Uber, ChatGPT, X – eine Erinnerung an die systemische Bedeutung des Unternehmens.

Was genau ist vorgefallen?

Am 18. November 2025 begann Cloudflares Netzwerk um 11:20 UTC damit, Kernverkehr nicht mehr auszuliefern, nachdem eine Berechtigungsänderung auf einem ClickHouse-Cluster die Ergebnisse einer Abfrage veränderte, die die Bot-Management-„Feature File“ erzeugt. Die Änderung verursachte doppelte Zeilen, verdoppelte die Dateigröße und schob sie über ein Hard Limit im Kern-Proxy (FL/FL2).

‍

Während sich die übergroße Datei im Fünf-Minuten-Takt ausbreitete, schwankten Teile der Flotte zwischen „guten“ und „schlechten“ Zuständen, bis sich der Fehler stabilisierte. Proxys auf FL2 gaben 5xx-Fehler zurück, während der ältere FL-Pfad zwar keine 5xx erzeugte, dafür jedoch Bot-Scores von null lieferte - was bei Kunden, die Bot-Score-Regeln durchsetzen, zu False Positives führte.

‍

Die Auswirkungen griffen auf mehrere Produkte über: Kern-CDN- und Security-Traffic sah verbreitete 5xx-Fehler; Turnstile lud nicht (was viele Dashboard-Logins blockierte); Workers KV und abhängige Systeme, einschließlich Access, verzeichneten erhöhte Fehlerraten, bis ein KV-Bypass die Auswirkungen reduzierte; und Email Security verlor vorübergehend den Zugriff auf eine IP-Reputationsquelle, was die Spam-Erkennungsgenauigkeit verringerte.

‍

Ein unabhängiger, kurzzeitiger Ausfall der Cloudflare-Statusseite außerhalb der eigenen Plattform untermauerte zunächst intern die Hypothese eines Hyper-Scale-DDoS. Die Responders isolierten jedoch die fehlerhaft formatierte Feature File als Root Cause, stoppten deren Verbreitung, rollten auf ein bekannt gutes Artefakt zurück und starteten den Proxy neu. Dadurch wurde der Kernverkehr bis 14:30 UTC wiederhergestellt und bis 17:06 UTC vollständig normalisiert.

Timeline

Cloudflare-Zeitstempel sind UTC.

‍

11:05 – Änderung an der Datenbank-Zugriffskontrolle ausgerollt.

11:20 – Beginn der Ausfälle. Die ersten HTTP-Fehler bei Kunden wurden um 11:28 beobachtet. Automatisierte Tests markierten Probleme um 11:31; die manuelle Untersuchung begann um 11:32, und um 11:35 wurde eine Incident-Bridge geöffnet.

13:05 – Mitigations reduzierten die Auswirkungen, indem Workers KV und Cloudflare Access auf eine frühere Proxy-Version umgangen wurden.

14:24–14:30 – Generierung und Verbreitung der fehlerhaften Bot-Management-Datei wurde gestoppt; eine bekannt gute Datei wurde validiert und global ausgerollt. Haupteinwirkung um 14:30 behoben.

17:06 – Alle Downstream-Services vollständig wiederhergestellt; Auswirkungen beendet.

‍

TTD (Time to Detect): ~3 Minuten (11:28 → 11:31).

TTR (Time to Resolve): ~3 Stunden 2 Minuten bis zur Haupt-Recovery (11:28 → 14:30); ~5 Stunden 38 Minuten bis zur vollständigen Wiederherstellung (11:28 → 17:06).

‍

Betroffen waren Kunden im gesamten Cloudflare-Netzwerk; das Unternehmen bezeichnete es als seinen schlimmsten Ausfall seit 2019, wobei der meiste Kernverkehr während des Peak-Fensters nicht fließen konnte.

So reagierte Cloudflare

Engineering eskalierte innerhalb weniger Minuten, bildete einen Incident-Call und verfolgte parallel mehrere Workstreams: Traffic-Manipulation und Account-Limitierung zum Schutz gestresster Services, gezielte Umgehungen auf frühere Proxy-Versionen sowie ein Rollback der Bot-Management-Konfiguration auf ein bekannt gutes Artefakt. Sobald die auslösende Datei identifiziert war, stoppte das Team deren Erstellung/Verbreitung, schob die korrigierte Datei, und startete betroffene Komponenten neu. Anschließend arbeitenden die Teams den Long Tail ab und stellten sicher, dass Downstream-Systeme sauber recoverten.

So kommunizierte Cloudflare

Cloudflares Statusseite, die außerhalb der Cloudflare-Infrastruktur gehostet wird, war aufgrund eines unabhängigen Problems kurzzeitig nicht erreichbar, was die DDoS-Hypothese im Response-Team zunächst verstärkte. Nachdem die Stabilität zurückgekehrt war, veröffentlichte Cloudflare noch am selben Tag einen detaillierten Post-Incident-Report mit exakten UTC-Zeitstempeln, technischer Root Cause und Commitments zur Härtung. Die offene Einordnung und die explizite Entschuldigung waren ein Beispiel für transparente Incident-Kommunikation im Internet-Maßstab.

Wichtigste Learnings für andere Unternehmen

Große, häufig aktualisierte Konfigurationsartefakte sind de facto Code und verdienen die gleichen Leitplanken. Schema- und Berechtigungsänderungen können Abfrageergebnisse subtil verändern, daher müssen Feature-Generatoren Eingaben strikt filtern und Ausgaben validieren – inklusive Prüfungen auf Größe, Form und Semantik – bevor sie verteilt werden. Globale Propagations-Loops sollten schnelle Kill-Switches und gestufte Rollouts mit begrenztem Blast Radius beinhalten; wechselnde „gute/schlechte“ Versionen über eine teilweise aktualisierte Flotte können Symptome wie einen Angriff aussehen lassen und die Triage verlangsamen. Halten Sie Out-of-Band-Monitoring für Ihre Statusseite vor und stellen Sie sicher, dass sie wirklich unabhängig ist (off-platform gehostet, andere Provider, kontinuierlich synthetisch getestet), um zusätzliche Verwirrung zu vermeiden. Üben und messen Sie schließlich die Recovery Ihrer Kern-Proxys unter Konfigurations-Load-Fehlern und behandeln Sie jede Config-Pipeline mit Artefakt-Registern, Versions-Pinning und einem Rollback-First-Design. Das alles sind pragmatische Wege, um sowohl TTD als auch TTR zu verkürzen.

Das Wichtigste kurz zusammengefasst

Eine Änderung der Datenbank-Berechtigungen veränderte die Ergebnisse einer ClickHouse-Abfrage, die zum Erstellen einer Bot-Management-Feature-Datei verwendet wird. Die Datei verdoppelte ihre Größe, überschritt ein Proxy-Limit und verursachte – einmal propagiert – weitreichende 5xx-Fehler. Die Erkennung erfolgte innerhalb von drei Minuten; die Haupt-Recovery nach etwas mehr als drei Stunden; die vollständige Wiederherstellung in unter sechs Stunden. Cloudflare stoppte die Verbreitung, stellte ein bekannt gutes Artefakt wieder her, startete Services neu und dokumentierte das Ereignis ausführlich – und bezeichnete es als den schlimmsten Ausfall seit 2019.

So kann ilert unterstützen

ilert reduziert die durchschnittliche Zeit, die benötigt wird, um zu bemerken, zu mobilisieren, zu beheben und zu informieren.

‍

• Schnellere Erkennung: Eine vereinheitlichte Alarmierung aus synthetischen Checks und Telemetrie erkennt Anomalien wie steigende 5xx-Raten innerhalb von Minuten und leitet sie automatisch via Voice, SMS, Push und Chat an den Bereitschaftsdienst weiter.
• Intelligente Eskalation und Zusammenarbeit: Dienstpläne und Eskalationsketten stellen sicher, dass sofort die richtigen Responders eingebunden werden und eine gemeinsame, automatisch erzeugte Timeline entsteht. Kein Rätselraten, wenn jede Sekunde zählt.
• Change-bewusste Reaktion: Durch die Verknüpfung von Alarmen mit Deployment Events, können Responders und KI-Agenten Symptome sofort potenziellen Auslösern zuordnen
• Leitplanken für die Kommunikation: Eine gehostete, unabhängige ilert-Statusseite hält Kunden informiert, selbst dann, wenn Ihr primärer Stack degradiert - mit KI-unterstützten Updates und Stakeholder-Benachrichtigungen.
• Postmortems, die wirken: Erzeugen Sie strukturierte PIRs mit Timelines, Action Items und Ownership, damit präventive Kontrollen wie Validierung, Rollout-Gates und Kill-Switches zum Alltag werden.