Cloudflare wijt storing aan maatregelen tegen Kritieke kwetsbaarheid React

De storing bij Cloudflare vrijdag werd veroorzaakt door noodmaatregelen tegen de Kritieke kwetsbaarheid in React, meldt het cloudbedrijf zelf. Door de storing functioneerde het netwerk van Cloudflare 25 minuten niet stabiel.

Volgens Cloudflare ondervond een deel van het netwerk vrijdag vanaf 9.47 uur 'aanzienlijke storingen'. Om 10.12 uur was de storing volgens het bedrijf weer verholpen. In totaal is ongeveer 28 procent van het HTTP-verkeer dat door Cloudflare wordt verwerkt getroffen. De verstoring was volgens cto Dane Knecht niet het gevolg van een cyberaanval, maar van noodmaatregelen tegen de Kritieke kwetsbaarheid in React Server Components, die eerder deze week werd bekendgemaakt.

Cloudflare besloot de standaardbuffergrootte van zijn firewall voor webservers te verhogen van 128KB naar 1MB. Dit is de standaardlimiet die Next.js-applicaties toestaat. Deze maatregel werd geleidelijk doorgevoerd. Tijdens de uitrol merkte Cloudflare dat zijn interne testtool voor deze firewalls de grotere buffergrootte niet ondersteunde. Daarom besloot het team deze tool uit te schakelen.

Deze uitschakeling gebeurde via het global configuration system van Cloudflare. Dit systeem introduceert veranderingen niet geleidelijk, maar voert ze meteen wereldwijd door. Het uitschakelen van de tool veroorzaakte een bug in de code-uitvoering in de FL1-proxy van Cloudflare. Deze bug resulteerde in HTTP 500-fouten bij klanten wiens webassets door de FL1-proxy worden beheerd en de Cloudflare Managed Ruleset hebben geïmplementeerd.

De bug werd veroorzaakt door een programmeerfout in het regelsysteem van Cloudflare, specifiek hoe het systeem omgaat met de actie execute als het bedrijf een killswitch toepast. Het systeem sloeg de evaluatie van de executeactie terecht over, maar de code verwacht dat het object rule_result.execute bestaat als een dergelijke actie wordt uitgevoerd. Deze bestond echter niet, omdat de executeactie was overgeslagen. Daardoor gaf Lua een foutmelding.

"Dit is een simpele fout in de code, die jarenlang onopgemerkt was gebleven", schrijft Knecht. "Dit type codefout wordt voorkomen door talen met sterke typesystemen. In onze vervanging voor deze code in onze nieuwe FL2-proxy, geschreven in Rust, trad de fout niet op."

Het aantal succesvolle HTTP-verzoeken (Groen) en afgewezen verzoeken (rood) tijdens de storing

Reacties (17)

[Olaf van der Spek]

Cloudflare besloot de standaardbuffergrootte van zijn firewall voor webservers te verhogen van 128KB naar 1MB.

Waarom was een grotere buffer nodig?

[Stetsed]

Omdat normaal scant de WAF niet alles, want dit gebruikt te veel processing capaciteit. Hiervoor heb je dus een body limit waar in wordt gezegt dat als de body groter is dan dat dan wordt hij doorgestuurd anders niet, dit is vaak niet een probleem omdat veel kwetsbaarheden in de header zitten. Maar in deze situtatie blijkbaar niet waardoor ze hem moesten vergroten. Iets soort gelijk heb je bijna altijd ook in de WAF die je draait met traefik/nginx/enz dat je een soort gelijk limiet instelt.

[Stukfruit]

Eigenlijk ook wel weer mooi om te zien dat zelfs Cloudflare zelf over hun eigen limieten valt.

* Stukfruit is er al vaker dan één keer over gevallen en kon daarom een kleine grinnik niet onderdrukken

[Zenomyscus]

Tijdens de uitrol merkte Cloudflare dat zijn interne testtool voor deze firewalls de grotere buffergrootte niet ondersteunde. Daarom besloot het team deze tool uit te schakelen.

Tja. Meer dan 'tja' kan ik er eigenlijk niet over zeggen. Dit behoeft verder geen uitleg, want iedere serieuze ontwikkelaar weet dat dit vragen om problemen is en nogal dom is. Zorg dat al je tooling werkt voordat je een uitrol doet en wijk niet af van het protocol. Dat is er niet voor niets.

[Bedge85]

De aanpassing moest onder tijdsdruk worden doorgevoerd in verband met een kritieke kwetsbaarheid React. Het systeem van ClouFlare is zo groot en complex dat niet alle risico's afgedekt kunnen worden voor het uitrollen van een aanpassing.

[Reactie gewijzigd door Bedge85 op 6 december 2025 09:57]

[--MeAngry--]

Dit, een kritieke kwetsbaarheid brengt nog veel grotere risico’s met zich mee dan 25 minuten downtime. Dat maakt het niet minder vervelend, maar wel dat de prioriteiten goed op orde zijn.

[Sandor_Clegane]

Dit maakt het niet beter. Waarom zijn ze zo belangrijk voor het internet als ze het zelf niet snappen?

[Blokker_1999]

Je moet hier een keuze maken. Je bent vatbaar voor een RCE welke mogelijks heel je infra en heel je bedrijf in gevaar brengt. Dan is het niet zo eenvoudig als zeggen dat je er maar even enkele weken development werk tegenaan gaat gooien om het op te lossen en dat je ondertussen gewoon kwetsbaar gaat blijven.

En dat de testtool er niet mee overweg kan lijkt me nog niet eens de root cause te zijn dat je een resultaat verwacht dat niet altijd bestaat ergens anders in de lijn. Dat dat nooit is opgemerkt kan gebeuren, maar dan moet je QA team misschien ook eens nakijken welke test cases zij mogelijks nog over het hoofd zien. Een belangrijke optie in je software stack hebben, maar die nooit uittesten lijkt hier een belangrijke fout te zijn geweest, en in geval van nood moet je dus on-the-fly schakelen.

[Arrigi]

Goeie. Hoe kán het dat de bug in React door alle testing is geraakt? Zorg eerst voor correcte testing voor je mogelijk dergelijk kwetsbare code publiceert.

Toch?

[Barsonax]

He het was dus niet dns?

[Technoid]

Jawel, juist wel.

Als je die had geconfigureerd naar je webserver rechtstreeks ipv naar cloudflare had je nergens last van

[latka]

Dus een probleem door weak typing in lua om een probleem in een weakly typed ecosysteem van react/javascript te beperken. Ik zie een patroon.

[armageddon_2k1]

Weak typing had niks te maken met de CVE van React

[naaitsab]

Van achter de PC altijd makkelijk praten maar is dit niet erg knullig uitgevoerd? Lijkt me dat je na een test een gefaseerde 'rolling update' doorvoert en niet de helft van je dienstverlening op zwart gooit. Waarbij de communicatie ook nog eens belabberd was. En ja dit is nog altijd beter dan niks doen, dat moge duidelijk zijn, dit lek is niet zo maar een bugje.

Geeft maar weer eens aan hoe kwetsbaar het internet anno 2025 eigenlijk is. Bedrijven als Cloudflare hebben veel te veel marktaandeel wat het voor de alternatieven lastig maakt. Wat de stabiliteit niet ten goede komt.

[GertMenkel]

Het duurde wel een paar minuten tot de storing op de website stond, maar zo erg vond ik het ook weer niet verlopen. Al met al een half uurtje problemen vind ik zo erg nog niet, dat kan je ala gebruiker ook overkomen als iemand in je netwerk ene scraper draait en je IP tijdelijk op de gevaarlijst wordt gezet.

Dit is niets vergeleken met de vorige storing die lang duurde en maar weinig duidelijkheid bood. Ik geloof niet dat ze met deze storing enige SLA's hebben doorbroken.

[Reactie gewijzigd door GertMenkel op 6 december 2025 11:08]

[jcvw]

Dit toont maar weer eens aan dat voor grote systemen rollouts altijd gradual moeten zijn, met automatische monitoring en rollback. Rol de wijziging uit naar 0.1%, van je systemen, laat dit "inweken" en verifieer dat die nieuwe populatie blijft werken ("canarying"). Dan ga je naar 1% uiteraard weer met canarying, dan 10% en dan pas 100% van de populatie. En een rollout is niet alleen maar het uitrollen van nieuwe software, maar dus ook voor configs.

En ja, dit moet je ook doen bij dingen die "echt nu meteen" moeten, bijvoorbeeld om een outage te mitigeren. Alleen meet je dan de "inweektijd" niet in uren maar in minuten.

Zie ook https://sre.google/sre-book/reliable-product-launches/

[armageddon_2k1]

Beste stuurlui staan aan wel zoals gewoonlijk