MongoBleed : une faille MongoDB exploitée pendant les fêtes
Une faille de la base de données MongoDB permet de lire la mémoire du serveur sans mot de passe. Corrigée le 19 décembre, elle est exploitée depuis Noël. Ce qu'il faut vérifier avant la reprise.
Pendant que beaucoup d'équipes informatiques étaient en congés, une faille sérieuse s'est transformée en attaque active. Baptisée « MongoBleed » (CVE-2025-14847), elle touche MongoDB, une base de données très répandue dans les applications web et mobiles. Elle permet à un attaquant, sans aucun identifiant, de lire des morceaux de la mémoire du serveur, où peuvent se trouver des mots de passe, des clés d'accès ou des données clients. MongoDB a publié les correctifs le 19 décembre ; un code d'exploitation public est apparu le 26 ; l'agence américaine de cybersécurité CISA a confirmé une exploitation active le 29. Si une de vos applications utilise MongoDB, c'est à vérifier avant la reprise.
Ce qui s'est passé
MongoDB peut compresser les échanges entre l'application et la base de données, notamment avec l'algorithme zlib. La faille vient d'une erreur dans le traitement de messages compressés : en envoyant un message malformé, un attaquant obtient en retour des fragments de mémoire du serveur qui ne lui étaient pas destinés. Le nom fait référence à « Heartbleed », une faille célèbre de 2014 qui fonctionnait sur le même principe.
La chronologie, d'après la presse spécialisée :
- l'équipe de sécurité de MongoDB a repéré le problème mi-décembre ;
- le 19 décembre, MongoDB a publié une alerte et des versions corrigées ;
- le 26 décembre, un chercheur a publié un code de démonstration permettant d'exploiter la faille ;
- le 29 décembre, la CISA a ajouté la faille à son catalogue des vulnérabilités activement exploitées ;
- un scan de l'organisation Shadowserver a relevé 74 854 serveurs vulnérables et non corrigés sur 78 725 instances MongoDB exposées sur Internet.
Qui est concerné
- Concernés : les serveurs MongoDB installés et gérés par vous ou votre prestataire (« auto-hébergés »), dans les versions 4.4 à 8.2 non mises à jour, ainsi que les anciennes versions 4.2, 4.0 et 3.6, qui ne recevront pas de correctif. Les versions corrigées sont 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 et 4.4.30.
- Le risque est maximal si le port de la base de données est accessible depuis Internet, ce qui ne devrait jamais être le cas, mais l'est manifestement pour des dizaines de milliers de serveurs.
- Moins concernés : les clients de MongoDB Atlas, le service géré par l'éditeur, dont les serveurs ont été corrigés par MongoDB.
Ce que ça change pour une PME
Vous n'avez sans doute jamais choisi MongoDB vous-même. Mais si une application, une plateforme de réservation, un back-office ou un site e-commerce a été développé pour vous ces dernières années, il y a une chance qu'il l'utilise. Le risque concret :
- des identifiants (mots de passe de comptes, clés d'API de paiement ou d'envoi d'e-mails) lus dans la mémoire et réutilisés ;
- des données personnelles de clients exposées, avec ce que cela implique au titre du RGPD si une fuite est avérée ;
- une faille qui passe inaperçue : lire la mémoire ne laisse pas toujours de trace évidente.
Ce qu'il faut demander, cette semaine
- Nos applications utilisent-elles MongoDB, et dans quelle version ? La réponse doit être immédiate pour un projet maintenu.
- La mise à jour a-t-elle été appliquée ? Si ce n'est pas possible tout de suite, MongoDB recommande de désactiver la compression zlib en attendant.
- Le port de la base est-il fermé à Internet ? Une base de données ne doit être joignable que par l'application qui l'utilise. C'est la règle qui aurait évité la plupart des expositions.
- Faut-il changer des secrets ? Si un serveur exposé n'était pas corrigé après le 26 décembre, les mots de passe et clés qu'il manipulait doivent être considérés comme compromis.
- Faut-il prévenir ? Si des données personnelles ont pu fuiter, le RGPD impose d'évaluer la notification à la CNIL dans les 72 heures après en avoir pris connaissance.
Pour les applications qui passent par MongoDB Atlas, le service géré par l'éditeur, le correctif a été appliqué par MongoDB. Reste à vérifier deux choses côté application : que les accès à la base sont limités aux adresses qui en ont besoin, et que les identifiants de connexion ne sont pas partagés entre plusieurs outils ou plusieurs personnes.
Ce que montre cette fin d'année
En un mois, nous avons parlé ici d'une attaque contre les bibliothèques JavaScript, d'une faille critique dans React, d'une intrusion par mots de passe partagés et d'une attaque par saturation contre La Poste. Le point commun n'est pas la technique. C'est que, dans chaque cas, ceux qui s'en sont sortis le mieux avaient trois choses : un inventaire de ce qu'ils utilisent, quelqu'un qui surveille les alertes, et des systèmes qui n'exposent sur Internet que le strict nécessaire.
C'est ce que nous mettons dans la maintenance des logiciels que nous livrons, avec un hébergement en France et des bases de données jamais exposées directement. Si vous n'êtes pas sûr de la réponse aux questions ci-dessus pour vos propres outils, commençons l'année par un rendez-vous de 30 minutes. Bonne année à tous.