Réplicas MongoDB : une utilisation après libération avant authentification peut faire planter les serveurs (CVE-2026-118383)

Ce qui s'est passé

Le 10 novembre 2026, MongoDB a divulgué la CVE-2026-118383, une utilisation après libération dans le composant de réplication de MongoDB Server. Elle est notée 9.0 selon CVSS. La faille peut se produire lorsqu'un primaire de réplica set nouvellement élu termine sa phase de rattrapage. Des requêtes ne nécessitant aucune authentification peuvent la déclencher. Le processus serveur peut alors s'arrêter de manière inattendue. Dans certaines conditions, elle peut également conduire à l'exécution arbitraire de code dans le contexte du processus serveur.

Selon The Hacker News, le risque concerne un membre de réplica set qui a pris du retard puis devient primaire, par exemple lors d'un basculement. MongoDB a publié des correctifs. Cette vulnérabilité ne figure pas dans le catalogue des vulnérabilités exploitées connues de la CISA, et aucune des sources ne signale d'attaque.

Qui est concerné

• Concernés : les processus mongod qui fonctionnent en tant que membres d'un réplica set. Cela inclut les réplicas de shards et les réplicas de serveurs de configuration des clusters shardés.
• Non concernés : les instances mongod autonomes qui ne font pas partie d'un réplica set.

La faille peut être déclenchée avant l'authentification : activer l'authentification ne vous protège donc pas. Le risque est maximal pour les membres de réplica set accessibles depuis des réseaux non fiables ou depuis de nombreux serveurs d'application.

Que faire maintenant

1. Listez vos membres de réplica set. Sur chaque serveur MongoDB, vérifiez si mongod fonctionne dans le cadre d'un réplica set (voir la section suivante). Les instances autonomes ne nécessitent pas d'action urgente pour cette CVE.
2. Identifiez la version corrigée de votre série. Le ticket MongoDB SERVER-138119 (lien ci-dessous) fait partie du correctif. Il indique les versions corrigées 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 et 4.4.32. Comparez-le avec SERVER-138175 pour confirmer la version de votre série.
3. Sauvegardez votre configuration. Enregistrez /etc/mongod.conf (ou son équivalent) et assurez-vous qu'une sauvegarde récente de vos données existe.
4. Mettez à jour un membre à la fois. Commencez par les secondaires. Mettez à jour le paquet (par exemple apt install mongodb-org ou dnf update mongodb-org), redémarrez mongod, et attendez que le membre affiche de nouveau SECONDARY dans rs.status(). Exécutez ensuite rs.stepDown() sur le primaire et mettez-le à jour en dernier. Dans les clusters shardés, mettez à jour le réplica set des serveurs de configuration ainsi que chaque réplica set de shard.
5. Limitez l'accès réseau. Le port 27017 (ou votre port personnalisé) ne doit être accessible que depuis les serveurs d'application et les autres membres du cluster. Utilisez votre pare-feu ou bindIp pour l'imposer, dès maintenant comme après la mise à jour.
6. Surveillez les plantages. Vérifiez les journaux de mongod et votre supervision de services pour détecter des redémarrages inattendus, en particulier lors des élections et des basculements.

Comment vérifier si vous êtes concerné

• Vérifiez la version avec mongod --version, ou dans mongosh avec db.version().
• Vérifiez l'appartenance à un réplica set dans mongosh avec db.hello().setName. Si un nom est renvoyé, l'instance est membre d'un réplica set et est concernée tant qu'elle n'est pas mise à jour. Si rien n'est renvoyé et que rs.status() indique que l'instance ne fonctionne pas avec la réplication, il s'agit d'une instance autonome et elle n'est pas concernée.
• Pour les clusters shardés, effectuez la vérification sur chaque membre de shard et chaque membre de serveur de configuration.
• Si un membre utilise une version antérieure à la version corrigée de sa série, mettez-le à jour.

Sources

• https://nvd.nist.gov/vuln/detail/CVE-2026-118383
• https://jira.mongodb.org/browse/SERVER-138119