# Une expression régulière a mis Cloudflare hors service. 27 minutes.

Published: 2026-09-12

2 juillet 2019, 13:42 UTC : une nouvelle règle pour le pare-feu d'application web de Cloudflare est déployée dans plus de 180 villes en environ deux secondes. Il s'agit d'une règle XSS en mode simulation, elle ne bloque donc rien, mais elle s'exécute quand même sur chaque requête, et elle se termine par .\*(?:.\*=.\*). Le PCRE effectue des retours arrière, chaque cœur de CPU servant des requêtes HTTP atteint 100 %, et chaque site proxy par Cloudflare renvoie 502 pendant 27 minutes ; le trafic chute de 82 %. L'interrupteur d'urgence se trouve derrière Cloudflare Access, qui lui-même se trouve derrière Cloudflare. Autopsie, d'après le propre rapport de Cloudflare : la protection CPU supprimée des semaines plus tôt lors d'un refactoring censé économiser du CPU, la procédure qui permettait à n'importe quelle règle de sauter la phase de test, le moteur sans garantie de complexité, les 11 causes et les 7 correctifs. Verdict sur le correctif : SHIP IT.

Canonical: https://thedailydiff.dev/fr/video/2026-09-12-cloudflare-regex/

## Ce que couvre cette vidéo

- 13:31–13:42 UTC : PR fusionnée, CI verte (pas de test CPU), Quicksilver pousse la règle dans plus de 180 villes ; les règles WAF sautent les étapes DOG → PIG → Canary
- 13:45–14:07 : première page ; CPU 100 % dans le monde, trafic −82 %, 502 partout ; le panneau de contrôle interne est derrière Cloudflare Access, qui est en panne ; certains identifiants ont expiré ; un contournement rarement exercé
- 14:07–14:09 : arrêt global du WAF ; trafic et CPU normaux après 27 minutes ; 14:52 WAF de retour moins la règle
- 2 juillet (15:50 UTC) et 12 juillet : Cloudflare publie la note du jour même et l'autopsie complète ; la protection CPU est réintégrée, 3 868 règles sont relues, des déploiements par étapes sont mis en place, passage à un moteur d'expressions régulières à temps linéaire

## Transcription traduite

Traduit de la narration originale en anglais. L'audio et les sous-titres disponibles sont gérés par YouTube.

0:00 Une expression régulière est mise en ligne sur chaque serveur Cloudflare à la fois, et pendant les vingt-sept minutes suivantes, les sites derrière elle affichent une page 502, ce qui, pour un pare-feu, est le paramètre le plus strict possible. 2 juillet 2019, 13h42 UTC. Cloudflare publie en moins de deux heures : pas une attaque, un mauvais déploiement, le trafic baisse de 82 pour cent. Dix jours plus tard, le CTO John Graham-Cumming publie l'autopsie complète, expression régulière incluse, et Hacker News lui attribue 698 points,

0:26 ce qui pour une panne est une ovation debout. Comment cela arrive, pourquoi c'est possible, et qui est réellement à blâmer. Voici The Daily Diff, postmortem. 13h31. Une pull request fusionne : une nouvelle règle de pare-feu contre les scripts intersites, en mode simulation, elle ne bloque donc rien. 13h37, les tests passent ; aucun ne mesure le CPU. 13h42, la règle est expédiée à 180 villes en deux secondes, car les règles WAF sautent les étapes chien, cochon et canari que les autres versions obtiennent.

0:54 13h45, la première page. 13h49, Hacker News a un fil de discussion sur la page de statut, qui indique toujours que tous les systèmes sont opérationnels. La règle se termine par point-étoile, point-étoile, égal, point-étoile : n'importe quoi, puis n'importe quoi, puis un signe égal. PCRE devine avec avidité, échoue, et revient en arrière sur chaque autre division. x égal x prend 23 étapes. Vingt x après l'égal : 555.

1:15 Vingt x, pas de signe égal : 4 067 étapes pour ne rien trouver. Exécutez cela sur chaque requête et chaque cœur est à cent pour cent, ne faisant rien, minutieusement. Deux gardes auraient dû le détecter. La limite CPU sur les règles a été supprimée par erreur des semaines plus tôt, lors d'un refactoring destiné à faire en sorte que le WAF utilise moins de CPU. Et la procédure permet à n'importe quelle règle de sauter la phase de test, car les règles existent pour arrêter les attaques en direct ; celle-ci n'était pas une urgence, et elle est quand même devenue globale.

1:37 14h00, le WAF est identifié ; pas d'attaque. 14h02, quelqu'un propose l'arrêt global : un composant, éteint, dans le monde entier. L'interrupteur est derrière Cloudflare Access. Cloudflare Access est derrière Cloudflare. Certains identifiants ont expiré par désuétude, donc le réseau le plus rapide sur internet passe cinq minutes sur un contournement que personne n'a exercé. 14h07, arrêt. 14h09, trafic normal. git blame : un déploiement à une seule vitesse, global ; une protection CPU refactorisée par

2:04 accident ; un moteur d'expressions régulières sans limite supérieure. Pas l'ingénieur qui a écrit la règle : le postmortem énumère onze causes et ne nomme personne. Rayon d'impact : 27 minutes, 82 pour cent du trafic, 100 pour cent d'utilisation du CPU sur chaque cœur, dans chaque ville. Le tableau de bord et l'API se trouvent derrière la même périphérie, les clients ne peuvent donc même pas le désactiver. le désactiver. Hacker News, sous le postmortem : ils avaient un problème, ont utilisé une expression régulière, maintenant ils en ont deux. Vieille blague. Compile toujours.

2:28 Verdict, postmortem : SHIP IT. La protection CPU est de retour, les 3 868 règles sont lues à la main, les règles passent par la phase de test, et le moteur passe à un moteur avec des garanties de temps linéaire, publiées par Ken Thompson en 1968. Lundi : pas de point-étoile point-étoile dans tout ce qui s'exécute par requête, et gardez l'interrupteur d'arrêt en dehors de la chose qu'il tue. Envoyez-moi l'incident dont vous n'avez toujours pas le droit de parler, dans les commentaires, ou à the daily diff dot dev.

2:53 Et c'est le diff pour aujourd'hui. Je suis Niko d'Axrisi. Fusionnez de manière responsable.

## Sources

- [John Graham-Cumming, "Details of the Cloudflare outage on July 2, 2019" (Jul 12, 2019)](https://blog.cloudflare.com/details-of-the-cloudflare-outage-on-july-2-2019/) — blog.cloudflare.com
- [Matthew Prince, "Cloudflare outage caused by bad software deploy (updated)" (Jul 2, 2019)](https://blog.cloudflare.com/cloudflare-outage/) — blog.cloudflare.com
- [Matthew Prince on X, Jul 2, 2019, 14:22 UTC](https://x.com/eastdakota/status/1146061591143538688) — x.com
- [Matthew Prince on X, Jul 2, 2019, 14:36 UTC ("No evidence yet attack related")](https://x.com/eastdakota/status/1146065231270907907) — x.com
- [Hacker News, Jul 2, 2019, 13:49 UTC — "Cloudflare Network Performance Issues" (631 points)](https://news.ycombinator.com/item?id=20334924) — news.ycombinator.com
- [Hacker News, Jul 2, 2019 — "Cloudflare outage caused by bad software deploy" (348 points)](https://news.ycombinator.com/item?id=20336332) — news.ycombinator.com
- [Hacker News, Jul 12, 2019 — "Details of the Cloudflare outage on July 2, 2019" (698 points)](https://news.ycombinator.com/item?id=20421538) — news.ycombinator.com
- [TechCrunch, Jul 2, 2019](https://techcrunch.com/2019/07/02/a-cloudflare-outage-is-impacting-sites-everywhere/) — techcrunch.com