- 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
- Le responsable de l’équipe sécurité d’Elastic a donné le nom « MongoBleed » à la faille et publié un PoC (script Python)
- MongoDB et Elastic sont en concurrence dans le domaine des fonctions de recherche et d’analyse
- Ressources lié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
Aucun commentaire pour le moment.