S3 1 To
S3 1 To
Connexion Premium
Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société
Déontologie Règles de modération Mentions légales et contact
Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS GitHub Discord

Derrière la récente panne Cloudflare, une mesure de protection contre la faille React

Derrière la récente panne Cloudflare, une mesure de protection contre la faille React

crédits : Unsplash

Deux semaines après une grande panne de plusieurs heures, Cloudflare a de nouveau rencontré un problème de configuration, aboutissant à une coupure de 25 min de ses services. La faute serait relative à un changement intervenu pour combattre l’exploitation de la faille dans React.

Cloudflare a connu une panne majeure le 5 décembre 2025 qui a duré environ 25 minutes, entre 09h47 et 10h12, heure française. L’incident a affecté environ 28 % du trafic HTTP total transitant par son réseau, provoquant des erreurs HTTP 500 pour les clients concernés.

Protection lourde

La faute à un bug logiciel déclenché lors du déploiement d’une protection contre la vulnérabilité CVE-2025-55182 affectant React Server Components. Pour contrer cette faille critique (score CVSS de 10/10), Cloudflare a en effet créé de nouvelles règles dans son WAF (Web Application Firewall) et augmenté la taille du buffer d’analyse des requêtes HTTP de 128 ko à 1 Mo pour protéger ses clients utilisant Next.js.

Durant le déploiement de cette augmentation, un outil interne de test a généré des erreurs. L’équipe a alors décidé de le désactiver via son système de configuration globale, qui propage rapidement (« en quelques secondes ») les changements sur l’ensemble du réseau.

Cette modification a exposé un bug latent dans le proxy FL1 (une ancienne version). Le code Lua contenait une erreur de type « nil pointer » lors du traitement des règles du WAF avec action « execute » lorsque celles-ci étaient désactivées via le killswitch. Seuls les clients utilisant le proxy FL1 avec le Cloudflare Managed Ruleset déployé ont été touchés. Ce type d’erreur n’aurait pas pu se produire avec FL2, le nouveau proxy écrit en Rust, affirme Cloudflare.

Cloudflare se concentre sur les correctifs

Cet incident survient seulement deux semaines après une autre panne majeure le 18 novembre 2025. Cloudflare reconnaît que les modifications de sécurité promises après cette première panne n’ont pas encore été complètement déployées.

L’entreprise s’engage à publier cette semaine un plan détaillé des projets de résilience en cours, incluant des diffusions progressives améliorées avec validation automatique de la santé des services, des capacités de rollback rapide et une logique « fail-open » pour éviter que les erreurs de configuration ne bloquent le trafic. En attendant, tous les changements sur leur réseau sont mis en pause.

Commentaires (17)

votre avatar
Franchement, une panne dans un système aussi complexe pour améliorer la sécurité face à une menace dangereuse très récente c'est okay pour moi.
Nombre de fois au boulot où j'entends, on va pas mettre à jour ça pourrait casser certains clients même si c'est une mise à jour de sécurité importante. Ca fait limite plaisir.
Enfin, je tiens pas non plus un site de e-commerce où 25min de panne signifie -200 000€ de ventes.
votre avatar
Je ne suis qu'à moitié d'accord.

Oui, il faut protéger tes clients contre les alertes de sécurité quand tu leur vends la fonction.
Cela comporte des risques et ils ont mis en place des mécanismes pour les détecter en faisant un déploiement progressif et désactiver une règle si besoin.
Mais ces mécanismes doivent être sans bugs, c'est-à-dire testés à 100 %. Le bug qui a tout fait planté était quand même un bug tout con d'un résultat inexistant parce que l'on n'a pas exécuté un bout de code. C'est même le genre de bug qui doit être détecté par un analyseur de code.

Le fait que l'action de désactiver la règle a été poussée immédiatement partout au lieu de l'être progressivement n'a pas aidé puisqu'elle a produit de gros dégâts immédiatement chez touts les clients concernés. Si elle avait été poussée progressivement, ils auraient vu le problème et serait revenus en arrière sur la modification initiale ce qui aurait produit bien moins de dégâts.
votre avatar
Je dirais que c'est un peu le pb des langages interprétés ou ce type d'erreur ne se voit qu'à l’exécution de la branche de code concernée. Tout juste si un check syntaxique basique est fait au chargement par l'interpréteur, loin du niveau de correction résultant d'un programme qui compile (surtout avec des options peu permissives) et qui est déjà loin d'être une validation que cela fait ce qu'on attends.

Ayant un gros background de C dans un contexte bas niveau, franchement, à chaque fois que je fais du Python même si j'en ai un usage limité/outils perso ou Bash serait à l'agonie et/ou peu lisible/maintenable, j'en arrive à repasser des "linter" comme on le faisait au début des années 90 en école d'ingé, quand la compilation du moindre exo de TD prenait qq minutes sur les stations d'époque... pour afficher les erreurs de base qu'un lint sortait en qq secondes!

Et si, en python, on a des outils comme ruff qui font un excellent boulot (et très vite comparé à d'autres outils plus anciens, qu'il fallait en prime pas mal configurer pour pas faire chier sur les règles de nommage que je trouve débile et que ce langage recommande, Guido ayant eu des fixettes un peu directivistes, certains raccourcis de traitement d'exception globaux et autre trucs qui dans mon cadre d'usage sont voulus)... Eh bien, pour faire un peu de Lua à titre perso (c'est le langage nativement intégré à Domoticz qui gère ma baraque), je l'ai pas trouvé grand chose dépassant luacheck qui fait globalement le job mais laisserait passer le gag Cloudflare.

Pour les pythonistes qui connaissent pas ruff, l'essayer c'est l'adopter!
https://docs.astral.sh/ruff/
votre avatar
Le problème des langages de script et un peu trop dynamique sur le typage, c'est que cela amène un tas de programmeurs du dimanche. Mais bon le marché a besoin de tocards pour faire pression sur les prix. C'est un choix : 'Sécure ou pas cher'...
votre avatar
Ce n'est pas qu'un pb de typage qui facilite la vie (au point de ne plus forcément avoir conscience de ce qu'on manipule), mais que des gags énormes peuvent rester invisibles dans des branches presque jamais utilisées (les cas d'erreur typiquement), jusqu'à ce qu'on y passe, car les interpréteurs ne regardent globalement pas trop ce qu'on leur donne à manger (sans doute pour ne pas ajouter trop de latence au chargement des scripts).
votre avatar
Je confirme les "programmeurs du dimanche".
Et le top du top, c'est les langages qui gèrent le typage stricte mais qui laisse la possibilité au développeur de désactiver ça. Le code n'est plus vérifié à la compilation mais au moment de l'exécution.

Ah VB.Net et ses options Strict / Explicit désactivés ...
votre avatar
However, we have never before applied a killswitch to a rule with an action of “execute”
Mais ils n'ont jamais testé le code non plus.
Un test de couverture de code aurait montré le problème avant qu'il ne se produise en production !

Le bug était quand même assez basique.
votre avatar
La prod est la meilleure des recettes.
votre avatar
Bref, chez Cloudflare, ça déploie en prod un peu à la va-vite... C'est bien de savoir déployer en quelques secondes ; mais c'est mieux si on teste un peu avant de déployer.
votre avatar
Tester c'est douter !
votre avatar
Pourtant, une mise en prod un vendredi... :non:
https://www.estcequonmetenprodaujourdhui.info/
votre avatar
En même temps, un système planté est un système qui n'est pas sujet à la faille en question ! CQFD

Et je suis déjà parti très très loin
votre avatar
L'éternel problème du manque de standardisation. On laisse tellement de possibilités que même en faisant des tests il y aura un cas tordu en prod qui ne marchera pas auquel personne n'aurait pu pensé.
votre avatar
Standardisation de quoi ?
votre avatar
Paramétrage, matériel etc...
Les admins testent sur leurs cas à eux, si ailleurs c'est pas le même paramétrage, le même matériel ça pose vite des problèmes, ils ne peuvent pas deviner les tous les cas utilisés.
Il faut donc standardiser pour éviter cela. Pour que tout soit testable il faut limiter les cas en imposant des standards.
votre avatar
C'est plutôt le contraire. Tu veux tester tous les cas ? Exit les standards, tu contrôles tout et c'est bon (philosophie d'Apple, qui verrouille complètement son matériel).

Si tu respectes des standards (pour la conception de machine j'entends) et c'est vite la merde car justement, tu ne peux pas tout tester (cf. Microsoft).

Imposer un standard fera que tu auras une multiplication des cas d'usage, ce qui va aller à l'encontre du but que tu recherches justement via un testing exhaustif.
votre avatar
Je ne vois pas le rapport entre ce que tu dis et le problème de Cloudflare décrit ici.

Ce problème à la base est dans un logiciel développé chez eux. Ils n'ont pas fait de tests dans le cas d'une valeur parmi 4 valeurs possibles de leurs "actions".

C'est le B.A BA du test unitaire de tester pour les 4 valeurs et de se rendre compte lors du test qu'il y a un problème pour la valeur execute si l'on veut activer le kill switch de leur firewall applicatif avec cette valeur execute.

Ce n'est pas en prod que l'on doit se rendre compte de ce genre de problème. C'est un problème laissé par un développeur.

Il n'y a aucune standardisation à attendre dans un logiciel propriétaire développé pour offrir un service très spécifique de protection aux clients de Cloudflare.