Wie eine Rust-Panic bei Cloudflare das Internet lahmlegte
Es ist ein Szenario, das die Fragilität zentralisierter Internet-Infrastruktur gnadenlos offenlegt. Am 18. November 2025 sorgte ein Ausfall beim Content Delivery Network (CDN) Cloudflare für weltweite Störungen. Während erste Spekulationen in Richtung eines massiven DDoS-Angriffs gingen – Cloudflare wehrte erst kürzlich Rekord-Attacken ab –, liegt die Ursache in der eigenen Software-Architektur.
Die Post-Mortem-Analyse zeigt: Ein trivialer Logikfehler in einem Datenbank-Update führte in Kombination mit unzureichendem Error-Handling in der Sprache Rust zu einem Kaskadeneffekt ("Thundering Herd"), der zentrale Proxy-Dienste in den Absturz trieb.
Kurz & Knapp
- Der Auslöser: Ein Update der Zugriffskontrollen in einer ClickHouse-Datenbank führte zur Duplizierung von Datensätzen.
- Der Crash: Die daraus resultierende Konfigurationsdatei überschritt ein internes Hard-Limit. Der zuständige Rust-Code reagierte mit einer
panicund beendete den Prozess. - Die Folgen: HTTP-500-Fehler bei zentralen Authentifizierungs-Diensten (Cloudflare Access, Turnstile) legten SaaS-Plattformen, KI-Dienste und physische Zugangssysteme lahm.
- Technischer Hintergrund: Betroffen waren vor allem Instanzen, die auf der neuen Proxy-Architektur "FL2" liefen.
Die Kausalkette: Von der Datenbank zum Totalausfall
Um zu verstehen, warum du gestern Mittag vor "Error 500"-Meldungen saßt, müssen wir tief in den Backend-Stack von Cloudflare blicken. Der Vorfall begann harmlos um 11:05 Uhr UTC mit einer Wartungsarbeit an der Zugriffskontrolle für die analytische Datenbank ClickHouse.
1. Der Trigger: ClickHouse und die doppelten Metadaten
Cloudflare nutzt ClickHouse, um Bedrohungsdaten für das Bot-Management zu verarbeiten. Ein Skript generiert regelmäßig ein sogenanntes "Feature File" – eine Liste von Merkmalen zur Erkennung von Bots –, das an das globale Netzwerk verteilt wird.
Das Update änderte die Sichtbarkeit von Tabellen in der Datenbank-Struktur. Zuvor sah eine Abfrage auf system.columns nur die default-Datenbank. Durch die erweiterte Berechtigung lieferte die Abfrage plötzlich auch Metadaten der zugrundeliegenden Shards (r0-Schema) zurück.
Das Ergebnis: Die Abfrage differenzierte nicht nach Datenbank-Schema. Jeder Eintrag in der Feature-Liste wurde dupliziert. Die Konfigurationsdatei, die normalerweise etwa 60 Einträge enthält, wuchs schlagartig auf über 200 Einträge an.
2. Der Crash: unwrap() in der Produktionsumgebung
Das eigentliche Problem war nicht die fehlerhafte Datei, sondern wie der Proxy-Dienst (intern "FL2" genannt) darauf reagierte. Cloudflare setzt für seine Kerninfrastruktur auf die speichersichere Sprache Rust.
Der Code enthielt jedoch eine harte Annahme: Die Feature-Liste wird niemals größer als 200 Einträge sein. Um Speicher vorab zu allokieren (eine Performance-Optimierung), prüfte der Code die Größe der Datei. Da die Datei das Limit überschritt, trat der Worst Case im Error-Handling ein.
Code-Analyse: Der betroffene Rust-Code nutzte die Methode
.unwrap()auf einemResult-Typ, der einen Fehler zurückgab. In Rust bedeutetunwrap(): "Ich gehe davon aus, dass hier kein Fehler vorliegt. Falls doch: Beende das Programm sofort."
Das Resultat war eine sogenannte Rust Panic: thread fl2_worker_thread panicked: called Result::unwrap() on an Err value
Da dieser Prozess ("FL2") für das Routing des Traffics verantwortlich ist, riss der Absturz die Verbindung für den Endnutzer ab. Die Server starteten neu, luden die fehlerhafte Datei erneut, stürzten wieder ab – eine klassische Boot-Loop.
Auswirkungen auf kritische Infrastruktur
Die Störung verdeutlicht die massive Abhängigkeit moderner IT von wenigen großen Playern. Betroffen waren nicht nur Webseiten, sondern APIs und Backend-Dienste, die Cloudflare als Reverse Proxy oder für DDoS-Schutz nutzen.
- Authentifizierung (Turnstile & Access): Da Cloudflares eigener Login-Schutz (Turnstile) betroffen war, fielen Login-Masken weltweit aus. Nutzer konnten sich nicht bei SaaS-Diensten, Dashboards oder Verwaltungs-Oberflächen anmelden.
- Physische Auswirkungen: Berichte bestätigen Ausfälle bei McDonalds-Bestellterminals sowie beim PADS-System (Personnel Access Data System), das in den USA den Zutritt von Personal zu kerntechnischen Anlagen regelt.
- Kommunikation: Ironischerweise waren auch Status-Seiten (darunter Downdetector) teilweise nicht erreichbar, da sie selbst auf Cloudflare-Infrastruktur setzen.
Betroffene System-Ebenen im Überblick
| Ebene | Betroffene Dienste (Beispiele) | Fehlerbild |
|---|---|---|
| Netzwerk / CDN | Webseiten, APIs, Game-Launcher | HTTP 500 / Timeouts |
| Sicherheit | Cloudflare Access, Turnstile | Login-Loops, Captcha lädt nicht |
| Applikation (SaaS) | ChatGPT, X (Twitter), Salesforce | Dienst vollständig nicht verfügbar |
| Physische Infrastruktur | McDonalds Terminals, PADS (Kraftwerke) | Terminals offline, Zutritt verweigert |
Möglicher nächster Schritt
Remediation und Lehren
Der Vorfall wurde durch einen Rollback auf eine ältere Version der Feature-Datei (Last Known Good) und das Patchen des Codes behoben. Cloudflare musste zwischenzeitlich harte Maßnahmen ergreifen, wie die Deaktivierung des VPN-Dienstes WARP in London, um Last vom Netzwerk zu nehmen.
Aus technischer Sicht bleiben zwei wesentliche Kritikpunkte, die Cloudflare nun adressieren muss:
- Input Validation interner Daten: Das System vertraute intern generierten Dateien blind ("Implicit Trust"). Künftig sollen interne Konfigurationen genauso strikt validiert werden wie externer User-Input.
- Resilienz statt Panic: Ein Überlaufen eines Arrays oder Vektors darf in einer kritischen Netzwerk-Komponente niemals zum Absturz des gesamten Prozesses führen ("Fail Open" vs. "Fail Closed").
Für IT-Verantwortliche ist dieser Vorfall ein Weckruf, "Single Points of Failure" in der eigenen Abhängigkeitskette neu zu bewerten. Wenn der "Türsteher" des Internets stolpert, bleiben auch die besten High-Availability-Cluster dahinter unerreichbar.