Incident partiel du réseau Cloudflare du 5 décembre 2025

• À 08:47 UTC le 5 décembre 2025, une partie du réseau Cloudflare a subi une panne majeure et la restauration complète est intervenue à 09:12, soit environ 25 minutes plus tard
• Environ 28 % de l’ensemble du trafic HTTP a été impacté, et seul un sous-ensemble de clients répondant à certains critères a été touché
• La cause était une modification du WAF (logique d’analyse du corps de requête) liée au correctif de la vulnérabilité React Server Components (CVE-2025-55182), sans rapport avec une attaque ou une action malveillante
• Une erreur de code du proxy FL1 a généré des erreurs HTTP 500, et cette erreur n’a pas été observée sur le nouveau proxy FL2 basé sur Rust
• Cloudflare reconnaît qu’un problème similaire s’est reproduit depuis l’incident du 18 novembre et met désormais en priorité un projet visant à améliorer la sécurité des déploiements et la résilience

---

Aperçu de l’incident

• Le 5 décembre 2025 à 08:47 UTC, une panne est survenue sur une partie du réseau Cloudflare
  • La récupération complète a eu lieu à 09:12, avec un impact total de 25 minutes
  • Environ 28 % du trafic HTTP global ont été impactés
• L’incident n’était pas lié à une cyberattaque ni à une action malveillante, mais est survenu pendant un changement interne de configuration
• La cause était une modification de la logique de parsing du corps du WAF pour traiter la vulnérabilité de React Server Components

Cause de l’incident et contexte technique

• Le WAF Cloudflare met en mémoire tampon le corps des requêtes HTTP pour détecter les payloads malveillants
  • La taille du tampon est passée de 128 Ko à 1 Mo en cours de déploiement
• Les outils de test internes ne prenaient pas en charge la nouvelle taille de tampon, ce qui a conduit à une deuxième modification désactivant les outils de test
  • Cette modification a été propagée immédiatement à l’ensemble des serveurs via le système de configuration globale
• Sur le proxy FL1, ce changement a provoqué un état d’erreur, générant des réponses HTTP 500
  • Message d’erreur : attempt to index field 'execute' (a nil value)
• Le problème a été identifié immédiatement et la modification a été revertie à 09:12

Portée de l’impact

• Seuls les clients utilisant le proxy FL1 et appliquant le Cloudflare Managed Ruleset ont été impactés
  • Pour les sites concernés, toutes les requêtes ont renvoyé une erreur HTTP 500
  • Certaines exceptions ont existé, comme le endpoint de test /cdn-cgi/trace
• Le réseau chinois et les clients avec d’autres configurations n’ont pas été impactés

Détails de l’erreur d’exécution

• Le système rulesets de Cloudflare évalue les règles à chaque requête
  • Les règles sont composées de filtres et d’actions, et l’action execute appelle un autre ruleset
• Le système de journalisation interne utilisait execute pour évaluer des règles de test
• Le système de killswitch est conçu pour désactiver automatiquement les règles dysfonctionnelles, mais
  • c’est la première fois qu’un killswitch a été appliqué à une règle contenant l’action execute
• L’erreur de Lua est apparue en tentant d’accéder à l’objet execute lorsqu’il n’existait pas
• Cette erreur était un simple bug de code présent depuis plusieurs années non détecté
  • En Rust, le proxy FL2 n’a pas rencontré cette erreur

État des améliorations après l’incident du 18 novembre

• Le 18 novembre, un incident similaire de déploiement global ayant provoqué une panne étendue s’était déjà produit
• À l’époque, Cloudflare a communiqué directement avec des centaines de clients et partagé un plan pour éviter une propagation massive d’une seule mise à jour
• Ce travail d’amélioration n’était pas encore terminé et a contribué à l’incident actuel
• Cloudflare en a fait une priorité absolue de l’entreprise

Projets en cours de renforcement de la résilience

• Enhanced Rollouts & Versioning
  • Appliquer un déploiement progressif, une validation de santé et des rollbacks rapides aux changements de données et de configuration liés à la réponse aux menaces
• Streamlined Break Glass Capabilities
  • Permettre des opérations d’urgence même lors des interactions avec les services internes et le control plane
• Gestion des erreurs Fail-Open
  • En cas d’erreur de fichier de configuration, ne pas bloquer les requêtes, mais revenir à un état opérationnel sain ou laisser passer le trafic
  • Une option fail-open/fail-closed est prévue pour certains services
• Les détails de tous les projets de résilience seront publiés d’ici la semaine prochaine
• Jusqu’à alors, les changements réseau restent gelés en mode lockdown

Chronologie (UTC)

• 08:47 – Déploiement du changement de configuration et début de propagation réseau
• 08:48 – Impact global
• 08:50 – Déclaration d’incident suite à alertes automatiques
• 09:11 – Début du rollback du changement
• 09:12 – Récupération complète, trafic totalement normalisé

Conclusion

• Cloudflare reconnaît la gravité des deux incidents consécutifs et présente ses excuses aux clients et à l’ensemble de l’écosystème Internet
• L’entreprise prévoit de prévenir de nouveaux incidents par un renforcement de la sécurité des déploiements, de la tolérance aux erreurs et de la résilience

[GN⁺]

Réactions sur Hacker News

• Cette panne de Cloudflare n’a pas simplement révélé un bug Lua, mais un problème d’architecture plus profond.
  La structure web distribuée d’origine était bien plus résistante à ce type de panne globale. À l’inverse, un système centralisé homogène comme Cloudflare peut arrêter des services du monde entier d’un seul faux pas. Même écrit en Rust, un système reste exposé à l’erreur humaine. Au final, c’est la solidité de la conception qui compte.

  • En clair, plus on dépend de géants comme Cloudflare ou AWS, plus la stabilité du web diminue.
  • Comme dans l’analogie « 1 000 frelons contre 1 chien », qu’il s’agisse d’une panne globale ou locale, seule la forme de la douleur change. Quand Cloudflare tombe, des centaines d’ingénieurs réagissent immédiatement ; quand mon serveur tombe, la personne en charge est peut-être dans un chalet au fond des bois.
  • Sans même entrer dans le débat sur les monopoles, si on regarde le taux de disponibilité de Cloudflare sur le long terme, c’est sans doute meilleur que l’infrastructure opérée directement par chaque site. Du point de vue de l’utilisateur, il vaudrait mieux que tous les services tombent ensemble pendant une heure, plutôt que chacun tombe séparément pendant une heure à des moments différents. Mais si la fiabilité de Cloudflare passe sous la moyenne, cet avantage disparaît.
  • À une échelle de 80 millions de requêtes par seconde, le vrai problème est peut-être qu’un seul produit puisse atteindre une telle taille.
  • Cloudflare reste l’une des entreprises les plus rapides au monde pour restaurer une infrastructure globale. Cette fois encore, ils ont résolu une panne affectant 28 % du réseau en 25 minutes, avec objectivement moins d’indisponibilité que d’autres clouds.

• J’ai vu hier soir des erreurs 500 de Cloudflare sur plusieurs sites. Pourtant, la page de statut n’en disait rien et n’affichait qu’un avis de maintenance planifiée.

  • Comme pour la plupart des pages de statut, il faut du temps avant qu’un problème réel soit reconnu puis affiché. Tant que tout n’est pas entièrement automatisé, Cloudflare ne fera pas exception. Ce qui inquiète davantage, c’est la série récente de pannes chez AWS, Azure et Cloudflare. Mon intuition est qu’il s’agit d’un mélange de montée en charge liée aux LLM, de sous-effectif, d’effets post-pandémie et d’instabilité politique.
  • Ce type de problème avec les pages de statut ne s’améliorera probablement qu’à travers une critique publique. Il faut davantage de retours du type « Cloudflare n’arrive même pas à détecter correctement ses propres incidents ».

• On dirait que l’ingénierie qualité de Cloudflare n’arrive pas à suivre le rythme de production. Dans l’industrie de la défense, on disait autrefois que les équipes qualité étaient toujours les plus expérimentées ; dans le logiciel, on dirait l’inverse.

  • Cela rappelle cette anecdote où, même dans la défense, une fuite mémoire avait été connue puis ignorée au motif que « sur la durée d’utilisation prévue, il n’y a pas de problème ».
  • Quand cela arrive deux fois dans le même mois, ce n’est pas « à saluer ». À ce stade, la répétition n’a plus d’excuse.

• La structure en commutation de paquets de l’internet a justement été conçue pour résister à ce genre de panne globale.
  À l’époque de la guerre froide, le réseau de la DARPA visait à maintenir la chaîne de commandement même en cas d’attaque nucléaire.
  C’est peut-être le moment de revenir à un paradigme internet local-first.

  • Référence : The Real Internet Architecture
  • Référence : Local-first software

• J’ai l’impression qu’en ce moment Cloudflare rend internet plus lent et pénible. Les procédures du type « prouvez que vous êtes humain » se multiplient, et le chargement des pages prend plus de temps.
  Cela semble davantage lié à une politique de facturation du crawling IA qu’à la protection des sites (présentation de Pay-per-crawl).

  • Ces procédures de vérification humaine ne sont pas compatibles avec les anciens navigateurs, ce qui rend certains sites totalement inaccessibles.
  • Mais le scraping non autorisé de contenus par les IA pose aussi problème. Cloudflare offre donc aux propriétaires de sites une option de protection du contenu, qu’ils peuvent désactiver s’ils ne la veulent pas.
  • Certains lâchent aussi, avec cynisme : « maintenant, ils ne peuvent même plus nous surveiller discrètement ».

• Le système de configuration globale de Cloudflare est risqué s’il diffuse un changement à l’ensemble du réseau en quelques secondes, sans déploiement progressif.
  Il faut un mécanisme capable d’identifier immédiatement la corrélation lorsqu’un changement de configuration provoque une erreur.

  • Le vrai problème, c’est que l’alerte est arrivée trop tard. Elle est tombée au bout de 2 minutes, alors qu’il aurait fallu une détection en quelques secondes.
    La personne en charge du déploiement aurait dû surveiller les métriques en temps réel et appuyer immédiatement sur le bouton de rollback.
    Les logs pointaient même clairement jusqu’à la ligne de code, mais il semble y avoir eu une rupture entre l’équipe de déploiement et celle qui comprenait réellement le code.
  • Ils ont vu les signaux d’alerte et ont tenté un rollback, mais il semble que cette procédure ait elle-même causé des problèmes.
  • Les outils internes génèrent souvent beaucoup de faux positifs et il arrive aussi qu’ils soient eux-mêmes défaillants.
  • Cela fait penser à la blague : « le voyant moteur restait allumé, alors j’ai juste retiré l’ampoule ».

• Le taux de disponibilité de Cloudflare est tombé sous les 99,9 %. C’est pire que mon PC à la maison.

  • Même chose pour AWS. Si la raison d’être du cloud, c’est une « disponibilité supérieure », alors si c’est cher et instable, il y a de vraies raisons d’héberger soi-même.
  • Mais en auto-hébergement, quand le matériel tombe en panne ou qu’une sauvegarde échoue, la restauration peut prendre plusieurs jours.
  • Dans les régions où les coupures d’électricité sont fréquentes, il est difficile de tenir uniquement avec un laptop et une batterie. On en vient parfois à rêver d’une infrastructure autosuffisante.
  • Je me demande où l’on peut consulter les statistiques exactes d’uptime de Cloudflare.
  • Cela dit, comparer simplement un PC personnel à Cloudflare est une analogie sans grand sens.

• À l’échelle de Cloudflare, il faut absolument disposer d’un environnement de test.
  Tout changement devrait être simulé dans un environnement modèle isolé avant d’être déployé progressivement.
  Les garde-fous procéduraux comptent davantage qu’un système de types fort.

  • Dans notre entreprise, on utilise un déploiement en trois étapes : développement → intégration interne → production.
    Les équipes sujettes aux erreurs avancent plus lentement, et celles qui sont fiables vont plus vite.
    Au fond, la vitesse technique est un choix. Si les SLA sont menacés, il faut ralentir et renforcer les tests.
  • On pourrait aussi utiliser les utilisateurs gratuits comme banc d’essai et réserver aux clients payants les versions les plus stables.
  • Dire que « le système de types fort ne vous sauvera pas » signifie qu’en cas d’échec procédural, le langage lui-même est impuissant.

• La qualité logicielle de Cloudflare semble vaciller.
  Il y a même eu un bug où la vérification d’accès à une fonctionnalité réservée aux entreprises n’était effectuée qu’à la toute dernière étape.

  • J’ai moi-même rencontré dans l’API Cloudflare un paramètre impossible à annuler.
    Il fallait passer par le support pour le modifier, et la correction a pris plusieurs jours.
    Lien vers un cas connexe
  • Certains pensent que ce genre de bug pourrait venir de code écrit par une IA.
  • J’aimerais comprendre plus précisément ce que signifie « vérifier uniquement à la dernière étape ».

• Je suis curieux de la culture opérationnelle chez Cloudflare.
  Lors d’une réponse à un incident de sécurité, une erreur s’est produite, et au lieu d’un rollback ils ont procédé à un nouveau déploiement global ; c’est une décision risquée.
  Cela va à l’encontre du principe de base : « en cas de doute, rollback ».

  • Cela dit, il s’agissait cette fois d’une réponse urgente à une vulnérabilité RCE de React Server.
    Retarder le déploiement aurait pu exposer des clients à un piratage réel ; dans ce cas, la vitesse fait partie de la sécurité.
  • Le rollback n’est pas toujours la bonne réponse. Si la procédure n’est pas maîtrisée, elle devient elle-même un risque.
  • En réalité, les deux déploiements concernaient des composants différents.
    Le premier correctif a révélé un bug latent dans le second, donc dans certains cas un roll forward est plus réaliste qu’un rollback.
  • Cloudflare a probablement accumulé de la dette technique au fil de sa croissance rapide.
    La multiplication récente des pannes est peut-être le signe que cette dette commence à remonter à la surface.