> ## 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.

# MongoBleed (CVE-2025-14847) : fuite mémoire non authentifiée dans MongoDB

> Une faille de la couche réseau de MongoDB laisse fuir des fragments de RAM serveur — credentials, clés d'API, BSON — sans authentification.

*Publié le 1 décembre 2025*

<Warning>
  **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.
</Warning>

## 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 MongoDB | Version corrigée minimale |
| --------------- | ------------------------- |
| 8.2             | 8.2.3                     |
| 8.0             | 8.0.17                    |
| 7.0             | 7.0.28                    |
| 6.0             | 6.0.27                    |
| 5.0             | 5.0.32                    |
| 4.4             | 4.4.30                    |

## Mitigation temporaire

Si le redémarrage avec patch n'est pas possible immédiatement :

```bash theme={null}
# Forcer la liste des compresseurs négociables hors zlib
mongod --networkMessageCompressors=snappy,zstd
```

Ou dans `mongod.conf` :

```yaml theme={null}
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

```bash theme={null}
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](https://onetsolutions.net).