Skip to content
Exploitation de vulnérabilitéRésolu

Fuite mémoire « Cloudbleed » de Cloudflare

Un bug de dépassement de tampon dans les serveurs périphériques de Cloudflare les amenait à divulguer des fragments de mémoire adjacente — mots de passe, cookies et messages privés d'autres clients — dans des pages web, dont certains ont été mis en cache par les moteurs de recherche. La faille est restée active pendant des mois avant d'être découverte par Project Zero de Google.

Victime
Cloudflare, Inc.

En février 2017, le chercheur en sécurité Tavis Ormandy, de Project Zero de Google, a découvert que Cloudflare — le réseau de diffusion de contenu et de proxy inverse placé devant des millions de sites web — divulguait des fragments aléatoires de la mémoire de ses propres serveurs dans des pages web. Ces fragments pouvaient contenir tout ce qui avait récemment transité par la périphérie de Cloudflare : mots de passe, cookies de session, jetons d'authentification, corps de requêtes HTTP POST et messages privés appartenant à des clients totalement étrangers les uns aux autres. Comme certaines des pages fuyant ces données étaient mises en cache par les moteurs de recherche, des données sensibles sont restées exposées dans des caches publics bien après la correction du bug lui-même. La faille a été baptisée « Cloudbleed », en écho à la vulnérabilité Heartbleed de 2014.

Ce qui s'est passé

Les serveurs périphériques de Cloudflare exécutaient un analyseur HTML qui réécrivait les pages à la volée — pour masquer les adresses électroniques, appliquer les Server-Side Excludes et réécrire automatiquement les liens HTTP en HTTPS. Un subtil bug de dépassement de tampon dans ce code d'analyse faisait que, lorsque le code HTML d'une page était malformé d'une certaine manière, l'analyseur dépassait la fin d'un tampon et émettait la mémoire non initialisée adjacente dans la réponse renvoyée aux visiteurs.

Cette mémoire divulguée n'était pas du bruit aléatoire — c'étaient des données en direct provenant d'autres requêtes transitant par les mêmes serveurs Cloudflare. Un visiteur d'un site pouvait, par hasard, recevoir un fragment du mot de passe ou du message privé d'une autre personne intégré dans la page qu'il chargeait.

Ampleur et exposition

  • Le bug a pu divulguer de la mémoire dès le 22 septembre 2016, mais la période d'impact maximal s'est étendue d'environ le 13 au 18 février 2017, lorsqu'une fonctionnalité nouvellement déployée a fortement augmenté le taux de fuite.
  • Au pic, environ 1 requête HTTP sur 3,3 millions transitant par Cloudflare risquait de divulguer de la mémoire — un faible ratio, mais qui, rapporté à l'énorme volume de trafic de Cloudflare, signifiait que le bug s'est déclenché des millions de fois.
  • Les données divulguées couvraient une vaste base de clients : Cloudflare protégeait des millions de domaines, de sorte qu'un seul bug exposait simultanément des fragments provenant de tout le web.
  • Le risque le plus aigu provenait des caches des moteurs de recherche, où les données divulguées avaient été indexées et stockées. Cloudflare a collaboré avec Google, Bing, Yahoo et d'autres pour purger les pages mises en cache.

Réaction

Ormandy a signalé le bug à Cloudflare le 17 février 2017. L'équipe de Cloudflare a désactivé les trois fonctionnalités fautives en quelques heures après réception du signalement, les a globalement coupées dès le lendemain et a déployé un correctif permanent en quelques jours. L'entreprise a publié un rapport d'incident public détaillé le 23 février. Les enquêteurs n'ont trouvé aucune preuve que des attaquants aient découvert ou exploité le bug avant qu'il ne soit signalé.

Pourquoi c'est important

Cloudbleed est l'exemple type de la manière dont un seul bug de sécurité mémoire dans une infrastructure partagée peut avoir un rayon d'impact démesuré. Parce que les proxys de Cloudflare traitent le trafic de millions de sites sans rapport entre eux, une faille affectant un seul chemin de code divulguait des données indistinctement à travers tous ces sites — et l'implication de la mise en cache par les moteurs de recherche a étendu le nettoyage bien au-delà du simple correctif des serveurs d'origine. L'incident a renforcé deux leçons : que le code d'analyse non sûr en mémoire reste un risque critique dans les systèmes à haut débit, et que la centralisation du web derrière une poignée de fournisseurs périphériques concentre le risque autant que les bénéfices. Il est fréquemment cité aux côtés de Heartbleed comme argument en faveur des langages à sécurité mémoire pour les analyseurs sensibles à la sécurité.

Chronologie

  1. Le bug de dépassement de tampon devient potentiellement exploitable — la date la plus ancienne à partir de laquelle les serveurs périphériques de Cloudflare ont pu divulguer de la mémoire.

  2. Une nouvelle fonctionnalité (Automatic HTTP Rewrites) utilisant l'analyseur cf-html augmente fortement le taux de fuite mémoire ; la période d'impact maximal commence.

  3. Tavis Ormandy, de Project Zero de Google, remarque des données sensibles corrompues dans des réponses web lors d'un fuzzing, les relie à Cloudflare et les signale. Cloudflare désactive les fonctionnalités concernées en quelques heures.

  4. Cloudflare désactive globalement les trois fonctionnalités responsables (obfuscation des courriels, Server-Side Excludes, Automatic HTTPS Rewrites) ; la période de fuite maximale prend fin.

  5. Cloudflare publie son rapport d'incident public, donnant au bug son surnom de « Cloudbleed ».

  6. Cloudflare et les moteurs de recherche achèvent un balayage pour purger les données mises en cache divulguées ; les enquêteurs ne relèvent aucune preuve d'exploitation malveillante.

Sources

  1. blog.cloudflare.comhttps://blog.cloudflare.com/incident-report-on-memory-leak-caused-by-cloudflare-parser-bug/
  2. en.wikipedia.orghttps://en.wikipedia.org/wiki/Cloudbleed
  3. bugs.chromium.orghttps://bugs.chromium.org/p/project-zero/issues/detail?id=1139
  4. rapid7.comhttps://www.rapid7.com/blog/post/2017/02/24/cloudflare-data-leakage-or-dare-i-saycloudbleed/

Incidents liés

Exploitation de vulnérabilitéEn cours

Faille de gravité maximale dans Ivanti Sentry exploitée pour exécuter du code en root (CVE-2026-10520)

Ivanti a corrigé une faille d'injection de commandes sans authentification de gravité maximale dans sa passerelle mobile Sentry, permettant aux attaquants une exécution de code à distance avec les privilèges root ; quelques jours plus tard, l'exploitation réelle a suivi la publication d'une preuve de concept, conduisant la CISA à l'ajouter à son catalogue des vulnérabilités activement exploitées.

Victim
Ivanti Sentry
Exploitation de vulnérabilitéContenu

ServiceNow révèle une faille d'API sans authentification ayant permis d'interroger les données d'instances clientes

ServiceNow a révélé qu'un point de terminaison REST mal configuré et accessible sans authentification permettait d'interroger les données d'instances clientes hébergées, un problème corrigé le 5 juin mais dont l'avis (réservé aux clients connectés) n'a été publié que plusieurs jours plus tard.

Victim
ServiceNow
Exploitation de vulnérabilitéRésolu

Fuite de données FriendFinder Networks

Une faille d'inclusion de fichier local a permis aux attaquants de dérober 412 millions de comptes sur les sites pour adultes et de rencontres de FriendFinder Networks, dont AdultFriendFinder. La plupart des mots de passe étaient stockés en clair ou en SHA-1 non salé, et les comptes « supprimés » ne l'avaient jamais réellement été.

Victim
FriendFinder Networks
Records
412.2M