Leuffen.deBlog

Magazin

Cloudflare: Als eine Abschaltkonfiguration global verteilt wurde

Laut Cloudflare führte ein ungestaffelter Konfigurationswechsel am 5. Dezember 2025 von 08:47 bis 09:12 UTC in betroffenen Anfragepfaden zu HTTP-500-Antworten; rund 28 Prozent des verarbeiteten HTTP-Verkehrs waren betroffen.

Veröffentlicht am
Veröffentlicht von
Redaktion Blog Leuffen.de
Geprüft von
Clara Winter, Inhalt und Struktur, Redaktion und Recherche, Eindeutigkeitsprüfung

Cloudflare wollte am 5. Dezember 2025 ein internes WAF-Testwerkzeug abschalten. Dafür nutzte das Unternehmen einen funktionalen Abschaltmechanismus, den Cloudflare selbst als Kill-Switch bezeichnet. Der zweite Konfigurationswechsel wurde ohne Staffelung global verteilt und führte laut Cloudflare von 08:47 bis 09:12 UTC in betroffenen Anfragepfaden zu HTTP-500-Antworten.

Nach Cloudflares eigener Auswertung waren ungefähr 28 Prozent des in diesem Zeitraum von Cloudflare verarbeiteten HTTP-Verkehrs betroffen. Daraus folgt weder ein Totalausfall aller Produkte noch die Betroffenheit jedes Kunden.

Dem globalen Wechsel war ein anderer, sicherheitsbezogener Change vorausgegangen, den Cloudflare nach eigener Darstellung gestaffelt ausrollte. Erst der zweite Change zum Abschalten des internen Testwerkzeugs lief über das globale Konfigurationssystem ohne diese Staffelung.

Der unmittelbare Codefehler betraf eine Regel mit der Aktion execute. Laut Postmortem war die Anwendung des Kill-Switches auf eine solche Regel zuvor nicht getestet worden. Nach der Änderung fehlte das von Lua-Code erwartete execute-Objekt; der Zugriff darauf erzeugte Fehler. Der wichtigere Systemfehler lag eine Ebene darüber: Eine Konfiguration mit globaler Wirkung hatte bei diesem zweiten Change keinen kleinen Anfang, keine vorgelagerte Gesundheitsprüfung und keinen automatischen Rückweg.

Eine Abschaltkonfiguration ist Produktionssoftware

Eine Konfiguration, die etwas deaktiviert, wirkt oft risikoärmer als eine neue Funktion. Ihr eigener Ausführungspfad kann deshalb seltener benutzt und schlechter getestet sein. Ihre Wirkung bleibt trotzdem Produktion – besonders dann, wenn ein Verteilsystem sie gleichzeitig weltweit wirksam macht.

Cloudflare fasste die anschließende Arbeit unter „Fail Small“ zusammen. Am 1. Mai 2026 meldete das Unternehmen, die Arbeiten seien abgeschlossen. Der Abschlussbericht beschreibt progressive Rollouts über zunächst kleine Gruppen von Systemen oder Verkehrssegmenten, Gesundheitsmetriken mit automatischem Rollback und eine zuletzt nachweislich funktionierende Konfiguration als Rückfallposition. Außerdem soll für jeden relevanten Fehlerfall im jeweiligen Bedrohungsmodell bewusst entschieden werden, ob das System bei diesem Fehler Verkehr passieren lässt (fail-open) oder blockiert (fail-close).

Diese Maßnahmen adressieren nicht nur den konkreten fehlenden Lua-Wert. Ein Nullzugriff lässt sich reparieren; ohne begrenzten Rollout könnte ein nächster andersartiger Fehler erneut gleichzeitig große Reichweite erhalten.

Die übertragbare Prüfliste

  1. Wird auch eine Deaktivierung wie ein normaler Produktions-Change getestet?
  2. Kann die Änderung mit einer kleinen, repräsentativen Gruppe von Systemen oder Verkehrssegmenten beginnen?
  3. Gibt es technische Gesundheitskriterien statt nur manueller Beobachtung?
  4. Erfolgt der Rollback automatisch, und ist eine nachweislich funktionierende Konfiguration verfügbar?
  5. Ist für jeden relevanten Fehlerfall im jeweiligen Bedrohungsmodell festgelegt, ob Fail-open oder Fail-close das kleinere Risiko ist?

Die Lehre lautet weder „Lua war schuld“ noch „globale Konfigurationen sind grundsätzlich falsch“. Globale Wirkung braucht einen begrenzten Anfang und einen getesteten Rückweg.

Quellenhinweis: Ablauf, Reichweite, Ursache und Maßnahmen beruhen auf Cloudflares eigenen Postmortems. Sie wurden hier nicht durch eine unabhängige technische Untersuchung verifiziert.

Quellen

Quellenstand: 21. September 2026.