Cloudflare-storing op 18 november 2025

Op 18 november 2025 om 11:20 UTC (alle tijdstippen in deze blog zijn UTC) heeft het netwerk van Cloudflare ernstige problemen ondervonden bij het leveren van kernnetwerkverkeer. Internetgebruikers die de sites van onze klanten probeerden te bezoeken, zagen een foutpagina met de melding dat er problemen waren met het netwerk van Cloudflare.

Het probleem werd niet, direct of indirect, veroorzaakt door een cyberaanval of een andere vorm van kwaadaardige activiteit. Het werd daarentegen veroorzaakt door een wijziging in de machtigingen van een van onze databasesystemen, waardoor de database meerdere vermeldingen uitvoerde in een feature-bestand dat werd gebruikt door ons botbeheer-systeem. Hierdoor verdubbelde het feature-bestand in omvang. Het groter dan verwachte feature-bestand werd vervolgens verspreid naar alle machines in ons netwerk.

De software die op deze machines draait en het verkeer door ons netwerk leidt, leest dit functiebestand om ons botbeheersysteem up-to-date te houden in de context van voortdurend veranderende bedreigingen. De software was geconfigureerd met een limiet op de grootte van het feature-bestand. Deze limiet was kleiner dan het dubbele van de oorspronkelijke grootte. Daardoor faalde de software.

We vermoedden aanvankelijk ten onrechte dat de symptomen die we zagen werden veroorzaakt door een grootschalige DDoS-aanval. Al snel slaagden we er in het kernprobleem correct te identificeren en konden we de verspreiding van het groter dan verwachte feature-bestand stoppen en het vervangen door een eerdere versie van het bestand. Vanaf 14:30 uur verliep het kernverkeer grotendeels normaal. De daaropvolgende uren hebben we gewerkt aan het beperken van de grotere belasting op verschillende onderdelen van ons netwerk, omdat het verkeer weer snel online kwam. Om 17:06 functioneerden alle systemen bij Cloudflare opnieuw normaal.

Wij betreuren de gevolgen voor onze klanten en voor het internet in het algemeen. Gezien het belang van Cloudflare in het Internet-ecosysteem is elke storing van één van onze systemen niet aanvaardbaar. Het feit dat gedurende een bepaalde periode ons netwerk het verkeer niet kon doorsturen, is voor ieder lid van ons team zeer pijnlijk. Wij weten dat we u teleurgesteld hebben.

In dit bericht leest u in detail wat er precies is gebeurd en welke systemen en processen faalden. Dit is meteen ook de eerste, maar zeker niet de laatste maatregel die we van plan zijn te treffen om ervoor te zorgen dat een dergelijke storing zich niet meer voordoet.

De onderstaande grafiek toont het aantal 5xx-fout-HTTP-statuscodes dat door het Cloudflare-netwerk werd verzonden. Dit is normaal gezien een zeer laag aantal, en dat was ook zo tot net voor de storing.

Het volume vóór 11:20 is de verwachte basislijn van 5xx-fouten die in ons netwerk zijn waargenomen. De piek en de daaropvolgende schommelingen geven aan dat ons systeem faalt omdat het verkeerde feature-bestand is geladen. Opvallend is dat ons systeem zich daarna een tijdje heeft hersteld. Dit was zeer ongebruikelijk gedrag voor een interne fout.

De verklaring was dat het bestand elke vijf minuten werd gegenereerd door een query die werd uitgevoerd op een ClickHouse-databasecluster, dat geleidelijk werd bijgewerkt om het beheer van machtigingen te verbeteren. Er werden alleen incorrecte gegevens gegenereerd wanneer de query werd uitgevoerd op een deel van het cluster dat was bijgewerkt. Hierdoor bestond de kans dat er elke vijf minuten een goede of slechte set configuratiebestanden werd gegenereerd en snel over het netwerk werd verspreid.

Door deze schommelingen was het onduidelijk wat er precies aan de hand was. Het hele systeem herstelde zich en viel dan opnieuw uit, omdat soms goede en soms slechte configuratiebestanden op ons netwerk terechtkwamen. Aanvankelijk dachten we dat het om een aanval ging. Uiteindelijk genereerde elk ClickHouse-knooppunt het slechte configuratiebestand en stabiliseerde de schommeling zich in de falende status.

De fouten bleven optreden totdat het onderliggende probleem om 14:30 uur werd geïdentificeerd en opgelost. We hebben het probleem opgelost door de generatie en verspreiding van het slechte feature-bestand te stoppen en handmatig een bekend goed bestand in te voegen in de distributiewachtrij voor feature-bestanden. Vervolgens hebben we een herstart van onze kernproxy geforceerd.

De resterende 'long tail' in de grafiek hierboven is van ons team dat de resterende services die in een slechte staat waren terechtgekomen, opnieuw opstartte. Het volume met foutcode 5xx was om 17:06 weer normaal.

De volgende diensten werden getroffen:

Naast het vertonen van HTTP 5xx-fouten, observeerden we een veel hogere latentie in de reacties van ons CDN tijdens de impactperiode. Dit kwam doordat onze debug- en observatiesystemen een groot CPU-verbruik hadden. Deze systemen verbeteren automatisch niet-onderschepte fouten met extra debug-informatie.

Elk verzoek aan Cloudflare verloopt via een duidelijk gedefinieerd pad door ons netwerk. Het kan afkomstig zijn van een browser die een webpagina laadt, een mobiele app die een API aanroept of geautomatiseerd verkeer van een andere service. Deze verzoeken eindigen eerst op onze HTTP- en TLS-laag en stromen vervolgens door naar ons kern-proxysysteem (dat we FL noemen, wat staat voor "Frontline"), en ten slotte via Pingora, dat cache-lookups uitvoert of indien nodig gegevens ophaalt uit de oorsprong.

Eerder gaven we hier meer details over hoe de kernproxy. 

Terwijl een verzoek door de kernproxy loopt, voeren we de verschillende beveiligings- en prestatieproducten uit die beschikbaar zijn in ons netwerk. De proxy past de unieke configuratie en instellingen van elke klant toe, van het afdwingen van WAF-regels en DDoS-bescherming tot de routing van verkeer naar het Developer Platform en R2. Dit wordt bereikt door een set domeinspecifieke modules die de configuratie- en beleidsregels toepassen op het verkeer dat via onze proxy verloopt.

Eén van die modules, het botbeheer, was de oorzaak van de storing van vandaag. 

Het botbeheer van Cloudflare omvat onder andere een machine learning-model dat we gebruiken om botscores te genereren voor elk verzoek dat via ons netwerk gaat. Onze klanten gebruiken botscores om te bepalen welke bots al of niet toegang krijgen tot hun sites.

Het model neemt een 'feature'-configuratiebestand als invoer. Een kenmerk is in deze context een individueel kenmerk dat door het machine learning-model wordt gebruikt om te voorspellen of het verzoek geautomatiseerd is of niet. Het functieconfiguratiebestand is een verzameling van afzonderlijke functies.

Dit feature-bestand wordt elke paar minuten vernieuwd en gepubliceerd in ons volledig netwerk. Zo kunnen we reageren op veranderingen in de verkeersstromen op het internet. Dit biedt ons de mogelijkheid te reageren op nieuwe soorten bots en nieuwe bot-aanvallen. Het is daarom van groot belang dat dit regelmatig en snel wordt doorgevoerd, aangezien kwaadaardige figuren snel van tactiek veranderen.

Een wijziging in het onderliggende ClickHouse-querygedrag (hieronder uitgelegd) dat dit bestand genereert, resulteerde in een groot aantal dubbele 'feature'-rijen in dit bestand. Hierdoor werd de grootte van het eerder vaste functieconfiguratiebestand gewijzigd, waardoor de botmodule een foutmelding gaf.

Als gevolg hiervan werden HTTP 5xx-foutcodes weergegeven door het kernproxysysteem dat de verwerking van het verkeer voor onze klanten afhandelt, voor al het verkeer dat afhankelijk was van de botmodule. Dit had ook gevolgen voor Workers KV en Access, die afhankelijk zijn van de kernproxy.

Los van dit incident werken we momenteel aan de migratie van ons klantverkeer naar een nieuwe versie van onze proxyservice, intern bekend als FL2. Beide versies werden getroffen door het probleem, hoewel de waargenomen impact verschillend was.

Klanten die de nieuwe FL2-proxy-engine gebruikten, zagen HTTP 5xx-fouten. Klanten op onze oude proxy-engine, FL, zagen geen fouten, maar de botscores werden niet correct gegenereerd. Hierdoor kreeg al het verkeer een botscore van nul. Klanten die regels hadden geïmplementeerd om bots te blokkeren, werden geconfronteerd met een hoog aantal valse positieven. Klanten die onze botscore niet in hun regels gebruikten, merkten geen impact.

Een ander symptoom dat we zagen, bracht ons op het verkeerde been waardoor we aanvankelijk geloofden dat het om een aanval ging: de statuspagina van Cloudflare was offline. De statuspagina wordt volledig gehost op de infrastructuur van Cloudflare en is niet afhankelijk van Cloudflare. Hoewel het toeval bleek te zijn, vermoedde een aantal teamleden die het probleem moesten diagnosticeren, dat een aanvaller mogelijk zowel onze systemen als onze statuspagina had aangevallen. Bezoekers van de statuspagina kregen op dat moment een foutmelding:

In de interne chatroom voor incidenten waren we bezorgd dat dit een voortzetting zou kunnen zijn van de recente reeks grootschalige Aisuru DDoS-aanvallen:

Ik gaf hierboven al aan dat een wijziging in het onderliggende querygedrag ertoe leidde dat het feature-bestand een groot aantal dubbele rijen bevatte. Het betreffende databasesysteem maakt gebruik van de software van ClickHouse.

Voor context is het nuttig te weten hoe gedistribueerde query's van ClickHouse werken. Een ClickHouse-cluster bestaat uit vele shards. Om gegevens uit alle shards op te vragen, hebben we zogenaamde gedistribueerde tabellen (aangestuurd door de tabel engine Distributed) in een database met de naam default. De Distributed engine vraagt onderliggende tabellen op in een database r0. De onderliggende tabellen zijn de locatie waar gegevens op elke shard van een ClickHouse-cluster worden opgeslagen.

Query's naar de gedistribueerde tabellen worden via een gedeeld systeemaccount uitgevoerd. Als onderdeel van de inspanningen om de beveiliging en betrouwbaarheid van onze gedistribueerde query's te verbeteren, werken we er aan deze onder de oorspronkelijke gebruikersaccounts uit te voeren.

Tot nu toe zagen ClickHouse-gebruikers alleen de tabellen in de standaarddatabase bij het opvragen van tabelmetagegevens uit ClickHouse-systeemtabellen, zoals system.tables of system.columns.

Omdat gebruikers al impliciet toegang hebben tot onderliggende tabellen in r0, hebben we om 11:05 een wijziging doorgevoerd om deze toegang expliciet te maken, zodat gebruikers ook de metagegevens van deze tabellen kunnen zien. Door ervoor te zorgen dat alle gedistribueerde subquery's onder de initiële gebruiker kunnen worden uitgevoerd, kunnen query-limieten en toegangsverleningen op een meer gedetailleerde manier worden geëvalueerd. Zo wordt voorkomen dat één slechte subquery van een gebruiker gevolgen heeft voor anderen.

Door de hierboven vermelde wijziging hebben alle gebruikers toegang tot nauwkeurige metagegevens over de tabellen waar zij toegang toe hebben. Helaas zijn er in het verleden aannames gedaan dat de lijst met kolommen die door een dergelijke query wordt geretourneerd, alleen de "standaard "-database zou bevatten:

SELECTEER naam, type VAN systeem.kolommen WAAR tabel = 'http_requests_features' sorteren op naam;

Merk op dat de query niet filtert op de naam van de database. Nu we de expliciete toekenningen geleidelijk aan uitrollen bij gebruikers van een bepaald ClickHouse-cluster begon de bovenstaande query na de wijziging om 11:05 "duplicaten" van kolommen weer te geven, omdat deze betrekking hadden op onderliggende tabellen die waren opgeslagen in de r0-database.

Helaas was dit het type query dat werd uitgevoerd door de bestandsgeneratielogica van de botbeheerfunctie om elke invoer"functie" te bouwen voor het bestand dat aan het begin van deze sectie werd vermeld. 

De bovenstaande query retourneert een tabel met kolommen zoals de weergegeven tabel (vereenvoudigd voorbeeld):

Als onderdeel van de extra rechten die aan de gebruiker werden verleend, bevatte het antwoord nu echter alle metagegevens van het r0- schema, wat effectief meer dan het dubbele aantal rijen in het antwoord opleverde, wat uiteindelijk van invloed was op het aantal rijen (d.w.z. functies) in de uiteindelijke bestandsuitvoer. 

Elke module die op onze proxyservice draait, heeft een aantal limieten om onbeperkt geheugenverbruik te voorkomen en om geheugen vooraf toe te wijzen en de prestaties te optimaliseren. In dit specifieke geval heeft het botbeheer-systeem een limiet op het aantal machine learning-functies dat tijdens runtime kan worden gebruikt. Momenteel ligt die limiet op 200, ruim boven ons huidige gebruik van ongeveer 60 functies. Ook hier geldt dat de limiet bestaat omdat we om prestatieredenen vooraf geheugen toewijzen aan de functies.

Toen het slechte bestand met meer dan 200 kenmerken naar onze servers werd verspreid, werd deze limiet bereikt, wat leidde tot paniek in het systeem. De FL2 Rust-code die de controle uitvoert en de bron is van de onverwerkte fout, wordt hieronder weergegeven:

Dit resulteerde in de daaropvolgende paniekreactie, die op haar beurt resulteerde in een 5xx-fout:

thread fl2_worker_thread raakte in paniek: Result::unwrap() aangeroepen op een Err-waarde

Andere systemen die afhankelijk zijn van onze proxy, werden getroffen tijdens het incident. Dit omvatte Workers KV en Cloudflare Access. Het team kon de impact op deze systemen om 13:04 uur beperken, toen er een patch werd gemaakt voor Workers KV om de kernproxy te omzeilen. Vervolgens werd bij alle downstream-systemen die afhankelijk zijn van Workers KV (zoals Access zelf) een lager foutenpercentage waargenomen. 

Het Cloudflare Dashboard werd ook beïnvloed doordat Workers KV intern werd gebruikt en Cloudflare Turnstile werd geïmplementeerd als onderdeel van onze inlogstroom.

Turnstile ondervond hinder van deze storing, waardoor klanten die geen actieve dashboardsessie hadden, niet konden inloggen. Dit was te zien aan een verminderde beschikbaarheid gedurende twee tijdsperioden: van 11:30 tot 13:10 uur en van 14:40 tot 15:30 uur, zoals te zien is in de onderstaande grafiek.

De eerste periode, van 11:30 tot 13:10, werd veroorzaakt door de impact op Workers KV, waarvan sommige controlepaneel- en dashboardfuncties afhankelijk zijn. Dit werd hersteld om 13:10, toen Workers KV het kernproxysysteem omzeilde. De tweede periode van impact op het dashboard vond plaats nadat de configuratiegegevens van de functie waren hersteld. De achterstand aan inlogpogingen resulteerde in een overbelasting van het dashboard. Deze achterstand, in combinatie met het aantal nieuwe pogingen, resulteerde in een verhoogde latentie, waardoor het dashboard minder beschikbaar werd. Door het schalen van de gelijktijdigheid van het besturingsvlak werd de beschikbaarheid rond 15:30 uur hersteld.

Nu onze systemen opnieuw online zijn en normaal werken, zijn we alvast begonnen met de voorbereidingen om deze beter te beschermen tegen dit soort storingen in de toekomst. Zo werken we in het bijzonder aan:

• Het beveiligen van de invoer van door Cloudflare gegenereerde configuratiebestanden op dezelfde manier als we dit doen voor door de gebruiker gegenereerde invoer

• Meer globale noodstopschakeaar voor functies invoeren

• Ervoor te zorgen dat kerndumps of andere foutrapporten de systeembronnen niet meer kunnen overbelasten

• Het beoordelen van de faalmodi voor foutcondities in alle kernproxymodules

Dit was de ergste storing bij Cloudflare sinds 2019. We hebben storingen gehad waardoor ons dashboard niet beschikbaar was. Sommige hebben ervoor gezorgd dat nieuwere functies gedurende een bepaalde periode niet beschikbaar waren. Maar in de afgelopen 6+ jaar hebben we geen enkele storing meer gehad waarbij het merendeel van het kernverkeer niet meer door ons netwerk kon stromen.

Een storing zoals vandaag is niet aanvaardbaar. Onze systemen zijn zo ontworpen dat ze bestand zijn tegen storingen om zeker te zijn dat het verkeer altijd doorstroomt. Storingen in het verleden hebben er altijd toe geleid dat we nieuwe, meer veerkrachtige systemen hebben gebouwd.

Namens het hele team van Cloudflare wil ik mijn excuses aanbieden voor de problemen die we vandaag op internet hebben veroorzaakt.