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.

[GN⁺]

Hacker-News-Kommentare

• Dieser Cloudflare-Ausfall war nicht nur ein einfacher Lua-Bug, sondern ein Vorfall, der ein grundlegendes Architekturproblem offengelegt hat
  Die ursprüngliche verteilte Web-Struktur war gegen solche globalen Ausfälle viel robuster. Dagegen kann bei einem homogenen zentralisierten System wie Cloudflare ein einziger Fehler dazu führen, dass Dienste auf der ganzen Welt gleichzeitig stillstehen. Auch wenn es in Rust geschrieben ist, machen Menschen Fehler. Am Ende ist ein robustes Design entscheidend

  • Das bedeutet letztlich, dass die Stabilität des Webs abnimmt, je stärker man sich auf riesige Anbieter wie Cloudflare oder AWS verlässt
  • Wie bei der Analogie „1.000 Hornissen gegen 1 Hund“ unterscheidet sich bei globalen und lokalen Ausfällen nur die Form des Schmerzes. Wenn Cloudflare ausfällt, reagieren sofort Hunderte Ingenieure, aber wenn mein Server ausfällt, könnte der Zuständige gerade in einer Berghütte sein
  • Die Debatte darüber, dass Monopole schlecht sind, einmal beiseite: Wenn man sich Cloudflares langfristige Verfügbarkeit ansieht, ist das vermutlich immer noch besser, als wenn einzelne Websites ihre Infrastruktur selbst betreiben. Dass alle Dienste gleichzeitig 1 Stunde ausfallen, ist aus Nutzersicht besser, als wenn jeder Dienst für sich jeweils 1 Stunde ausfällt. Wenn Cloudflares Stabilität allerdings unter den Durchschnitt fällt, verschwindet dieser Vorteil
  • Bei einer Größenordnung von 80 Millionen Anfragen pro Sekunde halte ich schon die Struktur selbst für problematisch, in der ein einziges Produkt so groß werden kann
  • Cloudflare gehört immer noch zu den Unternehmen, die globale Infrastruktur weltweit am schnellsten wiederherstellen können. Auch diesmal wurde ein Netzwerkausfall von 28 % in 25 Minuten behoben, und objektiv gesehen gibt es weniger Downtime als bei anderen Clouds

• Gestern Abend habe ich auf mehreren Websites Cloudflare-500-Fehler gesehen. Auf der Statusseite stand dazu aber nichts, nur eine Ankündigung geplanter Wartungsarbeiten

  • Wie bei den meisten Statusseiten dauert es eine Weile, bis ein echtes Problem erkannt und aktualisiert wird. Bis das vollständig automatisiert ist, ist auch Cloudflare keine Ausnahme. Noch besorgniserregender ist, dass zuletzt AWS, Azure und Cloudflare nacheinander ausgefallen sind. Mein Bauchgefühl sagt, dass hier Faktoren wie die zunehmende Nutzung von LLMs, Personalmangel, Nachwirkungen der Pandemie und politische Unsicherheit zusammenwirken
  • Solche Probleme mit Statusseiten werden sich wohl nur durch öffentliche Kritik verbessern. Es müsste mehr Rückmeldungen in der Art geben: „Cloudflare erkennt Ausfälle nicht einmal richtig“

• Es wirkt so, als könne Cloudflares Quality Engineering mit der Produktionsgeschwindigkeit nicht Schritt halten. Aus der Rüstungsindustrie hieß es früher, das Qualitätsteam sei immer erfahrener gewesen, aber in der Softwarebranche scheint es eher umgekehrt zu sein

  • Das erinnert an eine Anekdote aus der Rüstungsindustrie, wo man einen Speicherleck kannte, ihn aber ignorierte mit der Begründung, „innerhalb der vorgesehenen Nutzungsdauer ist das kein Problem“
  • Dass so etwas zweimal im Monat passiert, ist nichts, wofür man jemandem „Anerkennung“ zollen sollte. Bei Wiederholungen gibt es keine Entschuldigung

• Die Paketvermittlungsstruktur des Internets wurde ursprünglich genau dafür entworfen, solche globalen Ausfälle auszuhalten.
  Das DARPA-Netzwerk in Zeiten des Kalten Krieges sollte die Befehlskette selbst unter einem Nuklearangriff aufrechterhalten.
  Jetzt ist der Zeitpunkt gekommen, zum Local-first-Paradigma des Internets zurückzukehren

  • Siehe auch: The Real Internet Architecture
  • Siehe auch: Local-first software

• In letzter Zeit habe ich das Gefühl, dass Cloudflare das Internet langsamer und unbequemer macht. Verfahren wie „Beweisen Sie, dass Sie ein Mensch sind“ nehmen zu, und auch das Laden von Seiten verzögert sich.
  Das scheint eher mit der Abrechnungspolitik für AI-Crawling zu tun zu haben als mit dem Schutz von Websites (Einführung von Pay-per-crawl)

  • Solche Verfahren zur Menschenerkennung sind mit älteren Browsern nicht kompatibel, sodass manche Websites gar nicht mehr zugänglich sind
  • Andererseits ist es ebenfalls ein Problem, dass AI Inhalte ungefragt absaugt. Cloudflare bietet Website-Betreibern damit gewissermaßen eine Option zum Schutz von Inhalten, und wer das nicht möchte, kann es deaktivieren
  • Dazu kam auch die zynische Bemerkung: „Jetzt können sie uns nicht einmal mehr heimlich überwachen“

• Cloudflares globales Konfigurationssystem ist riskant, weil es sich ohne stufenweisen Rollout innerhalb weniger Sekunden über das gesamte Netzwerk ausbreitet.
  Es braucht ein System, das bei Konfigurationsänderungen, die Fehler auslösen, die Korrelation sofort erkennen kann

  • Das Problem war, dass der Alarm viel zu spät ausgelöst wurde. Die Benachrichtigung kam nach 2 Minuten, dabei hätte die Erkennung in Sekunden erfolgen müssen.
    Das Deployment-Team hätte die Echtzeitmetriken beobachten und sofort den Rollback-Button drücken müssen.
    Sogar die konkrete Codezeile stand klar im Log, aber es wirkte, als seien das Deployment-Team und das Team mit dem Codeverständnis voneinander abgeschnitten gewesen
  • Offenbar wurde beim Erkennen der Warnsignale ein Rollback versucht, aber genau dieser Prozess hat das Problem noch verschärft
  • Interne Tools haben oft viele False Positives und sind nicht selten selbst kaputt
  • Es klingt wie der Witz: „Weil die Motorwarnleuchte ständig anging, habe ich einfach die Birne herausgedreht“

• Cloudflares Verfügbarkeit ist unter 99,9 % gefallen. Das ist schlechter als mein Heim-PC

  • Bei AWS ist es ähnlich. Wenn der Sinn der Cloud in „höherer Verfügbarkeit“ besteht, dann gibt es ausreichend Gründe für Self-Hosting, wenn sie teuer und instabil ist
  • Allerdings kann es beim Selbsthosting nach einem Hardwareausfall oder einem fehlgeschlagenen Backup Tage dauern, bis alles wiederhergestellt ist
  • In Gegenden mit häufigen Stromausfällen ist es selbst mit Laptop und Batterie schwer durchzuhalten. Manchmal träumt man von einer autark funktionierenden Infrastruktur
  • Ich frage mich, wo man die genauen Uptime-Statistiken von Cloudflare derzeit einsehen kann
  • Trotzdem ist ein direkter Vergleich zwischen einem privaten PC und Cloudflare eine sinnlose Analogie

• Bei einer Größe wie Cloudflare muss es unbedingt eine Testumgebung geben.
  Jede Änderung sollte erst in einer isolierten Modellumgebung simuliert und dann schrittweise ausgerollt werden.
  Wichtiger als ein starkes Typsystem sind prozedurale Sicherheitsvorkehrungen

  • Unser Unternehmen nutzt ein dreistufiges Deployment-System: Entwicklung → interne Integration → Produktion.
    Teams, die häufiger Fehler machen, werden ausgebremst, und Teams mit hoher Zuverlässigkeit können schneller vorgehen.
    Letztlich ist technische Geschwindigkeit eine Frage der Entscheidung. Wenn die SLA gefährdet ist, muss man langsamer werden und die Tests verschärfen
  • Man könnte kostenlose Nutzer als Testbed verwenden und zahlenden Kunden eine stabile Version bereitstellen
  • Der Satz „Ein starkes Typsystem wird dich nicht retten“ bedeutet, dass eine Sprache gegenüber prozessualem Versagen machtlos ist

• Es scheint, als gerate Cloudflares Softwarequalität ins Wanken.
  Es gab auch einen Bug, bei dem die Zugriffskontrolle einer Enterprise-only-Funktion erst im letzten Schritt geprüft wurde

  • Ich selbst habe in der Cloudflare-API schon Konfigurationen erlebt, die nicht zurückgerollt werden konnten.
    Änderungen waren nur über den Support möglich, und die Korrektur dauerte mehrere Tage
    Link zu einem ähnlichen Fall
  • Ich halte es auch für möglich, dass solche Bugs von AI-generiertem Code stammen
  • Ich würde gerne konkreter hören, was genau mit „erst im letzten Schritt prüfen“ gemeint ist

• Ich frage mich, wie Cloudflares Betriebskultur aussieht.
  Während der Reaktion auf ein Sicherheitsproblem trat ein Fehler auf, und statt eines Rollbacks wurde erneut ein globales Deployment durchgeführt — eine riskante Entscheidung.
  Damit wurde der Grundsatz „Im Zweifel rollbacken“ verletzt

  • Allerdings handelte es sich diesmal um eine dringende Lage wie bei der Reaktion auf die React Server RCE-Schwachstelle.
    Hätte man das Deployment verzögert, hätten Kunden tatsächlich gehackt werden können; in so einem Fall ist Geschwindigkeit gleich Sicherheit
  • Ein Rollback ist nicht immer die richtige Antwort. Wenn das Verfahren nicht eingespielt ist, wird es selbst zum Risiko
  • Tatsächlich betrafen die beiden Deployments unterschiedliche Komponenten.
    Der erste Fix hat nur den latenten Bug im zweiten sichtbar gemacht, deshalb ist manchmal Roll forward realistischer als ein Rollback
  • Cloudflare hat während seines schnellen Wachstums wahrscheinlich technische Schulden angehäuft.
    Die häufigen jüngsten Ausfälle könnten ein Zeichen dafür sein, dass diese Schulden jetzt sichtbar werden