Brève explication de la vulnérabilité MongoBleed

 (bigdata.2minutestreaming.com)
2 points par GN⁺ 2025-12-30 | 1 commentaires | Partager sur WhatsApp
  • MongoBleed (CVE-2025-14847) est une grave vulnérabilité de fuite de mémoire présente dans toutes les versions de MongoDB depuis 2017, permettant à un attaquant de lire des données arbitraires de la mémoire heap de la base de données
  • La vulnérabilité est causée par un bug dans le chemin de compression zlib et peut être exploitée sans authentification, par une simple connexion à la base de données
  • Un attaquant peut envoyer une requête compressée manipulée pour pousser le serveur à allouer un tampon de taille incorrecte, puis exposer la mémoire de travaux précédents (mots de passe, clés API, etc.) qui s’y trouve
  • MongoDB a publié un correctif le 19 décembre 2025, mais les versions en fin de vie (3.6, 4.0, 4.2) ne sont pas corrigées
  • Cette vulnérabilité, restée présente pendant 8 ans, touche plus de 210 000 instances MongoDB exposées sur Internet et nécessite un correctif immédiat ou la désactivation de la compression, dans les environnements cloud comme on-premise

Vue d’ensemble de MongoBleed

  • MongoBleed (CVE-2025-14847) est une vulnérabilité découverte dans le chemin de compression des messages zlib 1 de MongoDB, qui affecte toutes les versions depuis 2017
    • Un attaquant peut lire des données arbitraires de la mémoire heap simplement en se connectant à la base, sans authentification
    • Les versions en fin de support (EOL) comme MongoDB 3.6, 4.0 et 4.2 ne sont pas corrigées
  • Ce bug a été introduit dans une PR de mai 2017 et a été officiellement rendu public le 19 décembre 2025
  • MongoDB a annoncé avoir appliqué le correctif à toutes les instances, y compris son service cloud Atlas

Structure des communications MongoDB

  • MongoDB utilise son propre protocole TCP au lieu de HTTP, et les messages sont transmis au format BSON (Binary JSON)
  • Toutes les requêtes sont composées sous forme de commande OP_MSG et, lorsqu’elles sont compressées, encapsulées dans un message OP_COMPRESSED
    • Le message inclut des champs comme uncompressedSize, originalOpcode, compressorId, etc.
    • uncompressedSize indique la taille attendue après décompression

Étape 1 de l’exploit — allocation incorrecte du tampon

  • L’attaquant définit la valeur uncompressedSize à une taille excessivement supérieure à la réalité afin de forcer le serveur à allouer un grand tampon
    • Exemple : déclarer un message réel de 1 KB comme s’il faisait 1 MB
  • Après décompression, le serveur MongoDB ne vérifie pas la taille réelle et fait confiance à la taille fournie par l’utilisateur
    • En conséquence, la mémoire conserve une structure du type [données réelles | déchets heap non référencés]
  • Comme MongoDB, écrit en C++, n’initialise pas cette mémoire, cette zone peut contenir des données sensibles provenant de travaux précédents
    • Exemple : mots de passe, jetons de session, clés API, données clients, paramètres système, etc.

Étape 2 de l’exploit — exfiltration de données

  • L’attaquant envoie une entrée BSON malformée pour amener le serveur à parser les déchets mémoire comme une chaîne de caractères
    • Le premier champ de BSON est une chaîne, qui suit la règle des chaînes terminées par un caractère nul (null-terminated string) du langage C
  • Si l’attaquant envoie une chaîne sans caractère de fin nul, le serveur lit alors d’autres données présentes en mémoire
    • Exemple : [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • Le serveur interprète cela comme un champ BSON invalide et renvoie le contenu dans un message d’erreur
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • En répétant ce processus, l’attaquant peut scanner l’ensemble de la mémoire heap et collecter des informations sensibles

Impact et niveau de risque

  • Comme cela se produit avant l’authentification (pre-auth), un attaquant peut accéder aux données sans se connecter
  • Les instances MongoDB exposées sur Internet sont immédiatement à risque
    • D’après une recherche Shodan, plus de 213 000 instances MongoDB sont publiquement accessibles
  • La vulnérabilité a existé pendant environ 8 ans, de 2017 à 2025, et sa structure simple rend une exploitation réelle très plausible
  • MongoDB a déclaré qu’« il n’existe à ce jour aucune preuve d’exploitation », mais n’a publié ni excuses officielles ni chronologie détaillée

Mesures d’atténuation

  • Mettre à jour vers la dernière version corrigée (8.0.17 ou plus)
  • À court terme, il est aussi possible d’atténuer le risque en désactivant la compression réseau zlib
  • Pour les utilisateurs de MongoDB Atlas, le correctif est déjà déployé

Informations supplémentaires et discussions associées

Résumé

  • MongoBleed est une vulnérabilité de fuite de mémoire causée par un bug dans le traitement de la compression zlib
  • Un attaquant peut obtenir des données mémoire précédentes (mots de passe, clés API, etc.) via des requêtes compressées manipulées
  • Toutes les versions de MongoDB entre 2017 et 2025 sont affectées, et l’application du correctif ou la désactivation de la compression est indispensable
  • Plus de 210 000 instances exposées sur Internet sont potentiellement concernées
  • MongoDB a publié un correctif, mais l’absence de support pour les versions EOL et la lenteur de la communication publique sont critiquées

À lire aussi

1 commentaires

 
GN⁺ 2025-12-30
Réactions sur Hacker News
  • Il y a quelques années, j’ai modifié le memory allocator du runtime Cloudflare Workers pour qu’il réécrive toute la mémoire avec un motif d’octets fixe au moment de la libération
    Ainsi, aucune donnée significative ne restait dans la mémoire non initialisée
    Je m’attendais à une baisse de performances, mais en pratique il n’y a eu aucun impact mesurable
    À mon avis, tous ceux qui utilisent des langages non sûrs vis-à-vis de la mémoire devraient faire pareil. Ce bug de Mongo aurait probablement aussi pu être atténué de cette façon
    • Les versions récentes de macOS effectuent automatiquement un zero-out lors de la libération de mémoire
      Cela améliore l’efficacité de la compression mémoire et, en moyenne, cela améliorerait même les performances
    • Sous FreeBSD, si l’on définit la variable d’environnement MALLOC_CONF=opt.junk=free, malloc adopte le même comportement
      Autrement dit, beaucoup d’implémentations proposent déjà cette fonction en option
    • En 2025, je pense que tous les allocateurs généralistes devraient initialiser la mémoire à 0 par défaut
      Si l’on a besoin de plus de performances, il suffit d’écrire un allocateur sur mesure pour un usage spécifique
      Cela permettrait aussi d’autres optimisations impossibles avec l’allocateur système
    • OpenBSD remplit la mémoire nouvellement allouée avec 0xdb et la mémoire libérée avec 0xdf
      Cela permet de repérer rapidement les bugs de type use-before-initialization ou use-after-free
      C’est le réglage par défaut
    • Je me demande si cela revient au même que d’activer l’option init_on_free=1 du noyau
  • On dirait que l’auteur ne connaissait pas bien le processus de développement interne de Mongo
    Mongo développe d’abord dans un dépôt privé en interne, puis transfère les commits vers le dépôt public via Copybara
    La confusion sur les dates vient de là
    • Je ne le savais pas non plus. Je trouvais étrange qu’il n’y ait pas de revue de PR, mais maintenant je comprends
      Je vais mettre l’article à jour pour expliquer ce point ainsi que l’écart de dates
  • L’auteur semble avoir mal compris la chronologie
    Nos clusters Atlas avaient déjà été mis à niveau quelques jours avant la publication du CVE
    • Merci. J’ai mis l’article à jour
  • Dans des systèmes comme les bases de données, faire du zeroing ou du poisoning à la libération mémoire est un bon choix
    De nos jours, la plupart des allocateurs devraient le faire par défaut
    Chris a amélioré cet aspect dans Blink, et le résultat s’est propagé à tout Chromium
    La documentation associée est intéressante aussi
    Article de blog Chromium
    Documentation PartitionAlloc
  • Je me demande à quelle fréquence des instances Mongo sont exposées sur Internet
    Côté SQL, c’est rare, mais ça arrive parfois
    • D’après mon expérience, la raison d’être de MongoDB, c’est la paresse
      La philosophie, c’est de ne se soucier ni du schéma, ni de la durabilité, ni des lectures/écritures, ni de la connectivité
      Donc ce n’est pas surprenant que la sécurité passe aussi à la trappe
    • Les trois organisations « sérieuses » que je connais utilisent Mongo pour éviter de concevoir un schéma
      Cette attitude pousse à rechercher la commodité immédiate, et cela finit par mener à des problèmes de sécurité comme des instances de base de données publiques
    • Je trouve ces avis beaucoup trop extrêmes
      En pratique, il est courant d’utiliser SQL et NoSQL ensemble
      NoSQL est fort pour la haute disponibilité à grande échelle, et SQL est adapté au stockage de données relationnelles
      Par exemple, iMessage ou le système de matchmaking d’EA utilisent aussi du NoSQL
      Au final, on a besoin des deux. Ce ne sont pas des concurrents, mais des compléments
    • D’après les résultats de recherche Shodan, 2130 instances Mongo sont exposées
    • Exposer un serveur SQL aurait des conséquences encore plus graves
      Par exemple, PostgreSQL peut obtenir des privilèges sur l’ensemble du système avec la configuration par défaut
      C’est pourquoi la plupart des gens connaissent bien les risques d’un serveur SQL public
  • MongoDB a déclaré le 24 décembre qu’il n’y avait « aucune preuve d’exploitation du CVE », mais il ne faut pas oublier que « l’absence de preuve n’est pas la preuve de l’absence »
    • Dans ce cas, qu’auraient-ils dû dire selon toi ?
  • Je ne comprends pas pourquoi on utilise encore Mongo
    • La réplication est simple, et c’est plus rapide que le JSONB de Postgres
      Personnellement, je n’ai pas envie de l’utiliser, mais il existe des cas où DynamoDB ou MongoDB sont techniquement adaptés
    • Il y a aussi la blague selon laquelle on l’utilise parce que c’est « web scale »
      Vidéo liée
    • À une époque, NoSQL était à la mode, mais au final on a abouti à de simples bases key-value
    • C’est un raisonnement trop agressif pour être acceptable
  • Cela rappelle l’optimisme consistant à croire que l’OWASP Top 10 va résoudre les principales vulnérabilités
    Pourtant, les buffer overflows existent toujours depuis 2003
    • Au fond, on a mis un footgun dans les mains de tout le monde
      Ce genre de problème se répétera éternellement tant qu’on ne l’empêchera pas au niveau du langage
      Toutes mes condoléances aux développeurs de Mongo
  • Chaque fois qu’un article sur NoSQL est publié, on voit bien que beaucoup de « développeurs » n’ont jamais géré de trafic à grande échelle
    • Cette fois, j’ai surtout l’impression que c’est juste toi
  • MongoDB a toujours été médiocre… mais on l’a qualifié de « webscale »
    Je pense qu’il vaudrait mieux utiliser ToroDB ou le JSONB de PostgreSQL