La vulnérabilité MongoBleed en cours d'exploitation par des cybercriminels touche à toutes les versions de MongoDB depuis 2017

Et donne l'accès à plus de 80 000 serveurs sur le web public

La vulnérabilité MongoBleed en cours d’exploitation par des cybercriminels touche à toutes les versions de MongoDB depuis 2017
Et donne l’accès à plus de 80 000 serveurs sur le web public

MongoBleed, référencée sous le numéro CVE-2025-14847, est une vulnérabilité de fuite de mémoire très grave dans MongoDB, révélée pour la première fois en décembre 2024 et en cours d’exploitation par des acteurs malveillants. Semblable à la célèbre faille dénommeé Heartbleed, elle permet aux pirates d'extraire à distance des informations sensibles de la mémoire d'un serveur sans authentification. La vulnérabilité affecte toutes les versions de MongoDB depuis 2017et donne l’accès à plus de 80 000 serveurs sur le web public.

MongoBleed entre dans le lot des anomalies qui se produisent lorsqu'un programme, lors de la lecture de données à partir d'un tampon, dépasse les limites du tampon et lit (ou tente de lire) la mémoire adjacente.

Les clients peuvent envoyer des requêtes compressées à MongoDB. Le client inclut la taille non compressée du message afin que le serveur sache exactement combien de mémoire allouer lors de la décompression.

Le serveur alloue un tampon mémoire avec l'espace donné. En raison du fonctionnement de la gestion de la mémoire et du ramasse-miettes dans les programmes, cette mémoire allouée peut déjà contenir des informations sensibles qui ont été copiées précédemment et qui sont désormais considérées comme des déchets (par exemple parce qu'elles ne sont pas référencées).

Techniquement, cela ne pose pas de problème : tous les programmes informatiques fonctionnent de cette manière, car on part du principe que toute mémoire non réclamée sera écrasée. Malheureusement, c'est précisément là que réside la vulnérabilité.

Le serveur fait confiance à la taille non compressée fournie par le client. Lorsqu'un client malveillant ment sur la taille non compressée (par exemple, la taille réelle décompressée est de 100 octets, mais le client indique qu'elle est de 1 Mo), Mongo traite le bloc complet de 1 Mo comme le message.

Il déchargera le message décompressé de 100 octets dans la mémoire tampon, mais traitera le bloc entier de 1 Mo comme le message. Cela pose un problème majeur si vous parvenez à obtenir du serveur qu'il renvoie des parties du bloc de 1 Mo, car celles-ci pourraient contenir des données auxquelles vous n'avez pas accès.

C'est exactement ce que fait l'exploit disponible: il envoie un message BSON mal formaté. Le serveur ne parvient pas à l'analyser et renvoie donc un message d'erreur contenant le message invalide. Le message invalide peut être l'intégralité du bloc de 1 Mo de données étrangères.


Selon la plateforme Censys, qui permet de détecter les appareils connectés à Internet, au 27 décembre, plus de 87 000 instances MongoDB potentiellement vulnérables étaient exposées sur l'Internet public. Près de 20 000 serveurs MongoDB ont été observés aux États-Unis, suivis par la Chine avec près de 17 000 et l'Allemagne avec un peu moins de 8000.

L'impact sur l'environnement cloud semble également être significatif, car les données télémétriques de la plateforme de sécurité cloud Wiz ont montré que 42 % des systèmes visibles « ont au moins une instance de MongoDB dans une version vulnérable à CVE-2025-14847 ».

Les chercheurs de Wiz notent que les instances qu'ils ont observées comprenaient à la fois des ressources internes et des ressources exposées publiquement. La société affirme avoir observé l'exploitation de MongoBleed (CVE-2025-14847) par des tiers malveillants et recommande aux organisations de donner la priorité à l'application de correctifs.

Eric Capuano, cofondateur de Recon InfoSec, avertit que l'application de correctifs n'est qu'une partie de la réponse au problème MongoBleed et conseille aux organisations de vérifier également s'il y a des signes de compromission.

Dans un récent article de blog publié, le chercheur explique une méthode de détection qui consiste à rechercher « une adresse IP source avec des centaines ou des milliers de connexions, mais aucun événement de métadonnées ».

Cependant, Capuano prévient que la détection est basée sur le code d'exploitation de preuve de concept actuellement disponible et qu'un attaquant pourrait le modifier pour inclure de fausses métadonnées client ou réduire la vitesse d'exploitation.

MongoDB indique qu'il n'existe aucune solution pour contourner cette vulnérabilité. Si la migration vers une nouvelle version n'est pas possible, le fournisseur recommande à ses clients de désactiver la compression zlib sur le serveur et fournit des instructions pour ce faire.

Parmi les alternatives sûres pour la compression de données sans perte, on peut citer Zstandard (zstd) et Snappy (anciennement Zippy), gérées respectivement par Meta et Google.

Sources : Wiz

Et vous ?

Avez-vous eu connaissance de cette vulnérabilité ? Quelles dispositions avez-vous prises au niveau de votre entreprise ?

Voir aussi :

11 millions d'enregistrements de courriers électroniques exposés dans une base de données MongoDB, selon un chercheur en cybersécurité.
MongoDB : comment éviter les attaques qui prennent en otage vos données ? Un billet de l'entreprise pour essayer d'endiguer ce phénomène.
Une violation de données coûterait environ 3,86 millions $ US par entreprise et par an, selon une étude de Ponemon Institute pour IBM Security