Am 18. November 2025 erlebte Cloudflare, einer der weltweit wichtigsten Anbieter für CDN- und Netzwerksicherheitsdienste, einen der schwerwiegendsten Ausfälle seit Jahren. Zahlreiche Websites und Online-Services waren zeitweise nicht erreichbar. Wie CEO Matthew Prince später klarstellte, handelte es sich nicht um eine Cyberattacke, sondern um die Folgen eines internen Konfigurationsfehlers in einer zentralen Datenbankkomponente.
Vom vermeintlichen DDoS-Angriff zur internen Fehlkonfiguration
Die ersten Störungen traten gegen 11:20 UTC auf. Dienste, die Cloudflare als Reverse Proxy und Sicherheitsperimeter nutzen, wurden nur noch intermittierend erreichbar. Das Muster – kurze Erholungsphasen, gefolgt von erneuten Ausfällen – entsprach typischen Verläufen bei einer automatisierten DDoS-Abwehr, sodass das Incident-Response-Team zunächst von einem grossangelegten Angriff ausging.
Die forensische Analyse ergab jedoch rasch, dass die Ursache im Inneren der Cloudflare-Infrastruktur lag. Auslöser war eine Änderung der Zugriffsrechte in einem ClickHouse-Cluster, einer verteilten Datenbank, die Cloudflare für hochvolumige Analytik einsetzt. Ein fehlerhaft formulierter Abfragebefehl beeinflusste die Generierung einer zentralen Konfigurationsdatei für das Bot-Management-System.
Rolle von ClickHouse und Bot Management in der Cloudflare-Architektur
Cloudflare nutzt umfangreiche Traffic-Analysen, um bösartige Anfragen und automatisierte Bots zu erkennen und zu filtern. Ein dedizierter ClickHouse-Cluster erzeugt hierfür ein sogenanntes Feature File: eine Datei mit Merkmalen und Verhaltensindikatoren, anhand derer Proxys Entscheidungen über Zulassung, Drosselung oder Blockierung von Anfragen treffen.
Dieses Feature File ist ein kritisches Konfigurationselement. Es wird in regelmässigen Abständen generiert und global an Edge-Standorte verteilt. Fehler in Struktur, Inhalt oder Grösse wirken sich daher unmittelbar auf einen grossen Teil der Infrastruktur aus – ein klassischer „Single Point of Failure“ im Konfigurationspfad.
Wie ein Abfragefehler das Feature File sprengte
Ziel der Änderung in ClickHouse war es, Kunden breiteren Zugriff auf zusätzliche technische Metriken und Metadaten zu gewähren. Die entsprechende Datenbankabfrage war jedoch so formuliert, dass sie mehr Daten als vorgesehen zurücklieferte. In der Folge wuchs das Feature File auf mehr als das Doppelte seiner üblichen Grösse.
Da in der Architektur ein striktes Grössenlimit für diese Datei definiert war, stuften die Proxys die neue Version als ungültig ein und quittierten den Dienst mit Fehlern. Verschärfend kam hinzu, dass der Cluster alle fünf Minuten eine neue, ebenfalls fehlerhafte Version erzeugte. Dies führte zu einem wellenförmigen Muster von Ausfällen und kurzzeitigen Stabilitäten.
„Flapping“-Effekt: Warum der Ausfall wie eine Attacke aussah
Der Vorfall wurde zusätzlich verkompliziert, weil nicht alle ClickHouse-Nodes die neuen Rechte gleichzeitig erhielten. Nur ein Teil der Knoten generierte das „kaputte“ Feature File. Damit verteilten einige Proxys noch korrekte Konfigurationen, während andere bereits die fehlerhafte Version bezogen.
Dieses Wechselspiel verursachte ein Flapping: Systeme wechselten ständig zwischen funktionsfähigem und fehlerhaftem Zustand, abhängig davon, welche Konfigurationsversion sie zuletzt erhalten hatten. Gegen 13:00 UTC waren schliesslich alle Nodes auf den fehlerhaften Stand migriert – das System trat in ein „stabiles Fehlerregime“ über, die Störungen wurden flächendeckend und dauerhaft.
Globale Auswirkungen auf europäische Knoten und grosse Internetdienste
Monitoring-Plattformen meldeten signifikante Ausfälle in zahlreichen europäischen Cloudflare-Rechenzentren, darunter Amsterdam, Berlin, Frankfurt, Warschau, Wien, Zürich und Stockholm. Dienste wie Downdetector verzeichneten zehntausende Störungsmeldungen.
Betroffen waren auch grosse Online-Plattformen und Cloud-Anbieter, darunter Spotify, Twitter, OpenAI, Anthropic, AWS und Google, die Cloudflare zur Content-Auslieferung und als Sicherheitslayer einsetzen. Der Vorfall zeigt eindrücklich, wie stark sich die Konzentration auf wenige Infrastrukturanbieter auf die Gesamt-Resilienz des Internets auswirkt – ein Trend, den auch regelmässige Branchenberichte von ENISA und NIST zunehmend kritisch beleuchten.
Stabilisierung, Root-Cause-Analyse und technische Lehren
Zur Eindämmung des Vorfalls stoppte Cloudflare die Generierung der fehlerhaften Dateien, platzierte manuell eine bekannte, gültige Version des Feature Files in die Distributionspipeline und führte einen erzwungenen Neustart der betroffenen Proxys durch. Gegen 17:44 UTC war der Normalbetrieb weitgehend wiederhergestellt.
Cloudflare kündigte an, die Validierung von Konfigurationsartefakten deutlich zu verschärfen, zusätzliche Kill Switches für kritische Funktionen zu implementieren und die Fehlerbehandlung in zentralen Proxy-Komponenten zu überarbeiten. Solche Massnahmen entsprechen etablierten Best Practices aus dem Site-Reliability-Engineering, wie sie etwa in NIST-Empfehlungen und im Google-SRE-Framework beschrieben werden.
Implikationen für Cybersecurity, DevOps und Konfigurationsmanagement
Branchenstudien wie der Verizon Data Breach Investigations Report zeigen seit Jahren, dass Fehlkonfigurationen – nicht Zero-Day-Exploits – zu den häufigsten Ursachen für Sicherheits- und Verfügbarkeitsvorfälle gehören. Der Cloudflare-Ausfall unterstreicht mehrere zentrale Handlungsfelder:
1. Strenge Konfigurationsvalidierung: Konfigurationsdateien sollten vor dem globalen Rollout automatisiert syntaktisch und semantisch geprüft werden (Schema-Validierung, Grössenlimits, Canary-Checks). Ein fehlerhaftes Artefakt darf den Produktionsperimeter nicht erreichen.
2. Stufenweise Rollouts: Canary Deployments und regionale Testgruppen begrenzen den Schaden, wenn Konfigurationsänderungen unerwartete Nebenwirkungen haben. Ein globaler, gleichzeitiger Rollout erhöht das systemische Risiko erheblich.
3. Kill Switches und sichere Fallbacks: Sicherheits- und Bot-Management-Funktionen sollten über klar definierte Notabschaltungen und Fail-Safe-Modi verfügen. Wenn eine Komponente versagt, muss die Infrastruktur in einen kontrollierten Degradationszustand übergehen, statt unkontrolliert auszufallen.
4. Observability und korrekte Attribution: Eine ausgereifte Observability-Landschaft (Metriken, Logs, verteiltes Tracing) ist notwendig, um interne Konfigurationsfehler rasch von externen Angriffen zu unterscheiden. Fehlattribution verlängert Reaktionszeiten und verschärft Folgen.
Organisationen, die auf Cloudflare und ähnliche Anbieter angewiesen sind, sollten den Vorfall zum Anlass nehmen, die eigenen Prozesse kritisch zu überprüfen: Wie werden Zugriffsrechte auf kritische Datenbanken verwaltet? Welche Tests existieren für Konfigurationsartefakte? Wie schnell lässt sich ein fehlerhaftes Rollout global zurückdrehen? Und wie robust ist die eigene Mehrschicht-Architektur gegenüber Ausfällen externer Provider?
Wer diese Fragen ehrlich beantwortet und entsprechende Massnahmen umsetzt – von automatisierter Konfigurationsprüfung über Canary-Rollouts bis zu klar definierten Notfallprozeduren – reduziert das Risiko, dass eine einzelne fehlerhafte Abfrage nicht nur interne Systeme, sondern Teile des globalen Internets in die Knie zwingt.
