MongoDB : faille critique CVE-2026-118383 (CVSS 9,5) exploitable sans authentification sur les replica sets, passez en 8.0.37, 7.0.48 ou 9.0.7

Sources : alertes de sécurité MongoDB (bulletin du 10 novembre 2026) ; notes de version de MongoDB 8.0 ; tickets SERVER-138119 et SERVER-134872.

MongoDB a publié le 10 novembre 2026 son bulletin mensuel de sécurité : 26 vulnérabilités corrigées dans MongoDB Server, la base de données NoSQL orientée documents. La plus grave, CVE-2026-118383, reçoit un score CVSS 4.0 de 9,5 sur 10. C'est un use-after-free dans le composant de réplication, déclenchable sans authentification par le réseau au moment où un primaire fraîchement élu termine son rattrapage. Il peut faire planter le processus mongod et, dans certaines conditions, permettre l'exécution de code. Toutes les branches maintenues ou non sont touchées, de la 4.4 à la 9.0, mais uniquement les membres d'un replica set : une instance autonome n'est pas concernée.

Le même lot corrige trois autres failles qui mènent aux droits d'administration complets d'un cluster : une exception localhost qui reste ouverte, une vérification de certificat X.509 contournable et un administrateur de shard capable de se fabriquer un compte root. Cet article explique qui est exposé, comment vérifier la version de votre serveur MongoDB, comment mettre à jour depuis le dépôt officiel ou par l'image Docker, comment redémarrer un replica set membre par membre sans coupure, et quoi durcir si vous ne pouvez pas patcher tout de suite. Si votre base tourne sur un VPS, commencez par vérifier que le port 27017 n'est pas ouvert sur Internet : notre guide gérer les ports avec UFW sur Linux montre comment les lister et les fermer.

Le bulletin du 10 novembre : 26 CVE, dont quatre qui mènent à root

Le bulletin accompagne la sortie de MongoDB 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 et 4.4.32. Selon les notes de version, la 9.0.7 corrige 25 CVE, la 8.0.37 en corrige 19 et la 7.0.48 en corrige 16 : plus la branche est récente, plus elle contient de code touché. Les autres failles touchent l'agrégation, les collections time-series, le cache de plans ou le chiffrement côté client, ou provoquent des dénis de service ; plusieurs sont explicitement qualifiées de post-authentification. Les quatre ci-dessous sont celles qui changent la priorité pour un administrateur, parce qu'elles débouchent sur un contrôle total de la base de données.

À notre connaissance, aucune exploitation de ces vulnérabilités n'a été signalée publiquement au 12 novembre 2026. Mais les tickets Jira des correctifs sont désormais publics, ce qui donne des pistes à quiconque cherche à reproduire ces failles : n'attendez pas une alerte d'exploitation pour mettre à jour.

CVE-2026-118383 : un use-after-free au rattrapage du primaire

Dans un replica set MongoDB, un seul membre, le primaire, accepte les écritures. Les secondaires rejouent son journal d'opérations (l'oplog). Quand le primaire tombe ou se retire, les membres votent : c'est l'élection. Le nouveau primaire passe ensuite par une phase de catch-up (rattrapage) pendant laquelle il récupère les dernières entrées d'oplog que d'autres membres auraient reçues avant lui. C'est à la fin de cette phase que se situe la faille : une zone mémoire libérée y est réutilisée, et des requêtes qui ne demandent aucune authentification suffisent à la déclencher.

La fiche CVE précise les points qui comptent pour évaluer votre exposition :

• Membres concernés : tous les membres d'un replica set, y compris les membres des shards et des serveurs de configuration d'un cluster shardé. Un mongod autonome, sans replSetName, n'est pas vulnérable ;
• Effet : au minimum un plantage du serveur, donc une nouvelle élection ; dans certaines conditions, une exécution de code avec les droits du processus mongod ;
• Complexité : le vecteur CVSS indique une complexité d'attaque élevée (AC:H), car il faut viser le bon moment, mais aucun privilège ni aucune interaction de l'utilisateur. Le score CVSS 3.1 est de 9,0 ;
• Correctifs : la fiche renvoie à deux tickets, SERVER-138119 (« Allow only system users to use readConcern afterOpTime », qui réserve une option de lecture interne aux utilisateurs système) et SERVER-138175 (correction du use-after-free dans l'abandon de l'état de rattrapage).

Ce scénario concerne précisément les installations qui ont fait le choix de la haute disponibilité : trois membres sur trois VPS ou serveurs dédiés, un bot ou un panel qui écrit dans un replica set, une application qui exige les transactions multi-documents (elles imposent un replica set). Et une élection n'a rien d'exceptionnel : elle a lieu à chaque redémarrage ou arrêt du primaire, à chaque coupure réseau entre les membres et à chaque opération de maintenance.

Versions corrigées, paquets et images Docker

Chaque branche a sa version corrective. Le même jour, MongoDB a aussi publié 8.0.38 et 9.0.8 : leurs notes de version ne listent qu'un correctif de compilation (SERVER-138547) et fournissent les binaires des architectures s390x et ppc64le absents de la 8.0.37 et de la 9.0.7. Ce sont des versions ultérieures de la même branche : elles contiennent les correctifs de sécurité. Le dépôt repo.mongodb.org propose déjà la 8.0.38 pour Ubuntu 24.04 : c'est donc elle qu'apt installera sur cette distribution. L'image Docker officielle mongo, elle, a sauté la 8.0.37 et la 9.0.7.

Les branches 6.0 et 5.0 ont bien reçu leurs paquets dans repo.mongodb.org (6.0.30 pour Ubuntu 22.04, 5.0.35 pour Ubuntu 20.04), mais elles ont dépassé leur fin de vie : appliquez le correctif, puis planifiez la migration vers 7.0 ou 8.0. Une montée de version majeure se fait une branche à la fois et demande de passer le featureCompatibilityVersion (FCV) à chaque étape ; ce n'est pas une opération à improviser en urgence.

Les trois autres failles qui donnent les droits root

CVE-2026-120815 : l'exception localhost qui ne se referme pas

Quand l'authentification est activée et qu'aucun utilisateur n'existe encore, MongoDB applique l'exception localhost : un client connecté par l'interface locale peut créer le premier utilisateur ou le premier rôle, sans s'authentifier. Elle doit se refermer dès ce premier compte. Le ticket SERVER-134872 explique que c'est bien le cas quand ce compte est créé dans la base admin, mais pas quand il est créé dans $external, la base virtuelle des comptes authentifiés par un mécanisme externe (certificat X.509, LDAP, Kerberos). Dans ce cas, l'exception reste ouverte et un client non authentifié peut encore créer des utilisateurs, auxquels il peut attribuer le rôle root.

Le vecteur est local (AV:L) : il faut pouvoir ouvrir une connexion vers mongod depuis la machine elle-même. Cela vise un compte shell peu privilégié, une application compromise sur le même serveur, ou un conteneur qui partage le réseau de l'hôte. Les branches 7.0 à 9.0 sont concernées.

CVE-2026-120807 : le garde-fou X.509 des membres du cluster

Avec l'authentification interne par certificats X.509, un garde-fou empêche le certificat d'un membre du cluster d'être aussi traité comme un utilisateur ordinaire. Selon la fiche CVE, ce contrôle ne distingue pas correctement certaines erreurs survenues pendant la recherche de l'utilisateur et, dans certaines conditions de timing, il peut être contourné pour obtenir les privilèges internes complets du système. Il faut déjà détenir un certificat de membre valide et utiliser une configuration X.509 de cluster qui n'est pas celle par défaut : l'exposition est réelle mais étroite.

CVE-2026-120814 : un administrateur de shard qui se crée un root persistant

Dans le sous-système de sharding, un utilisateur disposant de certains privilèges d'administration au niveau d'un shard peut faire rejouer un état de coordination interne déjà enregistré, que le serveur traite alors avec une autorité interne élevée sans le revalider. Le titre de l'alerte résume la conséquence : la création d'un utilisateur root persistant pour tout le cluster. L'attaque demande une session authentifiée directement sur un membre du cluster, et seules les branches 8.0, 8.3 et 9.0 sont touchées. Elle concerne surtout les hébergements où plusieurs équipes se partagent un cluster shardé.

Vérifier la version de votre serveur MongoDB

Le binaire installé et le processus qui tourne ne sont pas forcément à la même version : tant que le service n'a pas redémarré, l'ancien mongod reste en mémoire. Vérifiez donc les deux.

Version du binaire présent sur le disque :

mongod --version

Version du serveur réellement en cours d'exécution, depuis le shell mongosh (ajoutez vos identifiants si l'authentification est activée) :

mongosh --quiet --eval 'db.version()'
mongosh "mongodb://admin@127.0.0.1:27017/?authSource=admin" --quiet --eval 'db.version()'

Pour un replica set, listez les membres et leur état, puis répétez la vérification sur chacun d'eux :

mongosh --quiet --eval 'rs.status().members.forEach(m => print(m.name, m.stateStr))'

Avec Docker, regardez le tag de l'image et la version embarquée. Un tag flottant comme mongo:8.0 ou mongo:latest ne garantit rien tant que l'image n'a pas été retéléchargée :

docker ps --format 'table {{.Names}}\t{{.Image}}'
docker exec nom-du-conteneur mongod --version
docker compose images

Mettre à jour depuis repo.mongodb.org

Avant toute chose : une sauvegarde récente (mongodump ou instantané du volume), et une vérification du FCV sur chaque membre. La documentation de MongoDB prévient qu'un nœud redémarré avec un binaire plus récent alors que la précédente montée de FCV n'est pas terminée peut planter.

mongosh --quiet --eval 'db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 })'

Debian et Ubuntu (apt)

Le fichier /etc/apt/sources.list.d/mongodb-org-X.Y.list pointe vers une seule branche (par exemple mongodb-org/8.0) : une mise à jour reste donc dans votre branche. Si vous aviez bloqué les paquets avec hold, comme le propose la documentation d'installation, levez le blocage le temps de l'opération :

sudo apt update
apt list --upgradable 2>/dev/null | grep mongodb
sudo apt-mark unhold mongodb-org mongodb-org-database mongodb-org-server mongodb-mongosh mongodb-org-mongos mongodb-org-tools
sudo apt install --only-upgrade mongodb-org mongodb-org-database mongodb-org-server mongodb-org-mongos mongodb-org-tools
sudo apt-mark hold mongodb-org mongodb-org-database mongodb-org-server mongodb-mongosh mongodb-org-mongos mongodb-org-tools

L'option --only-upgrade met à jour les paquets déjà installés et ignore les autres. Nommer les composants un par un est indispensable : le méta-paquet mongodb-org seul ne force pas la version de mongodb-org-server, qui contient le binaire mongod.

AlmaLinux et Rocky Linux (dnf)

Le dépôt est déclaré dans /etc/yum.repos.d/mongodb-org-X.Y.repo, avec une branche par fichier. Si vous avez ajouté la ligne exclude=mongodb-org,... recommandée pour éviter les mises à jour involontaires, commentez-la le temps de la commande, puis remettez-la :

sudo dnf check-update 'mongodb-org*'
sudo dnf upgrade 'mongodb-org*'

Sur un serveur autonome, il reste à redémarrer le service et à contrôler la version :

sudo systemctl restart mongod
systemctl status mongod
mongosh --quiet --eval 'db.version()'

Image Docker

Remplacez le tag par une version explicite corrigée, puis recréez le conteneur. Avec Docker Compose :

# docker-compose.yml
services:
  mongo:
    image: mongo:8.0.38    # ou 7.0.48, 8.3.17, 9.0.8 selon votre branche

docker compose pull mongo
docker compose up -d mongo
docker compose exec mongo mongod --version

Les données vivent dans le volume monté sur /data/db et survivent à la recréation du conteneur. Pour un replica set en conteneurs, appliquez la procédure ci-dessous en recréant un service à la fois. Notre guide Docker Compose sur VPS Linux détaille la gestion des volumes et des mises à jour d'images.

Redémarrer un replica set membre par membre

La procédure officielle de mise à jour d'une version corrective est un redémarrage tournant : les secondaires d'abord, le primaire en dernier. Elle a ici un intérêt supplémentaire : quand vous retirez le primaire, l'élection désigne un secondaire déjà corrigé, et c'est donc un membre patché qui traverse la phase de rattrapage visée par CVE-2026-118383.

1. Repérez le primaire avec la commande rs.status() vue plus haut.
2. Sur chaque secondaire, un à la fois : mettez à jour les paquets ou l'image, redémarrez mongod, puis attendez que rs.status() l'affiche de nouveau en SECONDARY. Un passage bref par STARTUP2 ou RECOVERING est normal. Ne touchez pas au membre suivant avant.
3. Sur le primaire, demandez-lui de céder sa place plutôt que de l'arrêter brutalement :

   mongosh --quiet --eval 'rs.stepDown()'

   Pendant la bascule, le replica set n'accepte pas d'écritures, en général pendant 10 à 20 secondes selon la documentation : prévenez vos applications ou choisissez une heure creuse.
4. Vérifiez qu'un autre membre est PRIMARY, puis mettez à jour et redémarrez l'ancien primaire, qui revient en secondaire.
5. Contrôlez db.version() sur les trois membres.

Sur un cluster shardé, l'ordre est imposé : désactivez le balancer (sh.stopBalancer()), mettez à jour le replica set des serveurs de configuration, puis chaque shard avec la même procédure, puis les routeurs mongos, et réactivez le balancer (sh.startBalancer()). Tous les membres doivent être démarrés avant de commencer.

En attendant la mise à jour : fermer, authentifier, contrôler

Ne jamais exposer le port 27017 sur Internet

CVE-2026-118383 demande un accès réseau à mongod. Par défaut, les paquets officiels écoutent sur 127.0.0.1 ; pour un replica set, on ajoute l'adresse privée de chaque membre dans /etc/mongod.conf, jamais 0.0.0.0 sans pare-feu :

net:
  port: 27017
  bindIp: 127.0.0.1,10.0.0.11

Doublez ce réglage par une règle de pare-feu qui n'autorise que les autres membres et les serveurs d'application. Avec UFW, la politique entrante par défaut étant deny, supprimez toute ouverture générale et autorisez seulement le réseau privé :

sudo ufw delete allow 27017/tcp
sudo ufw allow from 10.0.0.0/24 to any port 27017 proto tcp
sudo ufw status numbered

Avec nftables, dans la chaîne input de /etc/nftables.conf, avant toute règle d'acceptation générale :

tcp dport 27017 ip saddr 10.0.0.0/24 accept
tcp dport 27017 drop

Piège classique : un port publié par Docker (-p 27017:27017) contourne les règles UFW, comme le rappelle la documentation de Docker. Publiez sur une adresse précise (-p 127.0.0.1:27017:27017 ou l'adresse privée), ou ne publiez rien et reliez vos conteneurs par un réseau Docker interne. Pour relier des membres répartis chez plusieurs hébergeurs sans ouvrir de port public, un réseau privé chiffré fait l'affaire : voir Tailscale sur VPS Linux et, pour les règles en détail, nftables comme pare-feu de serveur.

Activer l'authentification avec un keyFile entre les membres

Soyons clairs : l'authentification ne bloque pas CVE-2026-118383, qui se déclenche avant toute authentification. Elle reste indispensable contre le reste du bulletin et contre le premier venu, car un replica set sans contrôle d'accès accepte n'importe quel client. Le keyFile est une clé partagée qui authentifie les membres entre eux et active du même coup le contrôle d'accès par rôles pour les clients. Générez-la une fois et copiez le même fichier sur chaque membre :

openssl rand -base64 756 | sudo tee /etc/mongodb-keyfile > /dev/null
sudo chmod 400 /etc/mongodb-keyfile
sudo chown mongodb:mongodb /etc/mongodb-keyfile   # Debian et Ubuntu
sudo chown mongod:mongod /etc/mongodb-keyfile     # AlmaLinux et Rocky Linux

security:
  keyFile: /etc/mongodb-keyfile
replication:
  replSetName: rs0

Le fichier doit appartenir à l'utilisateur qui exécute mongod et n'avoir aucun droit pour le groupe ni pour les autres. Sur un replica set déjà en production sans authentification, suivez la procédure dédiée de la documentation (création d'un administrateur, puis bascule avec transitionToAuth si vous ne voulez pas de coupure). Pour la production, MongoDB recommande les certificats X.509 plutôt que le keyFile.

Contre CVE-2026-120815, une fois vos comptes créés, vous pouvez fermer définitivement l'exception localhost au démarrage (paramètre disponible sur mongod uniquement) :

setParameter:
  enableLocalhostAuthBypass: false

Vérifier qu'aucun utilisateur root inconnu n'a été créé

Les failles 120815 et 120814 ont le même résultat : un compte privilégié que vous n'avez pas créé. Listez les utilisateurs de la base admin, puis ceux de toutes les bases, car getUsers() ne couvre que la base courante et ne montre pas les comptes de $external :

db.getSiblingDB('admin').getUsers()
db.getSiblingDB('admin').runCommand({ usersInfo: { forAllDBs: true } }).users.forEach(u => print(u.db, u.user, JSON.stringify(u.roles)))

Cherchez les rôles root, userAdminAnyDatabase, clusterAdmin et __system attribués à un compte que vous ne reconnaissez pas, ainsi que tout utilisateur inattendu dans $external. En cas de doute : supprimez le compte, changez les mots de passe et le keyFile, et examinez les journaux du serveur. Notre guide auditd sur VPS Linux aide à retracer qui a fait quoi sur la machine.

Lexique : les termes de la réplication MongoDB

En résumé

Si votre MongoDB tourne en replica set, en cluster shardé ou derrière une application qui exige des transactions, mettez à jour cette semaine : 9.0.7, 8.3.16, 8.0.37, 7.0.48 ou plus récent selon votre branche (8.0.38, 9.0.8 et 8.3.17 pour les images Docker), secondaires d'abord puis rs.stepDown() sur le primaire. En attendant, le port 27017 ne doit répondre qu'au réseau privé, l'authentification doit être active entre les membres, et la liste des utilisateurs doit être contrôlée. Les branches 6.0, 5.0 et 4.4 reçoivent un correctif, mais leur fin de vie est dépassée : c'est le moment de planifier la migration. Pour séparer proprement une base de données de vos serveurs de jeu ou de vos bots, un VPS Linux par membre ou un serveur dédié avec un réseau privé restent les architectures les plus simples à protéger.