Une faille MongoDB laisse fuiter des données sensibles des serveurs, y compris des mots de passe et des clés secrètes. Le danger est réel, d’autant plus que la faille existe depuis plus de huit ans et que des preuves de concept sont librement disponibles sur Internet. Des correctifs sont disponibles, à déployer au plus vite si ce n’est pas encore fait !

MongoDB est de nouveau victime d’une vilaine faille de sécurité, baptisée cette fois CVE-2025-14847. « De multiples vulnérabilités ont été découvertes dans MongoDB Server. Certaines d’entre elles permettent à un attaquant de provoquer un déni de service à distance, une atteinte à la confidentialité des données et une atteinte à l’intégrité des données », explique le CERT-FR.

Depuis 2017, il était possible de récupérer des données en mémoire

Le CERT Santé français donne quelques détails sur la faille et ses conséquences. Elle est exploitable par le réseau avec une complexité « faible » et ne nécessite aucun privilège, ce qui explique sa dangerosité. Dans tous les cas, elle ne permet pas d’obtenir des privilèges plus élevés, mais tout de même d’accéder à des « espaces mémoire non initialisés sans authentification ».

Cette vulnérabilité rappelle Heartbleed qui avait secoué Internet il y a plus de 10 ans, avec des conséquences parfois très graves.

• OpenSSL : la faille Heartbleed menace la sécurité du web, des sites ferment

Le CVE lui attribue une note de dangerosité de 7,5 sur 10 dans la version 3.1 du CVSS et de 8,7 sur 10 pour la version 4.0. L’alerte date du 19 décembre 2025 et fait suite à cinq bulletins de sécurité publiés par MongoDB les 25 novembre (1, 2 et 3), le 9 décembre (4) et enfin le 19 décembre (5). Le CERT indiquait le 23 décembre que la faille n’était pas activement exploitée… mais la situation va rapidement changer.

Dans le dernier bulletin de MongoDB, on peut lire que la faille concerne toutes les versions de MongoDB Server à partir de la 3.6. Le bug a été ajouté dans ce commit du 1ᵉʳ juin 2017… il y a donc plus de huit ans. Il est ensuite resté dans les versions plus récentes, de la 4.x à la 8.2 en passant par les 5.x, 6.x et 7.x. Des correctifs sont disponibles avec les versions 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 et 4.4.30. Les moutures 4.2, 4.0 et 3.6 de MongoDB sont donc laissées sur le côté.

Si vous ne pouvez pas mettre à jour rapidement, MongoDB recommande de « désactiver la compression zlib sur le serveur MongoDB en démarrant mongod ou mongos avec l’option networkMessageCompressors ou net.compression.compressors qui exclut explicitement zlib ».

Selon un rapport du moteur de recherche Censys (un concurrent de Shodan), plus de 87 000 bases de données seraient vulnérables.

Pour Noël, des « experts » publient des preuves de concept

Dans une mise à jour, le CERT Santé affirme maintenant qu’une preuve de concept « est disponible en sources ouvertes », permettant donc à n’importe qui d’exploiter facilement cette brèche si elle n’est pas corrigée. Les documents nécessaires pour créer un outil afin d’exploiter cette brèche ont été mis en ligne dans la nuit du 25 au 26 décembre sur un dépôt GitHub, soit une semaine après l’annonce de MongoDB et la mise en ligne des correctifs, en pleine période de préparation des fêtes de fin d’année.

Ils ont été publiés par un utilisateur qui serait responsable technique chez Elastic Security, qui se présente comme une « plateforme open source qui optimise la recherche, l’observabilité et la sécurité ». Le chercheur en cybersécurité Kevin Beaumont affirme avoir testé le PoC et confirme « que cet exploit est réel ».

C’est visiblement aussi simple à exploiter que HeartBleed, avec les mêmes dangers : « il suffit de fournir l’adresse IP d’une instance MongoDB et elle commencera à dénicher en mémoire des choses comme les mots de passe de base de données (qui sont en texte brut), les clés secrètes AWS, etc. », détaille Kevin Beaumont.

Ce dernier ajoute qu’une « autre entreprise a jugé bon de publier des détails techniques la veille de Noël » ; il s’agit d’Ox Security. Le ton est volontairement sarcastique car le calendrier est tout sauf idéal. La faille peut se révéler extrêmement dangereuse et publier les détails techniques de son exploitation permet à quasiment n’importe qui de tenter sa chance. Plusieurs s’étonnent d’ailleurs de voir des experts ainsi publier les détails d’exploitation d’une faille de sécurité aussi sensible, surtout en pleine période de fête.

Nous en parlions avec des experts en cybersécurité lors des Assises de Monaco en octobre dernier : « Quand une vulnérabilité est rendue publique avec son code d’exploitation, des acteurs malveillants vont lancer une campagne sur l’ensemble d’Internet en mode « /0 » pour tester si des sites ou services sont vulnérables ». Désormais, le plus difficile est presque d’estimer le bon montant de la rançon.

• /0 : Pourquoi des pirates et entreprises de cybersécurité scannent tout Internet (en IPv4)

Publier ainsi des PoC revient à faciliter la vie des pirates, comme relayer tout et n’importe quoi sur les fuites de données… et ainsi se faire les « commerciaux » des pirates. Un sujet sensible, qui nécessite souvent des vérifications incompatibles avec la course à l’information. Next a déjà depuis longtemps choisi son camp sur ce point.

Corriger est une chose, mais comment savoir si on a été victime ?

Que des chercheurs en cybersécurité postent des preuves de concepts et des détails techniques en plein pendant le réveillon n’est certainement pas l’idée de l’année… même s’il faut aussi reconnaitre que laisser des serveurs vulnérables pendant une semaine n’est pas mieux.

Aussi bien de la part du chercheur de chez Elastic Security que chez Ox Security, on ne trouve aucune précision sur comment détecter une exploitation de cette vulnérabilité dans les journaux par exemple. Un autre expert en cybersécurité s’est attelé à la tâche : Eric Capuano. Sur son blog, il recommande évidemment d’appliquer les correctifs, mais ajoute que « le patch seul ne suffit pas — il faut savoir si vous avez été ciblé avant le patch ».

Il explique que la particularité de cette brèche est qu’elle ne semble « détectable que dans les journaux du serveur MongoDB, qui ont très peu de chance d’être transmis à un système SIEM [Security Information and Event Management ou gestion des événements et des informations de sécurité, ndlr], et nécessite une logique relativement complexe qui pourrait être difficile à intégrer à la plupart des moteurs de détection SIEM ». Il propose un « artefact » pour Velociraptor, une plateforme open source de collecte et d’analyse. Si vous avez d’autres moyens de vérifier ce qu’il en est, n’hésitez pas à nous le signaler via les commentaires.

Ce n’est pas la première fois que MongoDB défraye la chronique. On se souvient par exemple en 2015 que plusieurs dizaines de milliers de bases de données étaient ouvertes aux quatre vents. Pas à cause d’une faille, mais d’un défaut de configuration avec des administrateurs qui laissaient les bases accessibles depuis n’importe quelle adresse IP. MongoDB avait alors réagi avec quasiment un simple RTFM (Read The Fucking Manual). Deux ans plus tard, rebelote. En 2023, MongoDB s’était fait pirater et des données de ses clients avaient été dérobées.