Cloudflare-Ausfall am 5. Dezember 2025

• Am 5. Dezember 2025 um 08:47 UTC war ein Teil des Cloudflare-Netzwerks von einem schweren Ausfall betroffen, und um 09:12, rund 25 Minuten später, wurde er vollständig wiederhergestellt.
• Insgesamt waren etwa 28 % des gesamten HTTP-Traffics betroffen, und nur Kunden mit bestimmten Voraussetzungen erfuhren den Ausfall.
• Ursache war eine WAF-Änderung (Body-Parsing-Logik) im Rahmen der Reaktion auf die neue React Server Components-Schwachstelle (CVE-2025-55182); sie war nicht mit einem Cyberangriff verbunden.
• Ein Codefehler im FL1-Proxy führte zu HTTP-500-Fehlern, im neuen Rust-basierten FL2-Proxy trat derselbe Fehler nicht auf.
• Cloudflare räumt ein, dass ein ähnliches Problem trotz des Vorfalls am 18. November erneut auftrat, und arbeitet als oberste Priorität an Projekten zur Stärkung von Rollout-Sicherheit und Resilienz weiter.

---

Ausfallübersicht

• Am 5. Dezember 2025 um 08:47 UTC trat in einem Teil des Cloudflare-Netzwerks ein Ausfall auf
  • Um 09:12 wurden alle Services wiederhergestellt; insgesamt 25 Minuten waren betroffen
  • Der Ausfall hatte nichts mit einem Cyberangriff oder böswilligen Aktionen zu tun, sondern entstand bei einer internen Konfigurationsänderung
• Die Ursache war die Anpassung der WAF-Body-Parsing-Logik zur Reaktion auf die neue React Server Components-Schwachstelle.

Ursache und technischer Hintergrund

• Die Cloudflare-WAF puffert den HTTP-Request-Body im Speicher, um bösartige Payloads zu erkennen.
  • Die bestehende Puffersize war von 128 KB auf 1 MB erhöht worden.
• Da das interne Test-Tool die neue Puffergröße nicht unterstützte, wurde ein zweiter Änderungsdurchlauf durchgeführt, der das Test-Tool deaktivierte.
  • Diese Änderung wurde über das globale Konfigurationssystem sofort auf alle Server ausgerollt.
• In FL1-Proxy führte diese Änderung zu einem Fehlerzustand und damit zu HTTP-500-Antworten.
  • Fehlermeldung: attempt to index field 'execute' (a nil value)
• Das Problem wurde sofort erkannt, und die Änderung wurde um 09:12 zurückgenommen.

Auswirkungsbereich

• Betroffen waren nur Kunden mit FL1-Proxy und aktiviertem Cloudflare Managed Ruleset
  • Alle Anfragen auf diesen Sites erhielten HTTP-500-Fehler
  • Einige Testendpunkte wie /cdn-cgi/trace waren ausgenommen
• Das China-Netzwerk und Kunden mit anderer Konfiguration waren nicht betroffen.

Details zum Laufzeitfehler

• Das Rulesets-System von Cloudflare bewertet pro Anfrage Regeln.
  • Regeln bestehen aus Filtern und Aktionen; die execute-Aktion ruft andere Rule-Sets auf.
• Das interne Logging-System bewertete Testregeln mit execute.
• Das Killswitch-System ist dafür ausgelegt, fehlerhafte Regeln zu deaktivieren.
  • Die Anwendung eines Killswitch auf Regeln mit execute-Aktion war bisher noch nie erfolgt.
• Der Zugriff auf ein nicht existentes execute-Objekt verursachte einen Lua-Fehler.
• Dieser Fehler war ein einfacher Codefehler, der seit Jahren vorhanden, aber unentdeckt blieb.
  • Im in Rust geschriebenen FL2-Proxy trat derselbe Fehler nicht auf.

Fortschritt seit dem Ausfall am 18. November

• Auch am 18. November gab es einen ähnlichen, weitreichenden Ausfall durch globales Deployment.
• Bei direkter Kommunikation mit mehreren hundert Kunden wurde ein Plan zur Verhinderung der vollständigen Ausbreitung eines einzelnen Updates geteilt.
• Diese Verbesserungsarbeit war noch nicht abgeschlossen und wirkte sich auf den aktuellen Ausfall aus.
• Cloudflare hat dies als organisationsweite Höchste-Priorität festgelegt.

Laufende Resilienz-Projekte

• Enhanced Rollouts & Versioning
  • Für Daten- und Konfigurationsänderungen bei der Reaktion auf Bedrohungen werden künftig schrittweise Rollouts, Health Checks und schnelle Rollbacks eingeführt.
• Streamlined Break Glass Capabilities
  • Auch bei Interaktion mit internen Services und der Control Plane soll eine Notfall-Bedienmöglichkeit sichergestellt werden.
• Fail-Open Fehlerbehandlung
  • Bei Konfigurationsdateifehlern wird der Traffic nicht blockiert, sondern in einen normalen Grundzustand zurückgeschaltet oder direkt durchgelassen.
  • Für einige Services ist künftig eine Auswahl zwischen fail-open und fail-closed geplant.
• Details zu allen Resilienz-Projekten werden innerhalb der nächsten Woche veröffentlicht.
• Bis dahin werden Netzwerkänderungen in einen umfassenden Lockdown versetzt.

Timeline (UTC)

• 08:47 – Bereitstellung der Konfigurationsänderung und Beginn der Netzwerkverteilung
• 08:48 – Vollständige Auswirkungen traten ein
• 08:50 – Incident-Meldung durch automatische Alarme
• 09:11 – Rücksetzung der Änderung gestartet
• 09:12 – Wiederherstellung abgeschlossen, der gesamte Traffic wurde normalisiert

Fazit

• Cloudflare erkennt die Schwere von zwei aufeinanderfolgenden Ausfällen an und entschuldigt sich bei seinen Kunden und dem gesamten Internet.
• Künftig sollen durch Maßnahmen zu Ausroll-Sicherheit, Fehlertoleranz und Resilienz ähnliche Vorfälle verhindert werden.