Cloudflare, l’un des acteurs clés de l’infrastructure internet, a reconnu que la panne mondiale survenue le 18 novembre 2025 résulte d’une défaillance interne de son propre réseau, et non d’une cyberattaque. Pendant plusieurs heures, des millions d’utilisateurs dans le monde ont vu s’afficher des pages d’erreur au lieu des sites web dépendant de ses services de CDN et de sécurité.

La société a publié un rapport technique détaillant précisément ce qui s’est passé, pourquoi ses mécanismes de protection ont échoué, et quelles mesures elle prévoit de mettre en place pour éviter qu’un incident similaire ne se reproduise. Le directeur général de Cloudflare lui-même admet qu’il s’agit du « plus grave blackout depuis 2019 » et qualifie cet incident d’« inacceptable » étant donné l’importance de l’entreprise dans l’écosystème internet.

Un changement apparemment mineur qui a fait s’effondrer le réseau mondial

Le problème a débuté le 18 novembre à 11h20 UTC, lorsque le réseau de Cloudflare a commencé à renvoyer massivement des erreurs HTTP 5xx, signe d’une panne interne dans ses systèmes. Pour les utilisateurs finaux, cela se traduisait par une page d’erreur Cloudflare au lieu du contenu habituel.

La cause n’a pas été une attaque, mais une succession d’effets déclenchés par une modification des permissions sur un des systèmes de bases de données que la société utilise pour alimenter son module de gestion des bots (Bot Management). Ce changement a entraîné la génération d’un fichier de configuration (qu’on appelle feature file) beaucoup plus volumineux que prévu, avec des lignes dupliquées.

Ce fichier, distribué toutes les quelques minutes à tous les serveurs du réseau Cloudflare, indique au système de détection des bots quelles caractéristiques prendre en compte pour évaluer chaque requête et décider si elle est automatisée ou légitime.

En doublant le nombre de caractéristiques, le fichier dépassait une limite de taille maximale prévue dans le logiciel des nœuds du réseau. Le module de gestion des bots n’étant pas configuré pour traiter plus de 200 « features », l’ouverture du fichier a provoqué une erreur non gérée, interrompant le fonctionnement du proxy central de Cloudflare, qui a commencé à retourner des erreurs 5xx en masse.

Une erreur intermittente qui a semé la confusion et laissé penser à une attaque

Au début de l’incident, les graphiques internes de la société montraient un comportement étrange : le volume d’erreurs 5xx montait brusquement, se stabilisait, semblait s’améliorer puis repartait à la hausse. Ce pattern intermittant a conduit dans un premier temps à suspecter une attaque par déni de service distribué (DDoS) d’envergure.

La suite a confirmé que le fichier de caractéristiques était généré toutes les cinq minutes sur le cluster ClickHouse. Comme la mise à jour des permissions n’avait pas été appliquée à tous les nœuds, selon celui qui exécutait la requête, le fichier pouvait être « correct » ou « incorrect ». Cela expliquait que, pendant un certain temps, le réseau fonctionnait normalement, jusqu’à la propagation d’un nouveau fichier défectueux, relançant la cascade d’erreurs.

Une fois la mise à jour des permissions achevée sur tous les nœuds, le comportement s’est stabilisé, avec une erreur persistante. L’équipe d’ingénierie a alors identifié la cause : arrêter la génération du fichier erroné, le remplacer par une version antérieure fiable, puis redémarrer les services concernés.

Selon la chronologie interne, le trafic a commencé à se rétablir à partir de 14h30 UTC, la normalité complète n’étant atteinte qu’à 17h06 UTC, une fois les services remis en marche après leur incohérence initiale.

Comment fonctionne le proxy de Cloudflare et pourquoi la chaîne a craqué

Pour comprendre l’ampleur du problème, la société a expliqué le parcours d’une requête lorsqu’un utilisateur accède à un site utilisant Cloudflare :

1. La connexion s’établit au niveau HTTP et TLS.
2. La requête entre dans le proxy central (appelé en interne FL, Frontline), chargé d’appliquer règles de sécurité, performance et routage.
3. Via un composant nommé Pingora, le système vérifie si le contenu est en cache ou s’il doit être récupéré sur le serveur d’origine.

Ce parcours passe par différents modules spécialisés : pare-feu d’applications web (WAF), protection contre DDoS, gestion des accès, plateforme pour développeurs, stockage distribué, et parmi eux, le module de Bot Management.

Ce dernier utilise un modèle d’apprentissage automatique qui attribue une « probabilité d’être un bot » à chaque requête. Il doit charger en mémoire un fichier de configuration avec les caractéristiques (features) alimentant le modèle.

Ce fichier est mis à jour en permanence pour s’adapter aux nouveaux schémas de trafic et tactiques des attaquants. Toutefois, sa conception supposait que sa taille resterait relativement stable et limitée. Lors du changement dans ClickHouse, quand le nombre de caractéristiques a dépassé la limite fixée, le module de bots a lancé une erreur non gérée, entraînant l’échec du processus du proxy central. Résultat : le réseau a commencé à ne plus pouvoir routage le trafic normalement et à répondre par des erreurs 5xx génériques.

Différences entre la vieille et la nouvelle version du proxy

Parallèlement, Cloudflare était en plein processus de migration vers une nouvelle version de son proxy, connue en interne sous le nom de FL2, écrite en Rust. Si la version ancienne (FL) comme la nouvelle ont été affectées par le problème du fichier de caractéristiques, leurs impacts ont été différents :

• Dans FL2, la défaillance du module de bots se traduisait directement par des erreurs HTTP 5xx visibles par l’utilisateur.
• Dans FL, le système ne renvoyait pas d’erreurs, mais tous les trafics recevaient une note de « bot » égale à zéro, ce qui pouvait conduire à de faux positifs dans les règles de blocage basées sur ces scores.

En résumé, les clients déjà migrés vers FL2 subissaient un impact plus visible (pages d’erreur), tandis que ceux utilisant l’ancienne version souffraient d’un effet plus subtil, lié à la détection des bots, mais également indésirable.

Services affectés : CDN, Workers KV, Access, Turnstile et tableau de bord

Le dysfonctionnement du proxy n’a pas seulement perturbé le service principal de CDN et de sécurité, mais aussi plusieurs autres produits dépendant de cette même route interne :

• Services principaux CDN et sécurité : erreurs 5xx, pages de Cloudflare typiques signalant une erreur interne.
• Workers KV : le stockage clé-valeur pour applications sans serveur a renvoyé des erreurs en forte hausse, dépendant de la passerelle frontale impactée.
• Cloudflare Access : les tentatives d’authentification ont échoué massivement, même si les sessions actives ont continué à fonctionner.
• Turnstile : le système de protection sur formes a été affecté, empêchant de nombreux utilisateurs de se connecter au tableau de bord Cloudflare.
• Tableau de bord (dashboard) : bien que certaines fonctions soient restées opérationnelles, l’accès pour de nouveaux utilisateurs a été bloqué par les dysfonctionnements de Turnstile et Workers KV.
• Email Security : il n’a pas perdu la capacité de traiter les emails, mais la précision de ses systèmes de réputation IP et quelques actions automatiques a temporairement diminué.

De plus, la latence dans le réseau de distribution de contenu s’est accrue pendant l’incident, non seulement en raison de la défaillance elle-même, mais aussi parce que les outils internes de surveillance et de débogage ont consommé une grande quantité de CPU supplémentaire pour tenter de recueillir des données sur les erreurs.

D’un soupçon de DDoS massif à une erreur de configuration

Un autre facteur ayant compliqué le diagnostic a été que, parallèlement, la page publique d’état de Cloudflare a aussi cessé de fonctionner, malgré qu’elle soit hébergée hors de l’infrastructure de la société. Bien que cette coincidence ait été fortuite, elle a alimenté pendant un temps l’hypothèse d’une attaque coordonnée contre le réseau et les systèmes externes de reporting.

Les canaux internes ont même envisagé que cela pourrait être une suite d’une vague récente d’attaques DDoS à grande échelle. Ce n’est que lorsqu’un lien a été fait avec les changements dans ClickHouse, la croissance anormale du fichier de caractéristiques et les limites mémoire du module de bots, qu’il est devenu clair que la cause était strictement interne.

Leçons tirées et engagements de changement

Une fois le service rétabli, Cloudflare a listé plusieurs axes pour renforcer sa plateforme face à des incidents similaires :

• Renforcer la gestion des fichiers de configuration générés en interne, en les traitant avec autant de précaution que des données entrées par des sources externes.
• Mettre en place davantage de “kill switches” permettant de désactiver rapidement certains modules, comme celui des bots, sans arrêter tout le proxy.
• Empêcher que les dumps mémoire et outils de diagnostic saturent les ressources en cas d’erreur, afin que ces outils ne noircissent pas davantage la crise.
• Revoir le mode de gestion des erreurs de tous les modules du proxy central, pour qu’une erreur dans une composante ne puisse pas faire escaler la panne à toute la chaîne.

L’entreprise insiste sur le fait qu’un tel blackout « est inacceptable » et reconnait la gravité d’avoir laissé une part importante du trafic principal d’internet interrompu pendant plusieurs heures. Elle souligne aussi que chacun de ces incidents graves a permis d’ajouter de nouvelles couches de résilience et de revoir en profondeur ses architectures.

Dans un écosystème où entreprises, médias, administrations et services essentiels dépendent de quelques grands fournisseurs d’infrastructure, la panne du 18 novembre rappelle la fragilité du réseau et l’importance pour ces acteurs d’être transparents quand quelque chose se brise. Cloudflare, cette fois, a choisi de dévoiler en détail ce qui s’est passé et d’assumer la responsabilité d’un des plus grands écueils de son histoire récente.

Sources :

• Rapport technique de Cloudflare « Cloudflare outage on November 18, 2025 », publié sur son blog officiel.

via : blog.cloudflare