Et Joyeux Noël !

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.

Tout commence ce week-end par un cadeau de Noël totalement inattendu pour certains joueurs : des crédits, des objets, des skins et des packs ont été distribués « gratuitement ». Selon BleepingComputer, pas moins de deux milliards de crédits R6 qui auraient été distribués. Actuellement, 15 000 crédits R6 sont vendus 99,99 euros.

Selon l’ancien joueur et désormais streameur KingGeorge, des joueurs ont aussi été bannis et/ou réautorisés dans le jeu. De faux messages étaient aussi affichés sur le bandeau d’information du bannissement. Bref, c’est un peu le scénario catastrophe avec une pénétration des pirates en profondeur dans les mécanismes du jeu.

Ubisoft has apparently been breached by an unknown group that gifted random items and billions of R6 credits pic.twitter.com/Z8qnTWuClT

— Nevermiss (@Nevermissgg) December 27, 2025

La réaction officielle d’Ubisoft ne s’est pas fait attendre. Samedi 27 décembre (à 15h10 heure française), l’entreprise publiait un message sur le compte officiel de Rainbow Six Siege sur X : « Nous sommes au courant d’un incident […] Nos équipes travaillent à sa résolution ». Rapidement suivi d’un deuxième message, plus inquiétant : le jeu et sa marketplace « ont été volontairement mis hors service le temps que l’équipe se concentre sur la résolution du problème ».

Quelques heures plus tard, toujours sur X, Rainbow Six Siege répondait à la crainte de certains joueurs :

« Personne ne sera banni pour avoir dépensé les crédits reçus. Une annulation de toutes les transactions effectuées depuis 11 h (heure UTC) est en cours. L’indicateur de bannissement a été désactivé lors d’une mise à jour précédente. Les messages affichés ne sont pas de notre fait. Une vague officielle d’interdiction de R6 ShieldGuard s’est déroulée, mais n’est pas liée à cet incident. Nous travaillons d’arrache-pied pour que ce problème soit résolu et que les joueurs puissent rejouer ».

Hier après-midi, le compte officiel annonçait qu’une « restauration [était] en cours. Et, par la suite, des tests de contrôle approfondis seront effectués afin de garantir l’intégrité des comptes et l’efficacité des modifications ». Il y a quelques heures seulement, Ubisoft annonçait un « retour progressif, en ouvrant le jeu à un petit nombre de joueurs seulement ». Deux heures plus tard (ce matin à 3h12), « le jeu est ouvert à tous », mais pas la marketplace, qui reste fermée « jusqu’à nouvel ordre ».

Le retour en arrière est désormais terminé : : « Les joueurs qui ne se sont pas connectés entre le samedi 27 décembre à 10h49 UTC et le 29 décembre ne devraient voir aucun changement dans leur inventaire ». Par contre, pour ceux « qui se sont connectés après le 27 décembre à 10h49 UTC : un faible pourcentage d’entre eux pourraient temporairement perdre l’accès à certains objets leur appartenant. Des investigations et des corrections seront menées au cours des deux prochaines semaines ».

Ubisoft ne donne pas de détail sur le piratage de son jeu, mais des yeux se tournent vers une faille MongoDB massivement exploitée ces derniers jours. Nous aurons l’occasion d’y revenir dans la matinée.

Alors que la Poste s‘est tout juste remise d’une cyberattaque de type DDoS qui a paralysé ses services pendant plusieurs jours (mais sans fuite de données des clients), Mondial Relay expliquait ce week-end à l’AFP avoir détecté « des accès non autorisés à sa plateforme ». L’entreprise ne donne pas de détails sur l’origine précise de la fuite ni son ampleur.

« Sur la plateforme, dédiée au suivi des colis et au support client, se trouvaient le nom, prénom, adresse e-mail et postale et numéro de téléphone des clients. Aucune donnée bancaire ou de paiement n’était accessible », expliquent nos confrères de l’AFP, via Sud Ouest. Les clients de l’entreprise « potentiellement exposés » sont contactés.

Mondial Relay affirme avoir informé la CNIL, comme la loi l’y oblige. Elle a également fait part de son intention de déposer plainte.

Les risques en pareilles situations sont un peu toujours les mêmes : du phishing personnalisé, d’autant plus en cette période de fête où les livraisons de colis sont en forte augmentation. Redoublez donc de prudence en cas de correspondance venant de Mondial Relay.

• Quels sont les risques liés aux multiples fuites de vos données personnelles ?