Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt

Use this file to discover all available pages before exploring further.

Publié le 1 décembre 2025
CVE-2025-14847 — surnommée “MongoBleed”. Pré-authentification, déclenchable depuis Internet, du PoC public en circulation. Toute instance MongoDB exposée sans patch est à considérer comme compromise jusqu’à preuve du contraire.

L’essentiel

Le décompresseur zlib intégré au transport réseau de MongoDB ne valide pas correctement la taille du payload après décompression. Lorsqu’un client annonce une trame compressée plus petite que le buffer alloué côté serveur, le serveur renvoie ce buffer sans le réinitialiser : il y reste des octets aléatoires de la heap, c’est-à-dire des morceaux de la RAM utilisée par d’autres requêtes. L’attaquant n’a besoin d’aucun compte — la compression se négocie pendant le handshake, avant l’authentification. Il lui suffit de répéter l’opération pour collecter, requête après requête, des bouts de mémoire.

Ce qu’on y trouve, en pratique

Les chercheurs qui ont étudié la faille rapportent dans les fragments fuités :
  • des credentials de bases en clair,
  • des clés d’API d’administration,
  • des variables d’environnement,
  • des fragments de documents BSON appartenant à d’autres utilisateurs.
Autrement dit, une fenêtre semi-aléatoire mais répétable sur la RAM du process mongod.

Êtes-vous exposé ?

Si votre instance MongoDB :
  • accepte des connexions depuis Internet, ou
  • accepte des connexions depuis un réseau partagé (LAN cloud, VPC multi-tenant), ou
  • est en frontal d’une application qui en relaie les erreurs détaillées,
…considérez l’exposition comme critique. Un PoC public circule, l’exploitation in-the-wild est confirmée.

Correctifs à appliquer

Mettez à jour vers (au minimum) la version corrigée de votre branche :
Branche MongoDBVersion corrigée minimale
8.28.2.3
8.08.0.17
7.07.0.28
6.06.0.27
5.05.0.32
4.44.4.30

Mitigation temporaire

Si le redémarrage avec patch n’est pas possible immédiatement :
# Forcer la liste des compresseurs négociables hors zlib
mongod --networkMessageCompressors=snappy,zstd
Ou dans mongod.conf :
net:
  compression:
    compressors: snappy,zstd
Et dans tous les cas, tant que vous ne pouvez pas patcher : restreindre l’accès au port 27017 au strict nécessaire, via firewall ou Security Group.

Vérifier la version

mongosh --eval "db.version()"
Comparez le résultat à la table de versions corrigées plus haut.

Et après

Une fois patché, partez du principe que les credentials qui ont pu transiter par cette instance avant le patch sont compromis : faites tourner les mots de passe, régénérez les API keys, auditez les logs d’accès. Pour toute question, ouvrez un ticket depuis votre espace client OnetSolutions.