Dans un billet détaillé, Cloudflare est revenue sur l'incident qui a brièvement mis KO une bonne partie du web vendredi dernier, expliquant comment un ensemble de décisions internes ont convergé vers un scénario catastrophe rapidement maîtrisé.
Le 5 décembre à 09h47 heure française, une partie du réseau Cloudflare a commencé à renvoyer des erreurs 500 en cascade. À 10h12, soit 25 minutes plus tard, tout était revenu à la normale, mais le bilan était lourd. Environ 28 % du trafic HTTP servi par Cloudflare avait été affecté, entraînant l’indisponibilité d’un large ensemble de sites et une dégradation visible des performances en ligne. En revenant sur les faits dans un billet de blog dédié, la société a confirmé que l’incident n’avait aucun lien avec une éventuelle attaque et qu’il était lié à un problème interne déclenché alors qu’elle travaillait à atténuer une vulnérabilité critique touchant l’écosystème React. Ou comment un enchaînement de décisions techniques et organisationnelles a révélé un vieux bug jamais identifié, responsable de la panne.
Offre partenaire
Protection avancée des e-mails, des calendriers, des mots de passe, du réseau… de votre entreprise grâce à la suite d'applications professionnelles sécurisées.
Offre partenaire
Comment une simple modification interne a dégénéré en panne mondiale
Pour comprendre de quoi il retourne, il faut savoir que Cloudflare administre un pare-feu web applicatif, ou WAF, chargé d’inspecter le trafic qui transite par son infrastructure. C’est lui qui analyse chaque requête pour y repérer des charges malveillantes ou des tentatives d’exploitation avant qu’elles n’atteignent les sites et services protégés par Cloudflare. Pour effectuer ces contrôles, il place en mémoire une partie des données envoyées par les internautes et par les services en interaction avec ces sites, ce qui lui permet d’examiner leur contenu. Jusqu’à présent, ce tampon était limité à 128 Ko, valeur suffisante pour la plupart des usages courants.
La semaine dernière, Cloudflare a identifié une faille critique dans React Server Components, référencée CVE-2025-55182. Dans les grandes lignes, ces composants côté serveur, utilisés par React et des frameworks comme Next.js, permettent de précharger une partie des pages web avant qu’elles ne s’affichent dans le navigateur pour améliorer leur rapidité et leur fluidité. Or, le protocole chargé d’échanger les données entre ces composants peut accepter des requêtes volumineuses, ce qui peut permettre à des attaquants d’envoyer des charges malveillantes suffisamment importantes pour tenter d’exploiter la vulnérabilité et déclencher une exécution de code à distance sur des sites intégrant des versions vulnérables de React ou de Next.js.
Pour augmenter ses chances de repérer ces tentatives d’exploitation, Cloudflare a donc élargi la taille du tampon utilisé par son WAF. La limite de 128 Ko est progressivement passée à 1 Mo, ce qui devait permettre d’inspecter des charges autrement trop importantes pour être analysées correctement.
Mais les choses se sont compliquées lorsque les équipes ont découvert que l’outil chargé de valider la configuration du WAF ne prenait pas en charge la nouvelle limite. Comme ce dispositif sert uniquement aux tests internes et n’a aucun impact sur le trafic client, Cloudflare a finalement choisi de le désactiver via le système de configuration générale, qui répercute les changements immédiatement sur l’ensemble de l’infrastructure plutôt que de les diffuser graduellement. Cette mise à jour rapide a alors touché des serveurs reposant encore sur une ancienne génération de proxys (FL1), incapables d’interpréter la nouvelle configuration, ce qui les a fait planter. Résultat, une bonne partie visible de l’Internet mondial à genoux.
La cause de la panne a finalement été identifiée et les modifications annulées, si bien que 25 minutes après le début de l'incident, le trafic était à nouveau routé sans problème. Un retour à la normale nettement plus rapide que celui de la panne de novembre.
Une panne qui soulève un problème d’infrastructure plus large
Au-delà du détail technique ayant provoqué la panne, l’incident met surtout en évidence un problème plus profond lié à l’ampleur et à l’hétérogénéité de l’infrastructure Cloudflare. Le fonctionnement du réseau repose sur une combinaison de systèmes récents, régulièrement mis à jour, et de composants plus anciens encore utilisés dans certaines régions. Cette coexistence n’a rien d’exceptionnel à cette échelle, mais elle crée des zones où des morceaux de code vieillissants peuvent réagir de manière imprévisible à des changements pourtant maîtrisés dans le reste du parc.
C’est exactement ce qui s’est produit avec les proxys FL1. Leur rôle dans l’architecture est marginal et, en temps normal, totalement transparent pour les clients. Leur comportement n’avait jamais posé problème, faute d’avoir été confrontés à une modification aussi rapide et aussi large.
L’autre enjeu concerne le dispositif de propagation des modifications, et plus précisément le système de configuration générale, conçu pour appliquer immédiatement les mises à jour à l’ensemble du réseau. Dans la plupart des cas, cette stratégie limite les risques d’incohérence et réduit le temps d’exposition aux vulnérabilités, mais elle laisse aussi moins de marge pour détecter un comportement anormal localisé avant qu’il ne se propage. De fait, un déploiement progressif aurait sans doute permis de repérer plus tôt l’incompatibilité avec FL1, mais au prix d’un délai supérieur pour la mise en place des mesures de mitigation concernant la faille CVE-2025-55182, vis-à-vis de laquelle Cloudflare estimait ne pas pouvoir attendre davantage.
L’entreprise a donc rappelé qu’elle menait déjà plusieurs chantiers prioritaires destinés à empêcher qu’une seule opération ne puisse affecter autant de serveurs en si peu de temps. Parmi ces évolutions figurent une gestion plus fine des déploiements, une meilleure isolation des opérations critiques via des mécanismes permettant de contourner temporairement certaines vérifications internes en cas d’urgence, ainsi que des garde-fous supplémentaires pour que les serveurs continuent de fonctionner même lorsqu’ils reçoivent une configuration imparfaite.
Source : Cloudflare
