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