Cloudflare-Dienstausfall am 5. Dezember 2025

Am 5. Dezember 2025 um 08:47 Uhr UTC (alle Zeiten in diesem Blog sind UTC) kam es in einem Teil des Cloudflare-Netzwerks zu erheblichen Ausfällen. Der Vorfall wurde um 09:12 Uhr behoben (ca. 25 Minuten Gesamtauswirkung), als alle Dienste vollständig wiederhergestellt wurden.

Ein Teil der Kunden war betroffen und machte etwa 28 % des gesamten HTTP-Traffics von Cloudflare aus. Mehrere Faktoren mussten zusammenwirken, damit ein einzelner Kunde wie unten beschrieben betroffen war.

Das Problem wurde weder direkt noch indirekt durch einen Cyberangriff auf die Systeme von Cloudflare noch durch böswillige Aktivitäten jeglicher Art verursacht. Stattdessen wurde dies durch Änderungen an unserer Body-Parsing-Logik ausgelöst, während wir versuchten, eine branchenweite Sicherheitslücke zu erkennen und zu beheben, die diese Woche in React Server Components veröffentlicht wurde.

Ein Ausfall unserer Systeme ist inakzeptabel, und wir wissen, dass wir das Vertrauen des Internets vom 18. November erneut enttäuscht haben. Nächste Woche werden wir Einzelheiten zu unserer Arbeit veröffentlichen, wie wir diese Art von Vorfällen künftig verhindern wollen.

Die folgende Grafik zeigt die von unserem Netzwerk während des Vorfallzeitraums bereitgestellten HTTP-500-Fehler (rote Linie unten) im Vergleich zum nicht betroffenen Gesamt-Cloudflare-Traffic (grüne Linie oben).

Die Web Application Firewall (WAF) von Cloudflare schützt Kunden vor schädlichen Payloads, indem diese erkannt und blockiert werden. Hierzu puffert der Cloudflare-Proxy den Inhalt des HTTP-Request-Bodys im Arbeitsspeicher zur Analyse. Bisher war die Puffergröße auf 128 KB festgelegt.

Im Rahmen unserer fortlaufenden Bemühungen, Kunden, die React verwenden, vor einer kritischen Sicherheitslücke (CVE-2025-55182) zu schützen, haben wir damit begonnen, unsere Puffergröße auf 1 MB zu erhöhen. Dies ist die Standardbegrenzung, die von Next.js-Anwendungen zugelassen wird. Damit stellen wir sicher, dass möglichst viele Kunden geschützt werden.

Diese erste Änderung wurde mit unserem schrittweisen Bereitstellungssystem eingeführt. Während der Einführung stellten wir fest, dass unser internes WAF-Testtool die erhöhte Puffergröße nicht unterstützte. Da dieses interne Testtool zu diesem Zeitpunkt nicht benötigt wurde und keine Auswirkungen auf den Traffic der Kunden hatte, haben wir eine zweite Änderung vorgenommen, um es zu deaktivieren.

Diese zweite Änderung, die Deaktivierung unseres WAF-Testtools, wurde mithilfe unseres globalen Konfigurationssystems implementiert. Dieses System führt keine schrittweisen Rollouts durch, sondern verteilt Änderungen innerhalb von Sekunden auf die gesamte Serverflotte in unserem Netzwerk und wird nach dem Ausfall am 18. November derzeit überprüft. 

Leider führte in unserer FL1-Version des Proxys das zweite Deaktivieren unseres WAF-Regeltesttools unter bestimmten Umständen zu einem Fehlerzustand, in dem unser Netzwerk 500-HTTP-Fehlercodes auslieferte.

Sobald die Änderung in unserem Netzwerk wirksam wurde, stieß die Codeausführung im FL1-Proxy auf einen Fehler im Regelmodul, was zu folgender LUA-Ausnahme führte.

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

und HTTP-500-Fehler zur Folge hatte.

Das Problem wurde kurz nach der Umsetzung der Änderung erkannt und um 09:12 rückgängig gemacht, woraufhin der gesamte Datenverkehr wieder korrekt verarbeitet wurde.

Kunden, deren Webinhalte über unseren älteren FL1-Proxy UND mit dem Cloudflare Managed Ruleset ausgeliefert wurden, waren betroffen. Alle Anfragen an Webseiten in diesem Zustand führten zu einem HTTP-500-Fehler – mit Ausnahme einiger Test-Endpunkte wie /cdn-cgi/trace.

Kunden, auf die die oben genannte Konfiguration nicht angewendet wurde, waren nicht betroffen. Auch der über unser China-Netzwerk abgewickelte Kunden-Traffic war nicht betroffen.

Das Regelsatzsystem von Cloudflare besteht aus Regelsätzen, die für jede Anfrage, die in unser System eingeht, evaluiert werden. Eine Regel besteht aus einem Filter, der bestimmten Traffic auswählt, und einer Aktion, die diesen Traffic beeinflusst. Typische Aktionen sind „block“, „log“ oder „skip“. Eine weitere Art von Aktion ist „execute“, mit der die Evaluierung eines anderen Regelsatzes ausgelöst wird.

Unser internes Logging-System nutzt diese Funktion, um neue Regeln zu evaluieren, bevor sie der Öffentlichkeit zur Verfügung gestellt werden. Ein übergeordnetes Regelset führt dabei ein weiteres Regelset mit Testrichtlinien aus. Genau diese Testregeln wollten wir deaktivieren.

Als Teil unseres Regelwerksystems verfügen wir über ein Killswitch-Subsystem, das es ermöglicht, fehlverhaltende Regeln schnell zu deaktivieren. Dieses System bezieht seine Informationen aus dem zuvor erwähnten globalen Konfigurationssystem. In der Vergangenheit haben wir das Killswitch-System mehrfach eingesetzt, um Vorfälle zu entschärfen, und dabei stets unsere klar definierte Standardarbeitsanweisung befolgt – so auch in diesem Fall.

Allerdings hatten wir bisher noch nie einen Killswitch auf eine Regel mit der Aktion „execute“ angewendet. Nach dem Aktivieren des Killswitches wurde die Ausführung dieser Aktion korrekt übersprungen und das zugehörige Unterregelwerk nicht ausgewertet. Nach dem Aktivieren des Killswitches wurde die Ausführung dieser Aktion korrekt übersprungen und das zugehörige Unterregelwerk nicht ausgewertet:

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

Dieser Code geht davon aus, dass bei einer Regel mit der Aktion „execute“ das Objekt „rule_result.execute“ existiert. Da die Regel jedoch übersprungen wurde, existierte das Objekt rule_result.execute nicht, und Lua gab einen Fehler zurück, da versucht wurde, einen Wert in einem Nil-Objekt zuzugreifen.

Dies ist ein einfacher Fehler im Code, der viele Jahre lang unentdeckt geblieben war. Diese Art von Codefehler wird durch Sprachen mit starken Typsystemen verhindert. Bei unserem Ersatz für diesen Code in unserem neuen FL2-Proxy, der in Rust geschrieben wurde, trat der Fehler nicht auf.

Wir haben vor zwei Wochen, am 18. November 2025, eine nicht damit zusammenhängende Änderung vorgenommen, die einen ähnlichen, längeren Ausfall verursacht hat. In beiden Fällen führte eine Implementierung zur Behebung eines Sicherheitsproblems für unsere Kunden zur Ausbreitung auf unser gesamtes Netzwerk, was zu Fehlern bei fast allen unseren Kunden führte.

Wir haben nach diesem Vorfall direkt mit Hunderten von Kunden gesprochen und unsere Pläne erläutert, um durch Änderungen zu verhindern, dass einzelne Updates solch weitreichende Auswirkungen haben. Wir sind der Meinung, dass diese Änderungen dazu beigetragen hätten, die Auswirkungen des heutigen Vorfalls zu verhindern, aber wir haben sie leider noch nicht vollständig implementiert.

Wir wissen, dass es enttäuschend ist, dass diese Arbeit noch nicht abgeschlossen ist. Sie bleibt jedoch unsere oberste Priorität im gesamten Unternehmen. Insbesondere die im Folgenden aufgeführten Projekte sollen helfen, die Auswirkungen solcher Änderungen zu begrenzen:

• Verbesserte Rollouts und Versionierung: Ähnlich der schrittweisen Softwarebereitstellung mit strenger Zustandsvalidierung müssen Daten für die schnelle Reaktion auf Bedrohungen und die allgemeine Konfiguration die gleichen Sicherheits- und Schutzfunktionen bieten. Dies beinhaltet unter anderem die Zustandsvalidierung und schnelle Rollback-Funktionen.

• Optimierte Break-Glass-Funktionen: Stellen Sie sicher, dass kritische Vorgänge auch angesichts zusätzlicher Fehlerarten weiterhin ausgeführt werden können. Dies gilt sowohl für interne Dienste als auch für alle Standardmethoden der Interaktion mit der Cloudflare-Steuerungsebene, die von allen Cloudflare-Kunden verwendet werden.

• „Fail-Open“-Fehlerbehandlung: Im Rahmen unserer Bemühungen zur Erhöhung der Ausfallsicherheit ersetzen wir die fehlerhaft angewendete Hard-Fail-Logik in allen kritischen Komponenten der Cloudflare-Datenebene. Wenn eine Konfigurationsdatei beschädigt oder außerhalb des zulässigen Bereichs liegt (z. B. bei Überschreitung der Feature-Obergrenzen), protokolliert das System den Fehler und wechselt standardmäßig in einen bekannten, funktionierenden Zustand oder leitet den Datenverkehr ohne Bewertung weiter, anstatt Anfragen zu verwerfen. Einige Dienste bieten dem Kunden wahrscheinlich die Möglichkeit, in bestimmten Szenarien im Fehlerfall „Fail Open“ oder „Fail Closed“ anzuwenden. Dies beinhaltet Funktionen zur Drift-Prävention, um sicherzustellen, dass diese kontinuierlich durchgesetzt wird.

Bis Ende nächster Woche werden wir eine detaillierte Aufschlüsselung aller laufenden Resilienzprojekte veröffentlichen, einschließlich der oben genannten. Während dieser Arbeiten sperren wir alle Änderungen an unserem Netzwerk, um sicherzustellen, dass wir über verbesserte Systeme zur Risikominderung und zum Rollback verfügen, bevor wir den Betrieb wiederaufnehmen.

Diese Art von Vorfällen und die Art, wie gehäuft sie auftreten, sind für ein Netzwerk wie unseres nicht akzeptabel. Im Namen des Cloudflare-Teams möchten wir uns für die Auswirkungen und die dadurch verursachten Unannehmlichkeiten für unsere Kunden und das gesamte Internet entschuldigen.