top of page
Rechercher

MongoBleed - Analyse du CVE-2025-14847

  • Photo du rédacteur: Loïc Castel
    Loïc Castel
  • 28 déc. 2025
  • 3 min de lecture

À peine l'écosystème remis de la secousse React2Shell, une nouvelle vulnérabilité critique frappe l'un des moteurs de base de données les plus populaires au monde. Surnommée MongoBleed, elle permet à un attaquant non authentifié d'extraire des données sensibles directement depuis la mémoire des serveurs MongoDB.



Sévérité : Élevée (Score CVSS : 8.7)

CVE associée : CVE-2025-14847

Cibles : Instances MongoDB avec compression zlib activée, notamment :

  • MongoDB 8.2.0 à 8.2.3

  • MongoDB 8.0.0 à 8.0.16

  • MongoDB 7.0.0 à 7.0.26

  • MongoDB 6.0.0 – 6.0.26

  • MongoDB 5.0.0 – 5.0.31

  • MongoDB 4.4.0 – 4.4.29

  • Toutes les versions plus anciennes ou égales à 4.2.0

Action requise : Patch immédiat ou désactivation temporaire de la compression zlib.


Pourquoi "MongoBleed" ?

Dévoilée autour du 25 décembre 2025, par un ingénieur de la société Elastic, Joe Desimone, cette faille a immédiatement hérité du surnom "MongoBleed" en référence à la célèbre vulnérabilité Heartbleed (2014).


Post de Kevin Beaumont annonçant MongoBleed
Post de Kevin Beaumont annonçant MongoBleed

Le parallèle est technique et fonctionnel : tout comme son ancêtre sur OpenSSL, MongoBleed permet à un attaquant de lire la mémoire du serveur (Heap memory) sans laisser de traces classiques dans les logs applicatifs. Ce n'est pas une intrusion bruyante, c'est une exfiltration discrète de données.


Root Cause Analysis - La compression zlib

Nos analystes et les chercheurs (notamment chez Aikido Security) ont identifié l'origine du problème dans la couche de transport réseau de MongoDB.


Le défaut réside dans l'implémentation de la compression zlib. Lorsqu'un paquet compressé malformé est envoyé au serveur, MongoDB échoue à valider correctement la longueur des données décompressées par rapport à la taille du buffer alloué, avant même l'authentification.


Vecteur d'attaque

Concrètement, l'exploitation se déroule ainsi :

  1. L'attaquant se connecte au port de la base de données (ex: 27017) sans s'authentifier.

  2. Il envoie une trame réseau spécifiquement forgée utilisant la compression zlib.

  3. Le serveur répond avec un paquet contenant des fragments de mémoire non initialisée.


Ces fragments de mémoire ("memory leaks") peuvent contenir tout ce qui transite par la RAM du serveur au même moment : identifiants administrateur, tokens de session, clés de chiffrement ou données clients.



Ce que nous observons sur le terrain

Les sondes Safercy détectent depuis 48h une activité intense de scanning ciblant spécifiquement le port 27017 avec des handshakes zlib.


Contrairement à React2Shell qui vise la prise de contrôle (RCE), les attaquants exploitant MongoBleed cherchent à exfiltrer massivement des données pour constituer des bases de "Leaked Credentials" ou pour préparer des attaques par rebond.


Un Proof of Concept a été publié et est accessible à travers le lien suivant :


Nos chercheurs ont créé une vidéo afin de reproduire l'exploitation de la vulnérabilité :

Vidéo reproduisant MongoBleed en local (utilisation d'un serveur mongoDB en version 4.4 en docker)

Point inquiétant : l'attaque est très rapide et peut être automatisée à grande échelle contre toute instance exposée sur internet.


Recommandations

Si vous gérez des clusters MongoDB (self-hosted), vérifiez immédiatement votre configuration. Les instances MongoDB Atlas (Cloud) ont déjà été patchées par l'éditeur.


1. Patching (Recommandé)

Mettez à jour vers les versions correctives publiées par MongoDB Inc. :

  • 8.2 -> passer en 8.2.4+

  • 8.0 -> passer en 8.0.17+

  • 7.0 -> passer en 7.0.27+

  • 6.0 -> passer en 6.0.27

  • 5.0 -> passer en 5.0.32

  • 4.4 -> passer en 4.4.30

  • Plus anciennes ou égales à 4.2 -> migrer vers une version plus récente


2. Solution de contournement (Immédiat)

Si la mise à jour n'est pas possible tout de suite, vous pouvez mitiger la faille en désactivant la compression zlib dans votre configuration mongod.conf :

net:  
  compression:
    compressors: snappy,zstd  # Retirez "zlib" de cette liste

Ou via la ligne de commande au lancement :

--networkMessageCompressors snappy,zstd

3. Hygiène réseau

Assurez-vous que vos bases de données ne sont jamais exposées directement sur internet (0.0.0.0/0). Utilisez des VPN ou des listes blanches d'IP (Allowlisting).


Conclusion

Le mot de l'expert Safercy :

"MongoBleed est typiquement le genre de vulnérabilité 'dormante' qui peut transformer une simple exposition réseau en fuite de données majeure. Ce n'est pas la complexité de l'attaque qui inquiète, mais sa furtivité : un attaquant peut récupérer vos clés d'API sans jamais avoir besoin de deviner un mot de passe. C'est un rappel brutal que la sécurité périmétrique (Firewall) reste cruciale, même en 2025. Attention spécifique aux instances mongoDB accessibles depuis les réseaux internes qui risquent d'être exploitées dans un second temps et devenir une source d'entrée pour les attaquants." — Loïc Castel, CTO @ Safercy

Besoin de vérifier vos instances ?

Si vous craignez qu'une exfiltration ait déjà eu lieu, notre équipe CSIRT peut vous accompagner dans la gestion de l'incident, la confirmation d'une exploitation et des potentiels actions de post-exploitation.

 
 
bottom of page