Cloudflare-storing op 5 december 2025

Op 5 december 2025 om 8:47 uur UTC (alle tijden in deze blog zijn UTC) ontstonden er ernstige storingen in een deel van het Cloudflare-netwerk. Het incident was om 9:12 uur verholpen (totale impact: ongeveer 25 minuten), toen alle diensten volledig waren hersteld.

Een deel van onze klanten werd door deze storing geraakt, goed voor ongeveer 28% van al het HTTP-verkeer dat door Cloudflare werd verwerkt. Zoals hieronder staat uitgelegd, moest er sprake zijn van een combinatie van verschillende factoren voordat individuele klanten last kregen van deze storing.

Het probleem werd niet direct of indirect veroorzaakt door een cyberaanval op de systemen van Cloudflare of door kwaadwillige activiteiten van welke aard dan ook. De storing was echter het gevolg van wijzigingen die we aan onze body-parsinglogica hebben aangebracht toen we bezig waren om een sectorbrede kwetsbaarheid die deze week in React Server Components werd bekendgemaakt, te detecteren en te beperken.

Elke storing van onze systemen is onacceptabel en we weten dat we het internet opnieuw in de steek hebben gelaten na het incident van 18 november. Volgende week publiceren we meer informatie over de maatregelen die we momenteel treffen om dit soort incidenten te voorkomen.

De onderstaande grafiek toont de HTTP 500-fouten die tijdens het incident door ons netwerk werden geserveerd (rode lijn onderaan) vergeleken met het totale Cloudflare-verkeer dat geen last van de storing had (groene lijn bovenaan).

De Web Application Firewall (WAF) van Cloudflare biedt klanten bescherming tegen schadelijke payloads, waardoor die gedetecteerd en geblokkeerd kunnen worden. Hiervoor buffert de proxy van Cloudflare de inhoud van het HTTP-verzoek in het geheugen voor analysedoeleinden. Vóór vandaag was de buffergrootte ingesteld op 128 KB.

Als onderdeel van ons voortdurende werk om klanten die React gebruiken tegen de kritieke kwetsbaarheid CVE-2025-55182 te beschermen, zijn we begonnen met het vergroten van de buffer naar 1 MB, de standaardlimiet die door Next.js-applicaties wordt geaccepteerd. Hiermee willen we zoveel mogelijk klanten beschermen.

Deze eerste wijziging werd geleidelijk uitgerold. Tijdens de uitrol merkten we dat onze interne WAF-testtool de grotere buffergrootte niet ondersteunde. Aangezien deze interne testtool op dat moment niet nodig was en geen effect had op het klantverkeer, hebben we een tweede wijziging doorgevoerd om de tool uit te schakelen.

Deze tweede wijziging, waarbij we onze WAF-testtool uitschakelden, werd toegepast via ons wereldwijde configuratiesysteem. Dit systeem voert geen geleidelijke uitrol uit, maar zorgt binnen enkele seconden voor de toepassing van de wijzigingen in het gehele netwerk. Dit systeem wordt momenteel geëvalueerd na de storing die we onlangs op 18 november hebben ondervonden. 

Helaas heeft de tweede wijziging in onze FL1-versie van onze proxy, waarbij we onze WAF-regeltesttool uitschakelden, onder bepaalde omstandigheden een foutstatus veroorzaakt die resulteerde in 500 HTTP-foutcodes die vanuit ons netwerk werden verzonden.

Zodra de wijziging zich door ons netwerk verspreidde, stuitte de code-uitvoering in onze FL1-proxy op een bug in onze regelmodule, wat de volgende Lua-foutmelding veroorzaakte:

[lua] Failed to run module rulesets callback late_routing: /usr/local/nginx-fl/lua/modules/init.lua:314: attempt to index field 'execute' (a nil value)

en dit was de reden voor de veroorzaakte HTTP 500-fouten.

Het probleem werd kort na de toepassing van de wijziging vastgesteld en om 9:12 uur teruggedraaid, waarna al het verkeer weer probleemloos werd verwerkt.

Klanten met webassets die via onze oudere FL1-proxy werden bediend én de Cloudflare Managed Ruleset gebruikten, werden door deze storing getroffen. Bij al het HTTP-verkeer voor websites in deze status werd een HTTP 500-fout teruggezonden, met enkele kleine uitzonderingen voor testeindpunten zoals /cdn-cgi/trace.

Klanten zonder de bovenstaande configuratie ondervonden geen last van de storing. Ook het klantenverkeer dat via ons China network verliep had hier geen last van.

Het regelssysteem van Cloudflare bestaat uit een verzameling regels die elke aanvraag naar ons systeem beoordeelt. Een regel bestaat uit een filter dat specifiek verkeer selecteert en een actie die een effect op dat verkeer heeft. Voorbeelden van deze acties zijn 'blokkeren', 'loggen' of 'overslaan'. Een ander soort actie is 'uitvoeren', en die wordt gebruikt om de beoordeling van een andere regelset te activeren.

Ons interne logsysteem gebruikt deze functie om nieuwe regels te beoordelen voordat die openbaar gemaakt worden. Een regelset op het hoogste niveau voert een andere regelset uit die testregels bevat. Wij wilden juist deze testregels uitschakelen.

We beschikken over een killswitch-subsysteem als onderdeel van het regelsetsysteem, waarmee we alle regels die zich misdragen snel kunnen uitschakelen. Dit killswitch-systeem ontvangt informatie van ons wereldwijde configuratiesysteem dat hierboven werd genoemd. We hebben dit killswitch-systeem in het verleden al een aantal keer gebruikt om incidenten te beperken en hebben een duidelijk gedefinieerde werkprocedure, die ook bij dit incident werd toegepast.

We hebben echter nooit eerder een killswitch gebruikt voor een regel met de actie 'uitvoeren'. Toen de killswitch werd geactiveerd, sloeg de code inderdaad de beoordeling van de actie 'uitvoeren' over, waardoor de subregelset waarnaar de killswitch verwees dus niet werd geëvalueerd. Er is echter een fout opgetreden tijdens de verwerking van de algehele resultaten van de beoordeling van de regelset:

if rule_result.action == "execute" then
  rule_result.execute.results = ruleset_results[tonumber(rule_result.execute.results_index)]
end

Deze code verwacht dat, als de regelset de action='execute' bevat, het 'rule_result.execute'- object bestaat. Aangezien de regel echter was overgeslagen, bestond het 'rule_result.execute'-object niet en retourneerde Lua een foutmelding, omdat er een waarde in een nil-waarde werd gezocht.

Het gaat hier om een eenvoudige fout in de code, die al jarenlang onopgemerkt was. Dit soort codefouten wordt voorkomen door een taal met een sterk typesysteem te gebruiken. Na de vervanging van deze code in onze nieuwe FL2-proxy, die in Rust is geschreven, trad de fout niet langer op.

Twee weken geleden, op 18 november 2025, hebben we een andere wijziging doorgevoerd die een soortgelijk, langer durend incident veroorzaakte. In beide gevallen werd de oplossing voor een algemeen beveiligingsprobleem door het gehele netwerk verspreid, wat leidde tot fouten bij vrijwel al onze klanten.

Na dit incident hebben we rechtstreeks met honderden klanten gesproken en onze plannen voor het doorvoeren van wijzigingen met hen gedeeld om te voorkomen dat individuele updates voortaan zulke grote gevolgen kunnen hebben. Wij zijn ervan overtuigd dat deze wijzigingen het incident van vandaag hadden kunnen voorkomen, maar helaas is de implementatie daarvan nog niet helemaal afgerond.

Wij weten dat dat teleurstellend is. Het is en blijft onze prioriteit binnen de gehele organisatie. Met name de onderstaande projecten zullen de impact van dergelijke veranderingen beperken:

• Verbeterde uitrol en versiebeheer: op dezelfde manier waarop we de software langzaam en met strikte gezondheidsvalidatie uitrollen, moet de data die gebruikt wordt voor een snelle dreigingsrespons en algemene configuraties dezelfde impact beperkende en veiligheidsfuncties hebben. Dit omvat onder andere een gezondheidsvalidatie en snelle terugdraaifuncties.

• Gestroomlijnde noodprocedures: om ervoor te zorgen dat essentiële werkzaamheden nog steeds kunnen worden uitgevoerd ook als zich bijkomende storingen voordoen. Dit geldt voor de interne services en voor alle standaard interactiemethoden met het Cloudflare-controlepaneel die door alle Cloudflare-klanten worden gebruikt.

• Afhandeling van 'Fail-Open'-fouten: als onderdeel van onze inspanningen om de veerkracht te vergroten, vervangen we de onjuist toegepaste hard-fail-logica in alle kritieke Cloudflare-dataplane-componenten. Als een configuratiebestand beschadigd of buiten bereik is (bijv. als de functielimieten worden overschreden), registreert het systeem de fout en wordt standaard een bekende goede status gebruikt of wordt het verkeer zonder beoordeling doorgelaten, in plaats van HTTP-verkeer te weigeren. Sommige diensten bieden de klant waarschijnlijk de optie voor 'fail open' of 'fail closed' in bepaalde scenario's. Dit omvat functies voor driftpreventie om te waarborgen dat dit continu wordt toegepast.

Tegen eind volgende week zullen we een uitgebreid overzicht van alle lopende resilience-projecten publiceren, inclusief de bovenstaande. Terwijl deze werkzaamheden worden uitgevoerd, vergrendelen we alle wijzigingen van ons netwerk om ervoor te zorgen dat we betere systemen hebben om problemen te beperken en handelingen terug te draaien voordat we opnieuw beginnen.

Dergelijke incidenten, en de snelheid waarmee ze op elkaar volgen, zijn voor een netwerk als het onze onacceptabel. Namens het hele Cloudflare-team willen we onze excuses aanbieden voor de impact en de pijn die deze storing opnieuw heeft veroorzaakt bij onze klanten en op het internet in het algemeen.