Cloudflare: Ein fehlerhafter Cleanup-Task zieht Internet-Routen zurück

Unternehmen und Produkt

Cloudflare ist ein globaler Anbieter für IT-Infrastruktur und bietet unter anderem CDN-, Sicherheits- und Netzwerkdienste an. Die Funktion Bring Your Own IP (BYOIP) ermöglicht es Kunden, ihre eigenen IP-Adressbereiche über das Cloudflare-Netzwerk anzukündigen. Diese Funktion ist besonders wichtig für Organisationen, die die Kontrolle über ihre IP-Adressbereiche behalten möchten, aber gleichzeitig von dem globalen Routing sowie den Sicherheits- und Performance-Funktionen des Unternehmens profitieren möchten.

Da Cloudflare auf der Netzwerkschicht arbeitet, können Probleme bei der IP-Adressankündigung direkte Auswirkungen auf die Erreichbarkeit im gesamten Internet haben.

Was war passiert?

Der Incident wurde durch einen neu ausgerollten automatisierten Cleanup-Task ausgelöst, der ungenutzte BYOIP-Präfixe entfernen sollte. Aufgrund eines Bugs bei der API-Abfrage identifizierte der Task fälschlicherweise alle BYOIP-Präfixe als zur Löschung vorgesehen und begann, Präfixe in großem Maßstab zurückzuziehen, anstatt nur eine begrenzte Teilmenge.

Dies führte zu folgender Ereigniskette:

• Kunden-IP-Präfixe wurden aus dem BGP-Routing zurückgezogen
• Der Datenverkehr wurde nicht mehr zu Cloudflare geroutet
• Endnutzer erlebten Verbindungsabbrüche und Timeouts 
• Einige Services, wie z. B. die öffentliche Resolver-Schnittstelle von Cloudflare, lieferten Fehlermeldungen

Betroffene Nutzer beobachteten zunächst BGP Path Hunting, bei dem der Traffic versucht, alternative Routen zu finden, bevor er letztlich fehlschlägt.

Die Auswirkungen waren unterschiedlich:

• Einige Kunden konnten den Service manuell über das Dashboard wiederherstellen
• Andere benötigten umfangreichere Wiederherstellungsmaßnahmen aufgrund entfernter Konfigurationen
• Bei einem Teil der Kunden wurde eine vollständige Wiederherstellung der Service-Bindings über die Edge-Infrastruktur hinweg erforderlich

Die Root Cause war ein Bug in einem internen Cleanup-Task, der mit der Cloudflare Addressing API interagierte.

Konkret:

• Der Task fragte einen API-Endpunkt mit dem Parameter pending_delete ab
• Aufgrund einer fehlerhaften Verarbeitung leerer Werte lieferte die API alle Präfixe zurück, anstatt nur diejenigen, die zur Löschung vorgesehen waren
• Das System interpretierte dies fälschlicherweise als Anweisung, alle BYOIP-Präfixe zu entfernen

Dies führte zu einem unbeabsichtigten Rückzug von IP-Routen in großem Maßstab.

Mehrere Faktoren verstärkten die Auswirkungen:

• Fehlende Schutzmechanismen für Löschvorgänge in großem Umfang
• Unzureichende Testabdeckung für automatisierte Hintergrundprozesse
• Enge Kopplung zwischen Konfigurationszustand und operativer Ausführung

Diese Kombination ermöglichte es, dass ein einzelner fehlerhafter Prozess Änderungen direkt in die Produktionsinfrastruktur übernahm.

Timeline

• 5. Februar 2026: Fehlerhafter Code für eine Unteraufgabe des Cleanup-Tasks wird in den Produktionscode integriert
• 17:46 UTC: Code wird in der Produktion bereitgestellt (Release der Addressing API)
• 17:56 UTC: Rückzug von Präfixen beginnt: erste Auswirkungen
• 18:13 UTC: Cloudflare wird nach ersten Ausfällen auf 1.1.1.1 aufmerksam gemacht
• 18:18 UTC: Interner Incident wird gemeldet
• 18:21 UTC: Das Addressing-API-Team wird eingebunden, die Untersuchung beginnt
• 18:46 UTC: Fehlerhafter Prozess wird identifiziert und deaktiviert: Rückzug von Präfixen wird gestoppt
• 19:11 UTC: Wiederherstellungsmaßnahmen für zurückgezogene und entfernte Präfixe beginnen
• 19:19 UTC: Kunden starten mit Self-Service-Maßnahmen über das Dashboard (erneute Ankündigung von Präfixen)
• 19:44 UTC: Zusätzliche Wiederherstellungsmaßnahmen: Datenbank-Restore für entfernte Präfixe
• 20:30 UTC: Großteil der Präfixe wiederhergestellt (teilweise Wiederherstellung)
• 21:08 UTC: Globale Konfigurationsbereitstellung zur Wiederherstellung verbleibender Präfixe
• 23:03 UTC: Vollständige Wiederherstellung abgeschlossen: Incident behoben

‍

Time to Detection (TTD / Zeit bis zur Erkennung): 17 Minuten

Time to Resolution (TTR / Zeit bis zur Behebung): 5 Stunden und 7 Minuten (ab Erkennung)

Wer war betroffen?

Der Incident betraf in erster Linie Kunden, die den Bring Your Own IP (BYOIP)-Service von Cloudflare nutzten. Der Umfang der Auswirkungen lässt sich wie folgt quantifizieren:

• Rückzug von Präfixen: Von insgesamt 4.306 weltweit angekündigten BYOIP-Präfixen wurden 1.100 Präfixe (ca. 25 %) unbeabsichtigt aus dem Cloudflare-Netzwerk zurückgezogen.
• Auswirkungen auf die Infrastruktur: Während des Incidents wurden an einem bestimmten BGP-Peer insgesamt 6.500 Präfixe beobachtet; die 1.100 zurückgezogenen Präfixe machten einen erheblichen Anteil der gesamten von Cloudflare an diesen Nachbarn angekündigten Route
• Auswirkungen je nach Kundengruppe:
  
  • 800 Präfixe wurden relativ früh (bis 20:20 UTC) über Dashboard-Toggles oder automatisierte Reverts wiederhergestellt
  • 300 Präfixe waren stärker betroffen, da ihre Service-Konfigurationen vollständig von der Edge-Infrastruktur entfernt wurden. Dadurch war keine Selbstbehebung möglich und eine manuelle Wiederherstellung durch Engineers erforderlich
• Service-spezifische Ausfälle:
  
  • Magic Transit & Spectrum: Anwendungen, die durch diese Services geschützt waren, wurden nicht mehr im Internet angekündigt, was zu Timeouts führteCore.
  • Core CDN & Security: Der Traffic wurde nicht mehr zu Cloudflare „gezogen“, wodurch Websites in diesen IP-Bereichen nicht erreichbar waren
  • Dedicated Egress: Nutzer, die BYOIP für ausgehenden Traffic (Gateway) verwendeten, konnten keine Ziele mehr erreichens.
  • 1.1.1.1 Information Site: Während die DNS-Auflösung weiterhin funktionierte, lieferte die Website one.one.one.one HTTP-403-Fehler („Edge IP Restricted“) zurück

Wie reagierte Cloudflare?

Cloudflare reagierte mit folgenden Maßnahmen:

• Identifizierung und Deaktivierung des fehlerhaften Cleanup-Tasks
• Wiederherstellung der zurückgezogenen Präfixe 
• Ermöglichung von Self-Recovery für betroffene Kunden über das Dashboard
• Manuelle Wiederherstellung betroffener Konfigurationen

Nach dem Incident führte Cloudflare mehrere Maßnahmen zur Behebung und Prävention ein:

• Verbesserung der API-Schema-Validierung
• Einführung sichererer Rollback-Mechanismen
• Erweiterung des Monitorings für umfangreiche Konfigurationsänderungen
• Implementierung von Circuit Breakern zur Vermeidung übermäßiger automatisierter Aktionen

Diese Maßnahmen standen im Einklang mit der „Code Orange: Fail Small“-Initiative des Unternehmens, die darauf abzielt, den Blast Radius zu reduzieren und die Sicherheit von Deployments zu erhöhen.

‍Wie kommunizierte Cloudflare?

Cloudflare kommunizierte transparent durch ein detailliertes öffentliches Postmortem.

Der Bericht enthielt:

• Eine vollständige technische Analyse des Vorfalls
• Eine präzise Zeitleiste der Ereignisse
• Eine klare Erklärung des Systemverhaltens
• Konkrete Maßnahmen zur Behebung

Das Unternehmen betont Verantwortungsbewusstsein und Lernbereitschaft und unterstreicht sein Engagement, die Zuverlässigkeit seiner Systeme kontinuierlich zu verbessern.

Wichtige Learnings für andere Teams

• Automatisierte Prozesse erfordern strikte Schutzmechanismen:
  Hintergrund-Tasks, die auf Produktionsdaten zugreifen, müssen über starke Validierungen und klare Scope-Begrenzungen verfügen.
• Kleine Bugs können globale Auswirkungen haben:
  In verteilten Systemen können selbst kleine Logikfehler schnell eskalieren und große Teile der Infrastruktur beeinträchtigen.
• Blast Radius kontrollieren:
  Operationen im großen Maßstab (z. B. das Löschen oder Zurückziehen von Ressourcen) müssen Circuit Breaker und Mechanismen für schrittweise Rollouts enthalten.
• Gewünschten und operativen Zustand trennen:
  Eine enge Kopplung von Konfiguration und Ausführung erschwert Rollbacks und verlängert die Wiederherstellungszeit.
• Über User-Workflows hinaus testen:Tests sollten auch systeminitiierte Aktionen abdecken, nicht nur nutzergetriebene Szenarien.

Kurz erklärt

Bei Cloudflare kam es durch einen fehlerhaften Cleanup-Task zu einem SEV-1-Ausfall, bei dem unbeabsichtigt Kunden-IP-Präfixe zurückgezogen wurden. Dies führte zu weitreichenden Erreichbarkeitsproblemen für BYOIP-Kunden. Der Incident verdeutlicht die Risiken automatisierter Prozesse ohne ausreichende Schutzmechanismen sowie die Bedeutung eines kontrollierten Blast Radius in Produktionssystemen.

So kann ilert helfen 

Bei komplexen BGP- oder API-Ausfällen zählt jede Sekunde. ilert unterstützt Teams dabei, Ausfallzeiten zu minimieren und effektiv zu reagieren. 

Dies wird ermöglicht durch:

• Fortschrittliche Alarmierung: Es wird sichergestellt, dass die richtigen Netzwerk-Engineers sofort per Voice, SMS oder Push-Benachrichtigung alarmiert werden – ohne Verzögerung durch „E-Mail-Silos“.
• Incident-Kommunikation: Kunden werden mit gebrandeten Statusseiten auf dem Laufenden gehalten. Diese werden automatisch aktualisiert – das Support-Team wird während eines Incidents entlastet.
• Bereitschaftsmanagement: Bereitschaftspläne können so organisiert werden, dass jederzeit ein „Code Orange“-Experte verfügbar ist, um auf kritische Incidents zu reagieren.