CLOUDFLARE

Automatische Auswahl und erlaubte Algorithmen sind getrennte Stellgrößen. Für bestehende Skripte zählt damit nicht nur, ob die alte Schnittstelle noch existiert.

Cloudflare zufolge konnten einige Kunden am 23. August von 01:06 bis 01:54 UTC vermehrt 5xx-Fehler und Timeouts im Verkehr zwischen Origins in Nordamerika und seinem Rechenzentrum in Singapur feststellen. Der Vorfall ist abgeschlossen; die konkrete öffentliche Beschreibung wurde jedoch erst nach dem angegebenen Wirkungszeitraum veröffentlicht.

Cloudflare meldete ein Netzwerkleistungsproblem im asiatisch-pazifischen Raum und acht Minuten 36 Sekunden später einen umgesetzten Fix. Trotzdem wechselte die verknüpfte Network-Komponente in beiden Einträgen nur von operativ zu operativ. Aggregierter Komponentenstatus und Vorfallnarrativ messen damit unterschiedliche Dinge.

Cloudflare schloss am 4. August zwei getrennte Workers-Störungen. In der Laufzeitumgebung erschien ein unbeabsichtigtes globales `Temporal`-Objekt, dessen Uhr 1970 meldete. Im Deployment-Pfad wies eine Assertion die Kombination aus `nodejs_compat` und einem neuen Kompatibilitätsdatum zurück. Cloudflare nannte keine gemeinsame Ursache. Gemeinsam zeigen die Fälle dennoch, dass eine Plattform sowohl die Semantik einer sichtbaren Fähigkeit als auch die Zulässigkeit einer Lieferkonfiguration als Produktionsvertrag behandeln muss.

Cloudflare erklärte am 3. August einen Vorfall bei Workers Builds nach rund einer Stunde und 51 Minuten für behoben. Der aufschlussreichste Zeitpunkt lag jedoch 34 Minuten vor dem Ende: Um 15:38 Uhr UTC schlugen Builds nach Angaben des Unternehmens nicht mehr fehl, konnten sich aber weiterhin verzögern. Damit wurde aus einem Fehlerproblem ein Durchsatzproblem. Wer digitale Lieferketten steuert, muss diese Zustände getrennt prüfen—vom Quellstand über den Build und das Artefakt bis zur tatsächlich laufenden Version.

Cloudflare hat eine Gateway-Störung behoben, bei der Kunden mit in London verankerten dedizierten IPv4-Egress-Adressen möglicherweise das öffentliche Internet nicht erreichen konnten. Der öffentliche Vorgang dauerte 2 Stunden, 17 Minuten und 50 Sekunden. Er benennt die betroffene Komponente und die Statusfolge, aber weder Ursache noch Größenordnung. Für die technische Bewertung ist deshalb nicht „London ist ausgefallen“ der richtige Satz. Entscheidend ist, dass eine kontrollierte Ausgangsidentität nur so verfügbar ist wie der Providerpfad, der sie trägt.

Am 27. Juni 2024 beeinträchtigten zwei getrennte BGP-Ereignisse die Erreichbarkeit des öffentlichen DNS-Resolvers 1.1.1.1: eine unzulässige Ursprungsankündigung für 1.1.1.1/32 und ein davon unabhängiges Route Leak für 1.1.1.0/24. Der Vorfall zeigt, weshalb Registerdaten und RPKI-Nachweise zwar unverzichtbare Belege liefern, aber erst wirksame Filter, kontrollierte Blackhole-Verfahren, belastbares Monitoring und eine eindeutig zugeordnete betriebliche Verantwortung daraus Schutz machen.

Eine Bereinigung veralteter Präfixlisten ließ nach Angaben von Cloudflare eine syntaktisch gültige, aber semantisch zu weit gefasste IPv6-Exportregel zurück. Der Vorfall zeigt, warum Routing-Automatisierung nicht allein am Quelltext, sondern an tatsächlich exportierbaren Routen, Nachbarschaftsbeziehungen und extern sichtbaren BGP-Updates geprüft werden muss.

Der Ausfall vom 20. Februar 2026 zeigt, warum die Berechtigung zur Nutzung eines IP-Präfixes, dessen vorgesehene BGP-Ankündigung und die tatsächlich beobachtbare Erreichbarkeit getrennte Beweise sind. Verantwortbare Automatisierung muss diese Ebenen nicht nur verändern, sondern nach jeder Änderung nachweisbar miteinander abgleichen.

Die Angriffskampagne vom März 2013 zeigte, wie offene rekursive DNS-Dienste, gefälschte Quelladressen und gemeinsam genutzte Verbindungswege viele kleine Konfigurationsmängel zu erheblichen externen Schäden bündeln können. Verantwortlichkeit entsteht dort, wo sich nachweisen lässt, welcher Betreiber einen wirksamen Kontrollpunkt beherrschte und ob seine Reparatur im laufenden Netz tatsächlich funktionierte.

Cloudflare eröffnete am 31. Juli um 11:51:07 UTC einen geringfügigen Vorfall, der zunächst Analytics, Dashboard und zugehörige APIs betraf. Später kamen Pages- und Workers-Builds hinzu. Um 12:43:57 ging eine Korrektur in die Überwachung, um 13:01:59 wurde der Vorfall beendet. Laut Cloudflare blieben die Auslieferung zwischengespeicherter Dateien über das CDN und andere Sicherheitsfunktionen am Edge unbeeinträchtigt. Damit fiel nicht das gesamte Netz aus, sondern ein Teil der Beobachtungs-, Verwaltungs- und Bereitstellungsebene.