Deux requêtes ping envoyées sans identifiants, puis une bascule de primaire au mauvais moment : voilà la recette décrite par Datadog pour faire tomber un serveur MongoDB. La faille, CVE-2026-118383, est notée 9,5 sur 10 en CVSS 4.0, et MongoDB a annoncé ses correctifs le 10 novembre.

Ce qui est touché

Il s’agit d’un use-after-free (le serveur réutilise de la mémoire déjà libérée), qui se produit dans le composant de réplication, quand un membre tout juste élu primaire termine son rattrapage, cette étape où il applique les écritures manquées avant d’accepter les nouvelles. Tous les membres d’un replica set sont concernés, y compris ceux des shards et des serveurs de configuration d’un cluster shardé. Un mongod autonome, hors replica set, ne l’est pas.

D’après The Hacker News, dans chaque branche corrigée, toutes les versions antérieures au correctif sont touchées, depuis la première de la branche. Les versions corrigées, selon Datadog :

• 9.0 : 9.0.7
• 8.3 : 8.3.16
• 8.0 : 8.0.37
• 7.0 : 7.0.48
• 6.0 : 6.0.30
• 5.0 : 5.0.35
• 4.4 : 4.4.32

La branche 8.2 n’apparaît pas dans la liste, et sa dernière version est la 8.2.12. Pourtant, une preuve de concept publiée sur GitHub affirme que cette version présentait encore le défaut lors d’un test en laboratoire, avec un paramètre réservé aux tests qu’un attaquant distant ne peut pas activer. Cette branche est en fin de vie depuis le 31 juillet : elle ne reçoit plus de correctifs, sécurité comprise.

Une gravité réelle plus nuancée que le score

L’avis de sécurité de MongoDB parle d’un arrêt inattendu du serveur ou, dans certaines conditions, d’une exécution de code arbitraire. Mais le scénario décrit par Datadog se joue en deux temps, et le second échappe à l’attaquant.

Première étape : l’attaquant envoie deux commandes ping portant une valeur readConcern.afterOpTime. Les serveurs vulnérables acceptent ping avant l’ouverture de session, et activer l’authentification n’y change rien. Chaque requête laisse en mémoire une notification en attente, un « waiter », qui n’expire pas. Elle reste jusqu’au redémarrage du membre, à un rollback ou à sa perte du rôle de primaire.

Seconde étape : il faut que ce membre gagne plus tard une élection alors qu’il est en retard sur un autre. L’attaquant ne peut provoquer ni le retard ni l’élection, ni voir quand ils surviennent ; une maintenance ou une panne peuvent y conduire. À la fin du rattrapage, le nettoyage s’exécute deux fois et le nouveau primaire plante avant d’accepter la moindre écriture. Une fois ces conditions réunies, selon Datadog, le plantage ne dépend d’aucune course de vitesse.

En laboratoire, les chercheurs ont eux-mêmes provoqué le retard et la bascule, avec un accès administrateur ; seules les deux requêtes venaient d’un client sans identifiants. Sur la version 8.0.34, le membre a planté (erreur de segmentation), laissant le cluster sans primaire ; un autre déploiement pourrait en élire un nouveau et poursuivre. Sur la 8.0.37, les deux requêtes sont rejetées immédiatement comme non autorisées et le membre continue de tourner. Les chercheurs n’ont pas obtenu d’exécution de code, et leurs résultats ne disent pas à quelle fréquence l’attaque réussirait ailleurs.

MongoDB dit avoir trouvé la faille en interne ; lors de son annonce, il n’avait connaissance d’aucune tentative d’exploitation. Côté score, la base d’avis de GitHub affiche 9,0, contre 9,5 pour MongoDB et la NVD.

Que faire maintenant

Installez la version corrigée de votre branche, ou un paquet de distributeur qui l’intègre, sur chaque membre du replica set. Vérifiez ensuite la version en service sur chacun, conteneurs et membres hors ligne pendant la maintenance compris. Les clusters Atlas sont mis à jour automatiquement lors de la maintenance, d’après MongoDB, qui demande à ceux qui la reportent d’appliquer la mise à jour sans tarder.

En attendant, limitez l’accès réseau à MongoDB aux seuls systèmes qui en ont besoin. Cela restreint qui peut envoyer les requêtes, sans corriger la faille. Le correctif a deux volets : seuls les utilisateurs système peuvent désormais employer readConcern.afterOpTime, et le nettoyage ne s’exécute plus deux fois même si des waiters sont déjà en place. Datadog n’a testé que le premier. Lors du test de la preuve de concept, sans authentification, la 8.0.37 acceptait les waiters mais ne nettoyait qu’une fois.

Pour chercher des traces, The Hacker News reprend trois signes relevés dans les journaux structurés du test de Datadog sur version vulnérable :

• une entrée COMMAND « Slow query » (ID 51803) pour un ping non authentifié avec readConcern.afterOpTime, terminé par MaxTimeMSExpired ;
• l’entrée d’un membre en rattrapage de primaire (ID 21359), suivie de deux sorties (ID 21363) dans la même transition ;
• un signal fatal ou une trace impliquant CatchupState::abort_inlock() après ces sorties.

Une élection normale ou une sortie de rattrapage unique ne trahit pas la faille. Les requêtes ayant pu précéder la bascule de loin, remontez aussi les journaux plus anciens du membre. Selon les réglages de journalisation, les champs de la requête peuvent ne pas être enregistrés, et attr.remote peut afficher une adresse de bouclage plutôt que celle du client.

Reste une question ouverte pour les équipes restées en 8.2 : aucun correctif n’est prévu pour une branche en fin de vie, et la preuve de concept laisse planer un doute que seule une migration vers une branche corrigée permet de lever.

Fiche technique

Données : NVD (NIST) et GitHub Advisory Database (CC BY 4.0, données adaptées).

Sources

• CVE-2026-118383 – GitHub Advisory Database, github.com
• Cloud Security Vulnerabilities, docs.datadoghq.com
• CVE-2026-118383: Use-after-free vulnerability in MongoDB, Datadog, 11 novembre 2026
• Critical Pre-Auth MongoDB Flaw (CVE-2026-118383) Can Crash Lagging Servers on Failover, The Hacker News, 12 novembre 2026
• GHSA-fjxh-6vgh-cx2c : A use-after-free in the replication component of MongoDB Server can occur when a newly…, GitHub Advisory Database (CC BY 4.0)
• CVE-2026-118383, NVD (NIST)