Une panne massive de Cloudflare a été déclenchée par une erreur de configuration qui a fait doubler la taille d'un fichier important

Entrainant des perturbations sur de nombreux sites et services en ligne

Une panne massive de Cloudflare a été déclenchée par une erreur de configuration qui a fait doubler la taille d'un fichier important,
entrainant des perturbations sur de nombreux sites et services en ligne

L’Internet moderne repose sur des couches d’abstraction si nombreuses qu’on finit parfois par oublier la nature profondément fragile de l’édifice. La panne récente qui a frappé Cloudflare en est la démonstration brutale. Un fichier interne, dédié à la gestion des bots, a soudainement doublé de taille et déclenché une réaction en chaîne qui a perturbé une part importante du trafic mondial.

Pour les experts de l’infrastructure et de la cybersécurité, cet incident offre une leçon essentielle : dans un écosystème numérique hyper-centralisé, la plus petite erreur de configuration peut devenir l’origine d’un séisme global.

Lorsque Cloudflare a connu la panne qui a perturbé un grand nombre de sites Web et de services en ligne, l'entreprise a d'abord pensé qu'elle était victime d'une attaque DDoS (déni de service distribué) « à très grande échelle ».

« Je crains que ce soit le botnet qui se montre », a écrit Matthew Prince, cofondateur et PDG de Cloudflare, dans un forum de discussion interne, alors que lui et d'autres discutaient pour savoir si Cloudflare était victime d'attaques du prolifique botnet Aisuru.

À ce sujet, Microsoft a expliqué que le botnet a créé « la plus grande attaque DDoS jamais observée dans le cloud » :

« Le 24 octobre 2025, Azure DDOS Protection a automatiquement détecté et atténué une attaque DDoS multivectorielle atteignant 15,72 Tbps et près de 3,64 milliards de paquets par seconde (pps). Il s'agissait de la plus grande attaque DDoS jamais observée dans le cloud, qui visait un seul point de terminaison en Australie.

« Grâce à l'infrastructure de protection DDoS distribuée à l'échelle mondiale d'Azure et à ses capacités de détection continue, des mesures d'atténuation ont été mises en place. Le trafic malveillant a été efficacement filtré et redirigé, ce qui a permis de maintenir la disponibilité ininterrompue des services pour les charges de travail des clients.

« L'attaque provenait du botnet Aisuru. Aisuru est un botnet IoT de type Turbo Mirai qui provoque fréquemment des attaques DDoS record en exploitant des routeurs et des caméras domestiques compromis, principalement chez des FAI résidentiels aux États-Unis et dans d'autres pays.

« L'attaque consistait en des inondations UDP à très haut débit ciblant une adresse IP publique spécifique, lancées à partir de plus de 500 000 adresses IP sources dans différentes régions. Ces rafales UDP soudaines comportaient un minimum d'usurpation d'adresse source et utilisaient des ports source aléatoires, ce qui a simplifié le traçage et facilité l'intervention des fournisseurs.

« Les attaquants évoluent au même rythme que l'internet lui-même. À mesure que les débits de la fibre optique à domicile augmentent et que les appareils IdO deviennent plus puissants, la taille des attaques ne cesse de croître. »

Une corruption interne invisible… jusqu’à l’embrasement

Mais après une enquête plus approfondie, le personnel de Cloudflare s'est rendu compte que le problème avait une cause interne : un fichier important avait doublé de taille de manière inattendue et s'était propagé sur le réseau. Cela a causé des problèmes aux logiciels qui doivent lire le fichier pour maintenir le système de gestion des bots Cloudflare, qui utilise un modèle d'apprentissage automatique pour protéger contre les menaces de sécurité. Le CDN principal de Cloudflare, ses services de sécurité et plusieurs autres services ont été affectés.

« Après avoir initialement soupçonné à tort que les symptômes que nous observions étaient causés par une attaque DDoS à très grande échelle, nous avons correctement identifié le problème principal et avons pu arrêter la propagation du fichier de fonctionnalités plus volumineux que prévu et le remplacer par une version antérieure du fichier », a écrit Prince dans un compte rendu post-mortem de la panne.

Prince a expliqué que le problème « a été déclenché par une modification des autorisations de l'un de nos systèmes de base de données, qui a conduit la base de données à générer plusieurs entrées dans un "fichier de fonctionnalités" utilisé par notre système de gestion des bots. Ce fichier de fonctionnalités a alors doublé de taille. Le fichier de fonctionnalités plus volumineux que prévu s'est ensuite propagé à toutes les machines qui composent notre réseau. »

Ces machines exécutent un logiciel qui achemine le trafic sur le réseau Cloudflare. Le logiciel « lit ce fichier de fonctionnalités afin de maintenir notre système de gestion des bots à jour face à des menaces en constante évolution », a écrit Prince. « Le logiciel avait une limite de taille pour le fichier de fonctionnalités qui était inférieure à sa taille doublée. Cela a provoqué la défaillance du logiciel. »


Des répercussions sur Internet

Après avoir remplacé le fichier de fonctionnalités surchargé par une version antérieure, le flux du trafic principal est « en grande partie » revenu à la normale, a écrit Prince. Mais il a fallu encore deux heures et demie « pour atténuer la charge accrue sur différentes parties de notre réseau alors que le trafic reprenait en ligne ».

Tout comme Amazon Web Services, Cloudflare est utilisé par de nombreux services en ligne et peut paralyser une grande partie du Web lorsqu'il rencontre un problème technique. « Au nom de toute l'équipe de Cloudflare, je tiens à m'excuser pour les désagréments que nous avons causés à Internet aujourd'hui », a écrit Prince, ajoutant que toute interruption de service est inacceptable en raison de « l'importance de Cloudflare dans l'écosystème Internet ».

Le système de gestion des bots de Cloudflare classe les bots comme bons ou mauvais à l'aide « d'un modèle d'apprentissage automatique que nous utilisons pour générer des scores de bots pour chaque requête traversant notre réseau », a écrit Prince. « Nos clients utilisent les scores des bots pour contrôler quels bots sont autorisés à accéder à leurs sites, ou non. »

Prince a expliqué que le fichier de configuration sur lequel repose ce système décrit les « caractéristiques », ou traits individuels « utilisés par le modèle d'apprentissage automatique pour prédire si la requête était automatisée ou non ». Ce fichier est mis à jour toutes les cinq minutes « et publié sur l'ensemble de notre réseau, ce qui nous permet de réagir aux variations du trafic sur Internet. Il nous permet de réagir aux nouveaux types de bots et aux nouvelles attaques de bots. Il est donc essentiel qu'il soit déployé fréquemment et rapidement, car les acteurs malveillants changent rapidement de tactique.

Quand la redondance amplifie la panne

Chaque nouvelle version du fichier est générée par une requête exécutée sur un cluster de bases de données ClickHouse, explique Prince. Lorsque Cloudflare a apporté une modification accordant des autorisations supplémentaires aux utilisateurs de la base de données, la réponse à la requête a soudainement contenu plus de métadonnées qu'auparavant.

Le personnel de Cloudflare a supposé « que la liste des colonnes renvoyées par une requête comme celle-ci ne comprendrait que la base de données "par défaut". Mais la requête ne comprenait pas de filtre pour le nom de la base de données, ce qui a entraîné le renvoi de doublons de colonnes », note Prince.

C'est le type de requête que le système de gestion des bots de Cloudflare utilise « pour construire chaque "fonctionnalité" d'entrée pour le fichier », écrit-il. Les métadonnées supplémentaires ont plus que doublé le nombre de lignes dans la réponse, « affectant finalement le nombre de lignes (c'est-à-dire les fonctionnalités) dans le fichier final », écrit Prince.

Le service proxy de Cloudflare a des limites pour éviter une consommation excessive de mémoire, le système de gestion des bots ayant « une limite sur le nombre de fonctionnalités d'apprentissage automatique pouvant être utilisées au moment de l'exécution ». Cette limite est de 200, bien au-dessus du nombre réel de fonctionnalités utilisées.

« Lorsque le fichier corrompu contenant plus de 200 fonctionnalités a été propagé à nos serveurs, cette limite a été atteinte, ce qui a provoqué une panique du système » et généré des erreurs, écrit Prince.


La pire panne de Cloudflare depuis 2019

Le nombre de codes d'état HTTP 5xx renvoyés par le réseau Cloudflare est normalement « très faible », mais il a grimpé en flèche après la propagation du fichier corrompu sur le réseau. « Le pic, et les fluctuations qui ont suivi, montrent que notre système a échoué en raison du chargement d'un fichier de fonctionnalités incorrect », a écrit Prince. « Il est à noter que notre système s'est ensuite rétabli pendant un certain temps. Il s'agissait d'un comportement très inhabituel pour une erreur interne. »

Ce comportement inhabituel s'explique par le fait « que le fichier était généré toutes les cinq minutes par une requête exécutée sur un cluster de bases de données ClickHouse, qui était progressivement mis à jour afin d'améliorer la gestion des autorisations », indique Prince. « Les données erronées n'étaient générées que si la requête était exécutée sur une partie du cluster qui avait été mise à jour. Par conséquent, toutes les cinq minutes, il y avait une chance qu'un ensemble de fichiers de configuration corrects ou incorrects soit généré et se propage rapidement sur le réseau. »

Cette fluctuation « nous a d'abord amenés à penser qu'elle pouvait être causée par une attaque. Finalement, chaque nœud ClickHouse générait le fichier de configuration incorrect et la fluctuation s'est stabilisée dans l'état défaillant », écrit-il.

Cette fluctuation « nous a d'abord amenés à penser qu'il pouvait s'agir d'une attaque. Finalement, tous les nœuds ClickHouse ont généré le fichier de configuration erroné et la fluctuation s'est stabilisée dans un état défaillant », a-t-il écrit.

Prince a déclaré que Cloudflare « a résolu le problème en arrêtant la génération et la propagation du fichier de fonctionnalités incorrect et en insérant manuellement un fichier correct connu dans la file d'attente de distribution des fichiers de fonctionnalités », puis en « forçant le redémarrage de notre proxy central ». L'équipe s'est ensuite attelée à « redémarrer les services restants qui étaient entrés dans un état incorrect » jusqu'à ce que le volume des codes d'erreur 5xx revienne à la normale plus tard dans la journée.

Prince a déclaré que cette panne était la pire subie par Cloudflare depuis 2019 et que l'entreprise prenait des mesures pour se prémunir contre des défaillances similaires à l'avenir. Cloudflare s'efforcera de « renforcer l'ingestion des fichiers de configuration générés par Cloudflare de la même manière que nous le ferions pour les entrées générées par les utilisateurs ; d'activer davantage de kill switches globaux pour les fonctionnalités ; d'éliminer la possibilité que les vidages de mémoire ou autres rapports d'erreurs saturent les ressources du système ; [et] d'examiner les modes de défaillance pour les conditions d'erreur dans tous les modules proxy centraux », selon Prince.

Bien que Prince ne puisse pas promettre que Cloudflare ne connaîtra plus jamais de panne de la même ampleur, il a déclaré que les pannes précédentes « nous ont toujours amenés à construire de nouveaux systèmes plus résilients ».

Sources : Cloudflare (1, 2), Microsoft

Et vous ?

Comment expliquer qu’un simple fichier de configuration puisse encore, en 2025, provoquer un incident d’ampleur mondiale alors que les géants du cloud possèdent des infrastructures distribuées redondantes ?

Quelles pratiques devraient être mises en place pour empêcher un fichier de Bot Management ou toute configuration sensible de devenir un point de défaillance systémique ? Faut-il imposer des limites plus strictes, une validation humaine, ou des tests préventifs automatisés beaucoup plus agressifs ?

Dans quelle mesure l’hyper-centralisation des infrastructures cloud pose-t-elle un risque stratégique pour l’Internet mondial ? Des alternatives régionales, souveraines ou multicloud doivent-elles devenir la norme plutôt que l’exception ?

Le principe même de l’Anycast, conçu pour absorber les chocs, peut-il, dans certaines conditions, amplifier une panne au lieu de la contenir ? Les architectures actuelles sont-elles prêtes à gérer ce paradoxe, ou faut-il repenser la manière dont les nœuds reçoivent et valident leurs configurations ?