Lesezeit: 10 Min.
Am 12. Juni 2025 ist es bei Cloudflare zum einem schwerwiegenden Ausfall gekommen, von dem ein großer Teil unserer wichtigsten Dienste betroffen war – darunter Workers KV, WARP, Access, Gateway, Images, Stream, Workers AI, Turnstile und Challenges, AutoRAG, Zaraz und Teile unseres Dashboards.
Der Ausfall erstreckte sich über zwei Stunden und 28 Minuten und betraf alle Cloudflare-Kunden weltweit, die die betroffenen Dienste nutzten. Ursache war ein Fehler in der zugrundeliegenden Speicherinfrastruktur, die von unserem Dienst Workers KV verwendet wird. Es handelt sich um eine kritische Abhängigkeit vieler Cloudflare-Produkte, die von den betroffenen Diensten für die Konfiguration, Authentifizierung und Bereitstellung von Assets benötigt wird. Ein Teil dieser Infrastruktur wird von einem externen Cloud-Provider unterstützt, der an diesem Tag einen Ausfall verzeichnet hat, was die Verfügbarkeit unseres KV-Dienstes unmittelbar beeinträchtigt hat.
Wir möchten uns für diesen Ausfall entschuldigen, der einem Versäumnis unsererseits geschuldet ist. Die unmittelbare Ursache (bzw. der Auslöser) geht zwar auf einen Drittanbieter zurück, doch letztlich sind wir für die von uns gewählten Abhängigkeiten und die Art ihrer Integration verantwortlich.
Der Ausfall war nicht die Folge eines Angriffs oder eines anderen Sicherheitsvorfalls und es sind dabei keine Daten verloren gegangen. Die Cloudflare-Produkte Magic Transit und Magic WAN, DNS, Cache, Proxy, WAF und verwandte Dienste waren von diesem Vorfall nicht direkt betroffen.
Wo gab es Beeinträchtigungen?
In der Regel beruhen die Cloudflare-Dienste auf Grundbausteinen unserer eigenen Plattform, weshalb viele unserer Produkte den Workers KV-Service nutzen.
Die folgende Tabelle zeigt die betroffenen Dienste, einschließlich der Auswirkungen auf die Nutzer, der Betriebsstörungen und des verzeichneten Anstiegs der Fehlerquoten:
Produkt / Dienst | Auswirkung |
|---|
Workers KV
| Bei Workers KV sind 90,22 Prozent der Anfragen fehlgeschlagen: Jedes Schlüssel/Wert-Paar, das sich nicht im Cache befand und zum Abruf des Werts von den Ursprungs-Speicher-Backends von Workers KV erforderlich war, hatte das Fehlschlagen einer Anfrage mit dem Antwortcode 503 oder 500 zur Folge. Die restlichen Anfragen wurden entweder erfolgreich aus dem Zwischenspeicher von Workers KV beantwortet (Statuscode 200 und 404) oder es kam zu einer Fehlerausgabe innerhalb unserer erwarteten Parameter und/oder unseres Fehlerkontingents. Auf die in Workers KV gespeicherten Daten hatte der Vorfall keine Auswirkungen. |
Access
| Access speichert mithilfe von Workers KV Anwendungs- und Richtlinienkonfigurationen sowie Informationen zur Nutzeridentität. Während des Vorfalls sind die identitätsbasierten Logins für alle Anwendungsarten zu 100 Prozent fehlgeschlagen. Das galt für On-Premise-, SaaS- und Infrastruktur-Applikationen. Informationen zur Nutzeridentität waren während dieses Zwischenfalls für andere Dienste wie WARP und Gateway nicht verfügbar. Access ist so aufgebaut, dass sich die Lösung im Fehlerfall schließt, wenn die Richtlinienkonfiguration oder die Identität eines Nutzers nicht abgerufen werden kann. Bei aktiven Infrastruktur-Anwendungs-SSH-Sitzungen mit aktivierter Befehlsprotokollierung wurden aufgrund einer Abhängigkeit von Workers KV Protokolle nicht gespeichert. Der SCIM (System for Cross Domain Identity)-Dienst von Access war ebenfalls betroffen, da er zur Speicherung von Nutzerdaten auf Workers KV und Durable Objects (die von KV abhängig sind) angewiesen ist. Während des Zwischenfalls wurden Nutzeridentitäten aufgrund des Scheiterns von Workers KV-Updates nicht aktualisiert. Dies zog eine 500-Fehlermeldung an Identitätsanbieter nach sich. Einige Provider verlangen möglicherweise eine manuelle Neusynchronisierung. Bei den meisten Kunden dürfte der Dienst aufgrund der Wiederholungslogik des Identitätsanbieters aber mit Wiederherstellung des SCIM-Service von Access direkt wiederhergestellt worden sein. Auf Dienstauthentifizierung basierende Logins (z. B. Service-Token, Mutual TLS und IP-basierte Richtlinien) und Umgehungsrichtlinien waren nicht betroffen. Während des fraglichen Zeitraums sind keine Bearbeitungen oder Änderungen an den Access-Richtlinien verloren gegangen. |
Gateway
| Der Vorfall hatte keine Auswirkungen auf die meisten Gateway DNS-Abfragen, einschließlich derer über IPv4, IPv6, DNS über TLS (DoT) sowie DNS über HTTPS (DoH). Allerdings gab es zwei Ausnahmen: DoH-Abfragen mit identitätsbasierten Regeln sind fehlgeschlagen, weil Gateway die erforderlichen Identitätsinformationen der Nutzer nicht abrufen konnte. Authentifiziertes DoH funktionierte für einige Nutzer nicht mehr richtig. Nutzer mit aktiven Sitzungen und gültigen Authentifizierungs-Token waren nicht betroffen. Diejenigen, die neue Sitzungen starten oder Authentifizierungs-Token erneuern mussten, konnten dies jedoch nicht tun. Nutzer des Gateway-Proxys, von Egress und der TLS-Entschlüsselung waren nicht in der Lage, eine Verbindung herzustellen, sich zu registrieren, den Proxy zu nutzen oder den Datenverkehr zu protokollieren. Das lag daran, dass wir Workers KV zum Abruf aktueller Informationen zu Identität und Gerätestatus nutzen. Jede dieser Aktionen erfordert einen Aufruf an Workers KV. Ist dieser Dienst nicht verfügbar, ist die Gateway-Lösung so konzipiert, dass sie schließt. Auf diese Weise soll verhindert werden, dass der Datenverkehr die vom Kunden konfigurierten Regeln umgeht. |
WARP
| Der WARP-Client war wegen grundlegender Abhängigkeiten von Access und Workers KV betroffen. Beide Dienste werden für die Registrierung und Authentifizierung von Geräten benötigt. Infolgedessen konnten sich während des Zwischenfalls keine neuen Clients verbinden oder anmelden. Bestehende WARP-Client-Nutzersitzungen, die über den Gateway-Proxy geleitet wurden, verzeichneten Störungen, weil Gateway die erforderlichen Richtlinienbewertungen nicht durchführen konnte. Zusätzlich funktionierte aufgrund eines Fehlers bei der zugrundeliegenden Abhängigkeit – Workers KV – die WARP-Notfallabschaltung nicht. Consumer WARP verzeichnete ähnliche punktuelle Auswirkungen wie die Zero Trust-Version. |
Dashboard
| Dashboard-Logins und die meisten bestehenden Dashboard-Sitzungen funktionierten nicht. Der Grund dafür war ein Ausfall von Turnstile, DO, KV und Access. Die konkreten Ursachen für fehlgeschlagene Logins waren: Bei Standard-Logins (Nutzer/Passwort): Nichtverfügbarkeit von Turnstile Bei Anmeldung mit Google (OIDC): Problem mit einer KV-Abhängigkeit Bei SSO-Logins: Vollständige Abhängigkeit von Access Die Cloudflare v4-API war von dem Vorfall nicht betroffen. |
Challenges und Turnstile
| Die Challenge-Plattform, auf der Cloudflare Challenges und Turnstile beruhen, verzeichnete während des Vorfallszeitraums aufgrund ihrer Abhängigkeit von Workers KV und Durable Objects eine hohe Zahl von Fehlern und Timeouts bei Siteverify-API-Anfragen. Wir haben Kill Switches eingerichtet, damit diese Aufrufe bei Zwischenfällen und Ausfällen wie diesem deaktiviert werden können. Diese Kill Switches wurden von uns als Abwehrmaßnahme aktiviert, damit die Nutzer nicht am Fortfahren gehindert werden. Bemerkenswerterweise konnte die Siteverify-API von Turnstile (die ausgegebene Tokens validiert) während der Aktivierung dieser Kill Switches gültige Token mehrfach einlösen. Dadurch wurden potenziell Angriffe ermöglicht, im Rahmen derer ein böswilliger Akteur versuchen könnte, ein zuvor gültiges Token zur Umgehung zu verwenden. Die Fähigkeit von Turnstile, Bots zu erkennen, wurde nicht beeinträchtigt. Ein Bot wäre beim Versuch, eine Aufgabe zu lösen, trotzdem gescheitert. Somit hätte er auch keinen Token erhalten. |
Browserisolierung
| Bestehende Browserisolierungssitzungen über linkbasierte Isolierung wurden aufgrund der Abhängigkeit von Gateway bei der Richtlinienbewertung beeinträchtigt. Neue linkbasierte Browserisolierungssitzungen konnten wegen einer Abhängigkeit von Cloudflare Access nicht gestartet werden. Alle von Gateway initiierten Isolierungssitzungen sind aufgrund ihrer Gateway-Abhängigkeit fehlgeschlagen. |
Images
| Uploads bei Cloudflare Images waren während des Vorfallzeitraums beeinträchtigt. Auf dem Höhepunkt des Zwischenfalls betrug die Fehlerquote 100 Prozent. Bei der Bildübertragung sank die Erfolgsquote insgesamt auf etwa 97 Prozent. Bildumwandlungen wurden nicht signifikant beeinträchtigt und Polish verzeichnete keine Beeinträchtigungen. |
Stream
| Die Fehlerquote von Stream hat während des Vorfallzeitraums 90 Prozent betragen, da Video-Playlists nicht bereitgestellt werden konnten. Stream Live verzeichnete eine Fehlerquote von 100 Prozent. Video-Uploads waren nicht betroffen. |
Realtime
| Der Realtime TURN (Traversal Using Relays around NAT)-Dienst verwendet KV und war stark betroffen. Während des Zwischenfalls lag die Fehlerquote bei nahezu 100 Prozent. Der Realtime-SFU (Selective Forwarding Unit)-Dienst konnte keine neuen Sitzungen aufbauen, auch wenn bestehende Verbindungen aufrechterhalten wurden. Dies führte zu einer Reduzierung des normalen Datenverkehrs auf 20 Prozent während des Zwischenfalls. |
Workers AI
| Alle Inferenzanfragen an Workers AI sind während der gesamten Dauer des Vorfalls fehlgeschlagen. Workers AI ist für die globale Verteilung von Konfigurations- und Routing-Informationen für KI-Anfragen auf Workers KV angewiesen. |
Assets von Pages und Workers
| Statische Assets, die von Cloudflare Pages bereitgestellt werden, und Workers-Assets (wie HTML, JavaScript, CSS, Bilder usw.), werden in Workers KV abgelegt, zwischengespeichert und bei Bedarf abgerufen. Bei Workers-Assets ist die Fehlerquote während dieses Zeitraums im Durchschnitt um etwa 0,06 Prozent aller Anfragen gestiegen. Während des Vorfalls erreichte die Fehlerquote von Pages einen Höchststand von etwa 100 Prozent und kein Pages-Build konnte abgeschlossen werden. |
AutoRAG
| AutoRAG stützt sich sowohl für die Konvertierung von Dokumenten als auch für die Erzeugung von Vektoreinbettungen während der Indizierung auf Workers AI-Modelle und für Abfragen und Suchen auf LLM-Modelle. Während des Vorfalls stand AutoRAG aufgrund der Abhängigkeit von Workers AI nicht zur Verfügung. |
Durable Objects
| SQLite-gestützte Durable Objects nutzen dieselbe zugrundeliegende Speicherinfrastruktur wie Workers KV. Die durchschnittliche Fehlerquote erreichte während des Zwischenfalls einen Spitzenwert von 22 Prozent und sank auf 2 Prozent, als sich die Dienste zu erholen begannen. Namespaces für Durable Objects, die die herkömmliche Schlüssel/Werte-Speicherung verwenden, waren nicht betroffen. |
D1
| D1-Datenbanken greifen auf dieselbe zugrundeliegende Speicherinfrastruktur wie Workers KV und Durable Objects zurück. Die durchschnittliche Fehlerquote erreichte ähnlich wie bei Durable Objects während des Vorfalls einen Höchstwert von 22 Prozent und sank auf 2 Prozent, als die Erholung einsetzte. |
Queues und Ereignisbenachrichtigungen
| Die Vorgänge für Queues-Nachrichten, einschließlich Pushing und Consuming, waren während des Zwischenfalls nicht verfügbar. Queues nutzt KV, um jede Warteschlange den zugrundeliegenden Durable Objects zuzuordnen, die Nachrichten enthalten, die sich in einer Warteschlange befinden. Ereignisbenachrichtigungen nutzen Queues als zugrundeliegenden Übermittlungsmechanismus. |
AI Gateway
| AI Gateway beruht auf Workers und verwendet Workers KV für Client-basierte und interne Konfigurationen. Während des Vorfalls erreichte die Fehlerquote bei AI Gateway einen Höchststand von 97 Prozent der Anfragen, bis es bei den Abhängigkeiten wieder zu einer Normalisierung kam. |
CDN
| Die Infrastruktur für das automatisierte Traffic-Management war einsatzbereit, funktionierte während des Zeitraums der Auswirkungen aber nur eingeschränkt. Insbesondere nahmen die Registrierungsanfragen von Zero Trust-Clients infolge des Ausfalls erheblich zu. Der Anstieg der Anfragen führte zu zusätzlicher Belastung an mehreren Cloudflare-Standorten. Das automatisierte Traffic-Management reagierte darauf, indem es eingehenden CDN-Datenverkehr an nahegelegene Standorte umleitete, um die Auswirkungen für die Kunden abzufedern. Ein Teil des Traffics wurde jedoch nicht wie erwartet umgeleitet und wird deshalb nun untersucht. Von diesem Problem betroffene CDN-Anfragen würden eine erhöhte Latenz, HTTP 499-Fehler und/oder HTTP 503-Fehler verzeichnen. Betroffen waren unter anderem die Cloudflare-Service-Gebiete São Paulo, Philadelphia, Atlanta und Raleigh. |
Workers / Workers for Plattforms
| Workers und Workers for Platforms greifen für Uploads auf einen externen Dienst zurück. Während des Vorfalls wurde bei der Fehlerquote für Workers ein allgemeiner Spitzenwert von etwa 2 Prozent der gesamten Anfragen registriert. Bei Workers for Platforms stieg die Gesamtfehlerquote im gleichen Zeitraum auf einen Spitzenwert von etwa 10 Prozent aller Anfragen. |
Workers-Builds (CI/CD)
| Ab 18:03 Uhr UTC (20:03 Uhr MESZ) konnten Workers-Builds wegen des Ausfalls von Access keine neuen Quellcode-Verwaltungs-Push-Ereignisse mehr empfangen. 100 Prozent der neuen Workers-Builds sind während des Zwischenfalls fehlgeschlagen. |
Browser-Rendering
| Das Browser-Rendering hängt von der Browserisolierung für die Infrastruktur der Browserinstanz ab. Anfragen sowohl an die REST-API als auch über die Workers-Browser-Bindung waren während der Zeit des Vorfalls zu 100 Prozent betroffen. |
Zaraz
| 100 Prozent der Anfragen waren während des Zwischenfalls betroffen. Zaraz nutzt bei der Verarbeitung von Nutzer-Traffic Workers KV-Konfigurationen für Websites. Aufgrund derselben Abhängigkeit scheiterten in diesem Zeitraum Versuche, Aktualisierungen der Zaraz-Konfigurationen zu speichern. Aus unserer Überwachung wissen wir aber, dass davon nur ein einziger Nutzer betroffen war. |
Workers KV ist als ein von uns so genannter „Coreless“-Dienst konzipiert. Das bedeutet, dass es keinen Single Point of Failure geben sollte, da der Dienst an jedem unserer Standorte weltweit unabhängig läuft. Allerdings greift Workers KV heute auf einen zentralen Datenspeicher zurück, um einen allgemeingültigen Datenbestand als Referenz (Single Source of Truth) bereitzustellen. Ein Ausfall dieses Speichers führte zu einem vollständigen Ausfall der Lese- und Schreibvorgänge auf die KV-Namespaces, die von allen Diensten bei Cloudflare verwendet werden.
Workers KV wird derzeit auf eine deutlich widerstandsfähigere Infrastruktur für den zentralen Speicher umgestellt. Leider hat der aktuelle Vorfall eine Lücke bei der Abdeckung zutage befördert. Workers KV hat einen Speicheranbieter entfernt, während wir das KV-Backend neu gestaltet haben (was die Migration zu Cloudflare R2 umfasste), um (durch die ursprüngliche Datensynchronisationsarchitektur verursachte) Probleme mit der Datenkonsistenz zu vermeiden und die Unterstützung der Datenresidenz-Anforderungen zu verbessern.
Einer unserer Grundsätze lautet, Cloudflare-Dienste so weit wie möglich auf unserer eigenen Plattform zu entwickeln. Workers KV bildet da keine Ausnahme. Viele unserer internen und externen Dienste stützen sich stark auf Workers KV. Unter normalen Umständen hilft uns das dabei, robustere Services bereitzustellen, damit Serviceteams nicht versuchen müssen, ihre eigenen Speicherdienste zu erstellen. Im vorliegenden Fall hat jedoch ein Dominoeffekt die Auswirkungen des Ausfalls von Workers KV verschärft und den Radius des Schadens erheblich vergrößert.
Zeitlicher Ablauf und Auswirkungen des Vorfalls
Die Zeitleiste zu dem Vorfall, die sich über die anfänglichen Auswirkungen, die Untersuchung, die Ermittlung der Grundursache und die Abhilfemaßnahmen erstreckt, ist unten ausführlich dargestellt.
Fehlerquoten von Workers KV zur Speicherinfrastruktur. 91 Prozent der Anfragen an KV sind während des Vorfalls fehlgeschlagen.
Cloudflare Access-Anteil erfolgreicher Anfragen. Cloudflare Access greift direkt auf Workers KV zurück und ist ein guter Indikator, um die Verfügbarkeit von Workers KV über einen gewissen Zeitraum zu messen.
Alle Zeitangaben beziehen sich auf die Koordinierte Weltzeit (Universal Time Coordinated – UTC).
Zeit | Ereignis |
|---|
12.06.2025, 17:52 Uhr | BEGINN DES VORFALLS
Das Cloudflare WARP-Team bemerkt, dass die Registrierung neuer Geräte fehlschlägt. Es beginnt, diese Fehler zu untersuchen, und meldet einen Vorfall. |
12.06.2025, 18:05 Uhr | Wegen der schnellen Steigerung der Fehlerquote erhält das Cloudflare Access-Team eine Warnmeldung. Die Service-Level-Ziele unterschreiten für mehrere Dienste die Vorgaben, weshalb Warnmeldungen an die betroffenen Teams geschickt werden. |
12.06.2025, 18:06 Uhr | Mehrere dienstspezifische Vorfälle werden zu einem einzigen Vorfall zusammengefasst, nachdem wir eine gemeinsame Ursache (Nichtverfügbarkeit von Workers KV) identifiziert haben. Die Priorität des Vorfalls wird auf P1 hochgestuft. |
12.06.2025, 18:21 Uhr | Die Priorität des Vorfalls wird von P1 auf P0 hochgestuft, weil der Schweregrad der Auswirkungen deutlich geworden ist. |
12.06.2025, 18:43 Uhr | Cloudflare Access beginnt, Optionen zur Beseitigung der Abhängigkeit von Workers KV zu prüfen, indem mit dem Workers KV-Entwicklungsteam zu einem anderen unterstützenden Datenspeicher migriert wird. Es handelt sich dabei um eine proaktive Maßnahme für den Fall, dass der Ausfall der Speicherinfrastruktur länger anhält. |
12.06.2025, 19:09 Uhr | Zero Trust-Gateway beginnt, die Abhängigkeiten von Workers KV zu beseitigen, indem Identitäts- oder Gerätestatus-bezogene Regeln auf kontrollierte Weise aufgehoben werden. |
12.06.2025, 19:32 Uhr | Access und Device Posture erzwingen das Ablehnen von Identitäts- und Gerätestatus-Anfragen, um die Beanspruchung von Workers KV zu reduzieren, bis der externe Dienst wieder online ist. |
12.06.2025, 19:45 Uhr | Cloudflare-Teams arbeiten weiterhin daran, eine Workers KV-Version mit einen alternativen Begleit-Datenspeicher bereitzustellen und kritische Dienste dazu zu bringen, Konfigurationsdaten in diesem Speicher abzulegen. |
12.06.2025, 20:23 Uhr | Mit der Wiederherstellung der Speicherinfrastruktur beginnen die Dienste, wieder normal zu funktionieren. Weil die Services noch dabei sind, die Zwischenspeicher neu zu befüllen, verzeichnen wir weiterhin eine nicht zu vernachlässigende Fehlerquote und einen infrastrukturell bedingt beschränkten Durchsatz. |
12.06.2025, 20:25 Uhr | Access und Device Posture nehmen Aufrufe an Workers KV erneut auf, da der externe Dienst wieder funktioniert. |
12.06.2025, 20:28 Uhr | ENDE DER AUSWIRKUNGEN
Service-Level-Ziele kehren auf das Niveau zurück, das sie vor dem Zwischenfall verzeichnet hatten. Cloudflare-Mitarbeitende überwachen weiterhin die Systeme, um sicherzustellen, dass die Dienste während der Erholung der abhängigen Systeme keine Beeinträchtigungen verzeichnen. |
| ENDE DES VORFALLS
Das Cloudflare-Team registriert, dass alle betroffenen Dienste wieder normal funktionieren. Warnmeldungen zu Service-Level-Zielen werden aufgehoben. |
Abhilfe- und Folgemaßnahmen
Wir ergreifen sofortige Maßnahmen, um die Ausfallsicherheit von Diensten zu erhöhen, die von Workers KV und unserer Speicherinfrastruktur abhängen. Dies umfasst bestehende planmäßige Maßnahmen, die infolge dieses Vorfalls vorgezogen werden.
Dazu zählen unter anderem Bemühungen, einzelne Abhängigkeiten von Speicherinfrastrukturen zu beseitigen, die wir nicht besitzen, damit wir künftig kritische Dienste (wie Access, Gateway und WARP) leichter wiederherstellen können.
Konkret bedeutet das:
(Aktiv in Bearbeitung): Wir ziehen unsere Bemühen vor, die Redundanz innerhalb der Workers KV-Speicherinfrastruktur zu erhöhen und die Abhängigkeit von einzelnen Anbietern zu beseitigen. Während des Vorfalls haben wir für den Fall, dass er länger andauert, mit der Umstellung kritischer KV-Namespaces auf unsere eigene Infrastruktur und dem Auffüllen dieser Namespaces begonnen.
(Aktiv in Bearbeitung): Kurzfristige Maßnahmen zur Begrenzung des Schadensradius für einzelne Produkte, die von diesem Vorfall betroffen waren. Ziel ist es, dass jedes Produkt besser gegen Ausfälle geschützt ist, die durch einen Single Point of Failure verursacht werden – einschließlich Abhängigkeiten von Drittanbietern.
(Aktiv in Bearbeitung): Implementierung von Werkzeugen, mit denen sich Namespaces bei Vorfällen in der Speicherinfrastruktur schrittweise wieder aktivieren lassen. So können wir die Verfügbarkeit wichtiger Abhängigkeiten wie Access und WARP sicherstellen, ohne beim Auffüllen der Zwischenspeicher einen Denial-of-Service gegenüber unserer eigenen Infrastruktur zu riskieren.
Diese Auflistung erhebt keinen Anspruch auf Vollständigkeit. Unsere Teams überprüfen kontinuierlich Designentscheidungen und bewerten die Infrastrukturanpassungen, die wir sowohl kurzfristig (unmittelbar) als auch langfristig vornehmen müssen, um derartige Vorfälle in Zukunft zu vermeiden.
Es war ein schwerwiegender Ausfall und uns ist bewusst, dass große und kleinere Unternehmen, Organisationen und Institutionen für den Schutz und/oder den Betrieb ihrer Websites, Anwendungen sowie ihrer Zero Trust- und Netzwerkinfrastruktur auf uns angewiesen sind. Wir möchten uns ausdrücklich für die entstandenen Unannehmlichkeiten entschuldigen und versichern, dass wir daran arbeiten, die Ausfallsicherheit unserer Dienste zu erhöhen.