La vulnérabilité est apparue quelques jours avant Noël et, dans le pire des cas, permettait à des pirates non authentifiés de lire à distance la mémoire du serveur. Des correctifs sont déjà disponibles, mais l'impact est considérable : le problème touche pratiquement toutes les versions de MongoDB remontant à près de dix ans.
Surnommée MongoBleed (CVE-2025-14847), cette faille est une vulnérabilité pré-authentification dans le serveur MongoDB. Elle provient d'une incompatibilité entre les champs de longueur dans les en-têtes de protocole compressés zlib, qui peut amener le serveur à renvoyer une mémoire heap non initialisée à un client non authentifié. En clair, si un pirate parvient à atteindre une instance MongoDB via le réseau, il peut tenter de « vider » le contenu de la mémoire sans même se connecter.
Le système de suivi des problèmes de MongoDB est explicite quant à la correction, exhortant les utilisateurs à passer aux versions corrigées sur toutes les branches prises en charge (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 ou 4.4.30).
Ce qui rend MongoBleed particulièrement préoccupant, c'est la facilité avec laquelle il peut être exploité. Une preuve de concept publique est déjà disponible et ne nécessite guère plus que l'adresse IP d'un serveur MongoDB accessible. À partir de là, les pirates peuvent fouiller la mémoire divulguée à la recherche de secrets de grande valeur, notamment les identifiants de base de données stockés en clair, les clés cloud et d'autres informations sensibles. L'exploit est spécialement conçu pour rechercher précisément ce type de secrets, ce qui réduit considérablement le seuil d'abus dans le monde réel.
Trouver MongoDB partout : utiliser Vectra pour identifier l'exposition, les risques latéraux et l'exploitation
Avant de vous préoccuper de l'exploitation, vous devez répondre à une question beaucoup plus fondamentale :
Où MongoDB s'exécute-t-il réellement dans mon environnement ?
Cela semble trivial. Ce n'est pas le cas.
Entre les applications héritées, le shadow IT, cloud , les charges de travail conteneurisées et les bases de données « temporaires » qui sont devenues permanentes, MongoDB a tendance à apparaître dans des endroits dont personne ne se souvient avoir été propriétaire. Selon Shodan, plus de 200 000 instances MongoDB sont actuellement exposées à Internet. Ce n'est que la partie visible de l'iceberg.
La question la plus intéressante (et la plus dangereuse) est de savoir ce qui se passe à l'intérieur de votre réseau :
- Instances MongoDB accessibles par tout hôte compromis
- Bases de données liées à des ports non standard
- Services fonctionnant sans hypothèses d'authentification
- Les bases de données internes qui deviennent des tremplins parfaits pour les mouvements latéraux ou l'escalade des privilèges
C'est là que la visibilité au niveau du réseau prend toute son importance, et que la plateforme Vectra excelle.
Grâce à la visibilité approfondie du réseau et aux métadonnées enrichies de Vectra, nous disposons déjà des éléments nécessaires pour rechercher MongoDB n'importe où, quels que soient le port, le protocole ou le modèle de déploiement. Et lorsque les métadonnées ne suffisent pas, Vectra Match Suricata) nous permet d'aller plus loin grâce à des signatures sensibles au protocole.
Analysons cela.
1. Caractéristiques d'une instance MongoDB sur le réseau
Pour exploiter efficacement MongoDB, nous devons comprendre son comportement sur le réseau.
Caractéristiques du réseau par défaut
À un niveau élevé, MongoDB est un protocole client-serveur basé sur TCP.
Les caractéristiques communes comprennent :
- Port TCP par défaut : 27017
- Ports alternatifs courants : 27018, 27019 ou ports élevés arbitraires dans cloud conteneurisés cloud .
- Sessions TCP de longue durée : les clients maintiennent souvent les connexions ouvertes.
- Trafic bidirectionnel de requêtes/réponses : pas seulement de courtes rafales
Mais la détection basée uniquement sur les ports est fragile, les pirates et les administrateurs le savent bien.
Protocole filaire MongoDB (texte clair)
Lorsque TLS n' est pas activé, le trafic MongoDB est entièrement visible sur le réseau.
Principales caractéristiques du protocole filaire MongoDB :
- Protocole binaire avec en-tête de message standard
- Les champs d'en-tête comprennent :
- Longueur du message
- Identifiant de la demande
- Réponse à l'identifiant
- OpCode (par exemple, OP_MSG, OP_QUERY, opérations héritées)
- Les premiers paquets contiennent souvent :
- Poignée de main du client (isMaster / hello)
- Métadonnées du pilote (langue, version)
- Négociation d'authentification
Du point de vue du réseau, cela nous donne :
- Effacer les réponses du serveur
- Structure de protocole identifiable
- Modèles de requêtes prévisibles pendant l'établissement de la connexion
En d'autres termes : facile à identifier, même sur des ports non standard.
MongoDB avec TLS activé
Le protocole TLS complique les choses, mais il ne rend pas MongoDB invisible.
Lorsque TLS est actif :
- La charge utile est cryptée.
- Le contenu du protocole est masqué.
- Mais le comportement de la session et les métadonnées restent inchangés.
Ce que nous voyons encore :
- Destination et source TCP
- Utilisation des ports (même non standard)
- Durée de la session
- Nombre d'octets et directionnalité
- Métadonnées du certificat (si disponibles)
- Nom du serveur
- Émetteur
- Réutilisation des certificats entre les hôtes
Ceci est essentiel, car la plupart des environnements réels sont mixtes :
- Certaines instances MongoDB utilisent TLS.
- D'autres non
- Certains commencent en clair et passent à une version supérieure
- Certains s'appuient sur des hypothèses internes relatives à un « réseau de confiance ».
Les métadonnées de Vectra rendent ces différences visibles, sans déchiffrer le trafic.
Pourquoi cela est important pour MongoBleed
MongoBleed est une vulnérabilité pré-authentification accessible via le réseau.
Cela signifie :
- MongoDB exposé à Internet = risque immédiat
- MongoDB accessible en interne = mine d'or après compromission
- TLS ne supprime pas l'exploitabilité
- L'authentification ne supprime pas l'exploitabilité
Si un pirate parvient à se connecter, il peut alors sonder le système.
2. Recherche d'instances MongoDB à l'aide des métadonnées réseau
C'est là que nous passons de la théorie à la pratique.
Vectra génère en continu des métadonnées réseau enrichies qui nous permettent de rechercher des instances MongoDB sans avoir recours à des journaux, des agents ou des inventaires d'actifs.
Recherche d'instances MongoDB exposées à Internet
Principales approches de chasse :
- Identifier les hôtes internes acceptant les connexions entrantes provenant d'Internet
- Filtrer sur :
- Services TCP avec comportement de type serveur
- Sessions de longue durée
- Connexions entrantes répétées provenant de diverses adresses IP sources
- Corrélation avec :
- Ports par défaut connus de MongoDB
- Trafic entrant à haute entropie sur des ports inhabituels
- Certificats TLS réutilisés sur plusieurs écouteurs MongoDB
Cela apparaît immédiatement :
- cloud oubliées
- Bases de données de test accidentellement exposées
- Des services « temporaires » devenus permanents
Et contrairement à Shodan, il s'agit ici de votre exposition réelle, et non d'un résultat d'analyse.
SÉLECTIONNER
id.resp_h,
resp_hostname.name,
COUNT(*) AS nombre_connexions
FROM network.isession._all
OÙ id.resp_p = 27017
ET local_orig = FAUX
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
GROUP BY id.resp_h, resp_hostname.name
ORDRE PAR nombre_de_connexions DESC
LIMITE 100
Dans ce scénario, nous nous concentrons sur l'identification des serveurs MongoDB fonctionnant sur TLS, quel que soit le port TCP utilisé. Étant donné qu'il n'est pas possible d'inspecter la charge utile avec un trafic crypté, nous nous appuyons sur les empreintes TLS, en particulier JA3 et JA4, qui sont automatiquement calculées par la plateforme Vectra pour chaque session TLS observée et enrichies dans les métadonnées réseau.
JA3 et JA4 identifient le comportement des clients TLS en hachant les caractéristiques de la poignée de main TLS, telles que les suites de chiffrement prises en charge, les extensions et les versions de protocole. Leurs équivalents côté serveur, JA3S et JA4S, capturent l'empreinte digitale de la réponse du serveur TLS, ce qui les rend particulièrement utiles pour identifier les technologies serveur sans déchiffrer le trafic.
En pratique, cela nous permet de repérer les serveurs MongoDB TLS en fonction de la manière dont ils négocient le protocole TLS, même lorsqu'ils fonctionnent sur des ports non standard ou qu'ils sont impossibles à distinguer au niveau de la couche transport.
Il est toutefois important de noter que les empreintes JA3S et JA4S ne sont pas uniques au niveau mondial. Des empreintes similaires peuvent être partagées entre différentes piles de serveurs et bibliothèques, ce qui signifie que des collisions sont possibles et que le contexte reste important.
Cela dit, les tests effectués sur plusieurs versions de MongoDB montrent que les empreintes JA3S et JA4S sont très cohérentes d'une version à l'autre, ce qui en fait un signal fiable lorsqu'elles sont combinées avec le comportement du réseau, les modèles de session et endpoint .
Recherche de serveurs MongoDB sur des ports non standard
L'identification des serveurs MongoDB qui ne sont pas liés à un port connu nécessite une analyse et un contexte supplémentaires. Dans ces cas, un simple filtrage basé sur les ports est insuffisant, et nous devons nous appuyer sur des indicateurs de plus haut niveau dérivés des métadonnées réseau.
Une approche efficace consiste à examiner les identifiants côté serveur, tels que le nom d'hôte du répondeur ou l'indication de nom de serveur TLS (SNI), et à rechercher des modèles suggérant une infrastructure de base de données. Les noms d'hôte faisant référence à des rôles de base de données, des clusters, des shards ou des ensembles de répliques peuvent fournir des indices solides indiquant que le service en question est un backend MongoDB, même lorsqu'il écoute sur un port inattendu.
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM réseau.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
ET local_orig = FAUX
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
ORDER BY timestamp DESC
LIMITE 1000
Si nous prenons également en compte le port de destination :
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM réseau.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
ET id.resp_p = 27017
ET local_orig = FAUX
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
ORDER BY timestamp DESC
LIMITE 1000
Remarque : MongoDB n'est pas fourni avec des certificats TLS ou des clés privées par défaut. Lorsque TLS est activé, les administrateurs doivent explicitement fournir leur propre certificat et leur propre clé. De plus, MongoDB utilise TLS 1.3 par défaut lorsque TLS est actif, ce qui signifie que les certificats traditionnels et les métadonnées x.509 ne sont pas exposés dans la télémétrie réseau.
Recherche d'instances MongoDB internes
Les menaces internes liées à MongoDB sont souvent plus dangereuses que les menaces externes.
Pourquoi ?
- Les pirates n'ont pas besoin de scanner Internet
- Les hôtes compromis peuvent énumérer librement
- Les bases de données internes manquent souvent de renforcement
Les modes de chasse comprennent :
- Services TCP est-ouest agissant comme des serveurs persistants
- Connexions répétées depuis les couches applicatives
- Modèles comportementaux connus de MongoDB (durée de session, cadence des requêtes)
- Services accessibles par de nombreux hôtes internes différents
Cela révèle rapidement :
- Bases de données accessibles partout
- Problèmes liés à la conception d'un réseau plat
- Cibles idéales pour les mouvements latéraux
SÉLECTIONNER
id.resp_h,
resp_hostname.name,
COUNT(*) AS nombre_connexions
FROM network.isession._all
OÙ id.resp_p = 27017
ET local_orig = FAUX
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
GROUP BY id.resp_h, resp_hostname.name
ORDRE PAR nombre_de_connexions DESC
LIMITE 100
Ici aussi, nous pouvons utiliser JA3S et JA4S :
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM réseau.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
ET local_orig = VRAI
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
ORDER BY timestamp DESC
LIMITE 1000
Si nous prenons également en compte le port de destination :
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
FROM réseau.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
ET id.resp_p = 27017
ET local_orig = VRAI
ET local_resp = VRAI
ET horodatage ENTRE date_add('day', -14, now()) ET now()
ORDER BY timestamp DESC
LIMITE 1000
À la recherche d'une exploitation potentielle de MongoBleed
Même sans visibilité sur la charge utile, les tentatives d'exploitation laissent des traces.
Éléments à rechercher :
- Tentatives de connexion inhabituelles aux services MongoDB
- Connexions répétées et de courte durée provenant d'hôtes inattendus
- Nouveau comportement du client MongoDB sur les systèmes qui ne l'ont jamais utilisé auparavant
- Pics soudains dans les connexions
- Trafic MongoDB provenant de systèmes non liés à des applications (postes de travail, hôtes relais, serveurs compromis)
Ce sont les signes classiques de :
- Reconnaissance
- Test d'exploitation
- Sondage automatisé de la mémoire
La vision centrée sur les entités de Vectra permet de mettre rapidement cela en évidence, en particulier lorsqu'elle est associée au contexte d'identité et d'hôte.
SÉLECTIONNER
id.orig_h,
id.resp_h,
id.resp_p,
durée,
conn_state,
horodatage,
octets_ip_origine,
octets_ip_réponse
FROM network.isession._all
OÙ conn_state EST DANS ('SF')
AND duration < 5000
ET orig_ip_bytes = 44
ET first_orig_resp_data_pkt = 'LAAAAAEAAAAAAAAA3AcAAA=='
ET horodatage ENTRE date_add('day', -14, now()) ET now()
ORDER BY timestamp DESC
LIMITE 100
Cette requête est un exemple de recherche de trafic MongoDB non chiffré où le premier paquet a une taille de 44 octets avec un en-tête MongoDB définissant un message compressé.
Le format d'en-tête MongoDB est défini comme suit :
Le PoC publié utilise une longueur de 44 octets avec un code opérationnel de 2012 (données compressées).
3. Approfondir avec Vectra Match Suricata)
Les métadonnées nous permettent d'aller loin. Vectra Match nous Match d'être précis.
À l'aide de signatures basées sur Suricata, nous pouvons identifier explicitement le trafic MongoDB et les modèles d'exploitation. Le Match Vectra Match est basé sur le jeu de règles commercial ETPro et contient les deux règles suivantes pour MongoBleed. La première consiste à détecter les tentatives d'authentification entrantes et la seconde à détecter l'exploitation elle-même. Elles sont toutes deux incluses dans le jeu de règles Vectra Match .
Détection de l'utilisation potentielle d'exploits
Pour MongoBleed en particulier, les signatures peuvent cibler :
- Longueurs de protocole mal formées ou anormales
- Tentatives répétées de poignée de main sans authentification
- Anomalies de protocole compatibles avec des tentatives de divulgation de mémoire
- Comportement de sondage à haute fréquence contre les services MongoDB
Cela ne repose pas uniquement sur des charges utiles spécifiques à CVE, mais se concentre sur le comportement, ce qui est beaucoup plus difficile à contourner pour les pirates.
alerte tcp tout tout -> $HOME_NET 27017 (msg : « ET INFO Authentification SASL MongoDB détectée » ; flux : établi, vers le serveur ; bits de flux : définis, ET.MongoDB_Auth_Attempt ; bits de flux : sans alerte ; contenu : « |dd 07 00 00| » ; décalage : 12 ; profondeur : 4 ; contenu : « saslstart » ; fast_pattern ; nocase ; distance : 0 ; référence : url, www.alienfactory.co.uk/articles/mongodb-scramsha1-over-sasl ; classtype : misc-activity ; sid : 2066500 ; rev : 1 ; metadata : affected_product MongoDB, attack_target Server, created_at 2025_12_29, deployment Perimeter, confidence High, signature_severity Informational, updated_at 2025_12_29 ; target:dest_ip;)
alert tcp any any -> $HOME_NET 27017 (msg:"ET EXPLOIT MongoDB Unauthenticated Memory Leak (CVE-2025-14847)"; flux : établi, vers le serveur ; bits de flux : non défini, ET.MongoDB_Auth_Attempt ; contenu : « |dc 07 00 00 dd 07 00 00| » ; fast_pattern ; offset : 12 ; depth : 8 ; content : « |02| » ; distance : 4 ; within : 1 ; threshold : type threshold, track by_src, count 10, seconds 120 ; reference : url,bigdata.2minutestreaming.com/p/mongobleed-explained-simply ; reference : cve,2025-14847 ; classtype : tentative d'administration ; sid : 2066501 ; rev : 1 ; métadonnées : produit affecté MongoDB, cible de l'attaque Serveur, créé le 29/12/2025, cve CVE_2025_14847, déploiement Périmètre, déploiement Interne, confiance Faible, gravité de la signature Majeur, mis à jour le 29/12/2025 ; cible : dest_ip) ;
Texte clair, TLS et ports non standard — Couverts
À travers toutes ces chasses, la conclusion principale est simple :
- MongoDB en clair : protocole + métadonnées + signatures
- TLS MongoDB : métadonnées + analyse comportementale + certificats
- Ports non standard : le comportement l'emporte toujours sur les ports
Les pirates ne se soucient pas du port sur lequel MongoDB fonctionne, et les défenseurs ne devraient pas s'en soucier non plus.
Ce qu'il faut surveiller et ce qu'il faut rechercher
Appeler le médecin de garde lorsque
- Le MongoDB connecté à Internet reçoit des rafales entrantes provenant d'adresses IP inconnues.
- Les serveurs MongoDB internes subissent des tempêtes de connexions de type « scanner ».
- Les nouveaux clients commencent à communiquer via le protocole MongoDB sur des ports inhabituels.
Chasser quand
- Vous voyez le protocole MongoDB sur des ports non standard (niveau 2)
- Vous constatez des tentatives d'authentification provenant de sources inhabituelles (niveau 3).
- Vous constatez une augmentation des connexions de courte durée, même sans visibilité sur la charge utile (niveau 2).
Atténuation (car la détection ne remplace pas l'application de correctifs)
Les recommandations de MongoDB pour corriger le problème sont simples : effectuez une mise à niveau vers les versions corrigées (8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30). (jira.mongodb.org)
Le NVD résume la vulnérabilité comme une incompatibilité entre les champs de longueur dans les en-têtes zlib, permettant des lectures non authentifiées dans le tas. (NVD)
Il existe un PoC public, ce qui réduit l'effort requis par l'attaquant. (GitHub)
Pourquoi est-ce important ?
MongoBleed est simplement le dernier rappel en date que les bases de données ne sont pas des infrastructures passives. Elles constituent des surfaces d'attaque actives.
Si vous ne pouvez pas répondre :
- Où MongoDB est-il exécuté ?
- Qui peut l'atteindre ?
- Qui le touche en ce moment ?
… alors les correctifs seuls ne suffiront pas à vous sauver.
Vectra AI vous offre la visibilité nécessaire pour répondre à ces questions, ainsi que les capacités de recherche et de détection qui vous permettent d'agir avant que la « fuite de mémoire » ne se transforme en une violation à grande échelle.