La vulnerabilidad salió a la luz pocos días antes de Navidad y, en el peor de los casos, permitía a atacantes no autenticados leer la memoria del servidor de forma remota. Ya hay soluciones disponibles, pero el alcance del problema es amplio: afecta prácticamente a todas las versiones de MongoDB de los últimos diez años.
Denominada MongoBleed (CVE-2025-14847), la falla es una vulnerabilidad previa a la autenticación en el servidor MongoDB. Se debe a campos de longitud no coincidentes en los encabezados de protocolo comprimidos con zlib, lo que puede hacer que el servidor devuelva memoria heap no inicializada a un cliente no autenticado. En pocas palabras: si un atacante puede acceder a una instancia de MongoDB a través de la red, puede intentar «sangrar» el contenido de la memoria sin necesidad de iniciar sesión.
El propio gestor de incidencias de MongoDB es explícito en cuanto a la corrección, instando a los usuarios a actualizar a las versiones corregidas en todas las ramas compatibles (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.30).
Lo que hace que MongoBleed sea especialmente preocupante es lo fácil que resulta explotarlo. Ya hay disponible una prueba de concepto pública que solo requiere la dirección IP de un servidor MongoDB accesible. A partir de ahí, los atacantes pueden rastrear la memoria filtrada en busca de secretos de gran valor, como credenciales de bases de datos almacenadas en texto plano, claves cloud y otro material confidencial. El exploit está diseñado específicamente para buscar este tipo de secretos, lo que reduce drásticamente las barreras para su uso indebido en el mundo real.
Encontrar MongoDB en todas partes: uso de Vectra para identificar la exposición, el riesgo lateral y la explotación
Antes de preocuparte por la explotación, debes responder a una pregunta mucho más básica:
¿Dónde se ejecuta realmente MongoDB en mi entorno?
Eso suena trivial. Pero no lo es.
Entre aplicaciones heredadas, TI paralela, cloud , cargas de trabajo en contenedores y bases de datos «temporales» que de alguna manera se han convertido en permanentes, MongoDB tiene la costumbre de aparecer en lugares que nadie recuerda haber tenido. Según Shodan, más de 200 000 instancias de MongoDB están actualmente expuestas a Internet. Eso es solo la parte visible del iceberg.
La pregunta más interesante (y más peligrosa) es qué está sucediendo dentro de su red:
- Instancias de MongoDB accesibles desde cualquier host comprometido
- Bases de datos vinculadas a puertos no estándar
- Servicios que se ejecutan sin supuestos de autenticación
- Las bases de datos internas se convierten en trampolines perfectos para el movimiento lateral o la escalada de privilegios.
Aquí es donde la visibilidad a nivel de red cobra importancia, y donde la plataforma Vectra destaca.
Gracias a la profunda visibilidad de red y los metadatos enriquecidos de Vectra, ya disponemos de la materia prima necesaria para buscar MongoDB en cualquier lugar, independientemente del puerto, el protocolo o el modelo de implementación. Y cuando los metadatos no son suficientes, Vectra Match Suricata) nos permite ir un paso más allá con firmas sensibles al protocolo.
Analicemos esto.
1. Características de una instancia de MongoDB en la red
Para cazar MongoDB de manera eficaz, necesitamos comprender cómo se comporta en la red.
Características predeterminadas de la red
A alto nivel, MongoDB es un protocolo cliente-servidor basado en TCP.
Las características comunes incluyen:
- Puerto TCP predeterminado: 27017
- Puertos alternativos comunes: 27018, 27019 o puertos altos arbitrarios en cloud contenedorizados/en cloud .
- Sesiones TCP de larga duración: los clientes suelen mantener las conexiones abiertas.
- Tráfico bidireccional de solicitud/respuesta: no solo ráfagas cortas
Pero la detección basada únicamente en los puertos es frágil, y tanto los atacantes como los administradores lo saben.
Protocolo de cable MongoDB (texto sin cifrar)
Cuando TLS no está habilitado, el tráfico de MongoDB es totalmente visible en la red.
Características principales del protocolo de cable MongoDB:
- Protocolo binario con un encabezado de mensaje estándar.
- Los campos del encabezado incluyen:
- Longitud del mensaje
- ID de solicitud
- Respuesta a ID
- Código de operación (por ejemplo, OP_MSG, OP_QUERY, operaciones heredadas)
- Los primeros paquetes suelen contener:
- Apretón de manos del cliente (isMaster / hola)
- Metadatos del controlador (idioma, versión)
- Negociación de autenticación
Desde una perspectiva de red, esto nos da:
- Borrar respuestas del servidor
- Estructura de protocolo identificable
- Patrones predecibles de solicitudes durante el establecimiento de la conexión
En otras palabras: fácil de identificar, incluso en puertos no estándar.
MongoDB con TLS habilitado
TLS complica las cosas, pero no hace que MongoDB sea invisible.
Cuando TLS está activo:
- La carga útil está cifrada.
- El contenido del protocolo está oculto.
- Pero el comportamiento de la sesión y los metadatos permanecen.
Lo que aún vemos:
- Destino y origen TCP
- Uso de puertos (aunque no sean estándar)
- Duración de la sesión
- Recuento de bytes y direccionalidad
- Metadatos del certificado (cuando estén disponibles)
- Nombre del servidor
- Emisor
- Reutilización de certificados entre hosts
Esto es fundamental, ya que la mayoría de los entornos del mundo real son mixtos:
- Algunas instancias de MongoDB utilizan TLS.
- Otros no
- Algunos comienzan en texto sin cifrar y se actualizan.
- Algunos se basan en supuestos internos de «red de confianza».
Los metadatos de Vectra hacen visibles estas diferencias, sin necesidad de descifrar el tráfico.
Por qué es importante para MongoBleed
MongoBleed es una vulnerabilidad accesible desde la red previa a la autenticación.
Eso significa:
- MongoDB expuesto a Internet = riesgo inmediato
- MongoDB accesible internamente = mina de oro tras el compromiso
- TLS no elimina la vulnerabilidad.
- La autenticación no elimina la vulnerabilidad.
Si un atacante puede conectarse, puede sondear.
2. Búsqueda de instancias de MongoDB utilizando metadatos de red
Aquí es donde pasamos de la teoría a la práctica.
Vectra genera continuamente metadatos de red enriquecidos que nos permiten buscar instancias de MongoDB sin depender de registros, agentes o inventarios de activos.
Búsqueda de instancias de MongoDB expuestas a Internet
Principales enfoques de búsqueda:
- Identificar los hosts internos que aceptan conexiones entrantes desde Internet.
- Filtrar por:
- Servicios TCP con comportamiento similar al de un servidor
- Sesiones de larga duración
- Conexiones entrantes repetidas desde diversas direcciones IP de origen.
- Correlacionar con:
- Puertos predeterminados conocidos de MongoDB
- Tráfico entrante de alta entropía en puertos inusuales
- Certificados TLS reutilizados en múltiples oyentes de MongoDB
Esto sale inmediatamente a la superficie:
- cloud olvidadas
- Bases de datos de prueba expuestas accidentalmente
- Servicios «temporales» que se convirtieron en permanentes
Y, a diferencia de Shodan, esta es tu exposición real, no el resultado de un escaneo.
SELECCIONAR
id.resp_h,
resp_hostname.name,
COUNT(*) AS recuento_conexiones
DE network.isession._all
DONDE id.resp_p = 27017
Y local_orig = FALSO
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
GRUPO POR id.resp_h, resp_hostname.name
ORDENAR POR connection_count DESC
LÍMITE 100
En este escenario, nos centramos en identificar los servidores MongoDB que se ejecutan sobre TLS, independientemente del puerto TCP que se utilice. Dado que la inspección de la carga útil no es posible con el tráfico cifrado, nos basamos en las huellas digitales TLS, concretamente JA3 y JA4, que la plataforma Vectra calcula automáticamente para cada sesión TLS observada y enriquece con metadatos de red.
JA3 y JA4 comportan el cliente TLS mediante el hash de las características del protocolo de enlace TLS, como los conjuntos de cifrado compatibles, las extensiones y las versiones de protocolo. Sus homólogos del lado del servidor, JA3S y JA4S, capturan la huella digital de la respuesta del servidor TLS, lo que los hace especialmente útiles para identificar tecnologías de servidor sin descifrar el tráfico.
En la práctica, esto nos permite detectar servidores MongoDB TLS basándonos en cómo negocian TLS, incluso cuando se ejecutan en puertos no estándar o son indistinguibles en la capa de transporte.
Sin embargo, es importante señalar que las huellas digitales JA3S y JA4S no son únicas a nivel mundial. Se pueden compartir huellas digitales similares entre diferentes pilas de servidores y bibliotecas, lo que significa que pueden producirse colisiones y que el contexto sigue siendo importante.
Dicho esto, las pruebas realizadas en varias versiones de MongoDB muestran que las huellas digitales JA3S y JA4S son muy consistentes entre las distintas versiones, lo que las convierte en una señal fiable cuando se combinan con el comportamiento de la red, los patrones de sesión y el contexto del punto final.
Búsqueda de servidores MongoDB en puertos no estándar
Identificar servidores MongoDB que no están vinculados a un puerto conocido requiere un análisis y un contexto adicionales. En estos casos, el simple filtrado basado en puertos es insuficiente y debemos basarnos en indicadores de mayor nivel derivados de los metadatos de la red.
Un enfoque eficaz consiste en examinar los identificadores del lado del servidor, como el nombre de host del respondedor o la indicación del nombre del servidor TLS (SNI), y buscar patrones que sugieran una infraestructura de base de datos. Los nombres de host que hacen referencia a roles, clústeres, fragmentos o conjuntos de réplicas de bases de datos pueden proporcionar indicios sólidos de que el servicio en cuestión es un backend de MongoDB, incluso cuando está escuchando en un puerto inesperado.
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DESDE network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
Y local_orig = FALSO
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
ORDENAR POR timestamp DESC
LÍMITE 1000
Si además tenemos en cuenta el puerto de destino:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DESDE network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
Y id.resp_p = 27017
Y local_orig = FALSO
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
ORDENAR POR timestamp DESC
LÍMITE 1000
Nota: MongoDB no incluye certificados TLS ni claves privadas predeterminados. Cuando TLS está habilitado, los administradores deben proporcionar explícitamente su propio certificado y material de clave. Además, MongoDB utiliza TLS 1.3 de forma predeterminada cuando TLS está activo, lo que significa que los certificados tradicionales y los metadatos x.509 no se exponen en la telemetría de red.
Búsqueda de instancias internas de MongoDB
El MongoDB interno suele ser más peligroso que la exposición externa.
¿Por qué?
- Los atacantes no necesitan escanear Internet.
- Los hosts comprometidos pueden enumerarse libremente.
- Las bases de datos internas suelen carecer de refuerzo.
Los patrones de caza incluyen:
- Servicios TCP este-oeste que actúan como servidores persistentes
- Conexiones repetidas desde los niveles de aplicación
- Patrones de comportamiento conocidos de MongoDB (duración de la sesión, cadencia de solicitudes)
- Servicios accesibles desde muchos hosts internos diferentes.
Esto revela rápidamente:
- Bases de datos accesibles desde cualquier lugar
- Problemas de diseño de redes planas
- Objetivos ideales para el movimiento lateral
SELECCIONAR
id.resp_h,
resp_hostname.name,
COUNT(*) AS recuento_conexiones
DE network.isession._all
DONDE id.resp_p = 27017
Y local_orig = FALSO
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
GRUPO POR id.resp_h, resp_hostname.name
ORDENAR POR connection_count DESC
LÍMITE 100
Aquí también podemos usar JA3S y JA4S:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DESDE network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
Y local_orig = TRUE
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
ORDENAR POR timestamp DESC
LÍMITE 1000
Si además tenemos en cuenta el puerto de destino:
SELECT id.orig_h, id.resp_h, id.resp_p, server_name, cipher, version, ja3s, ja4s, timestamp
DESDE network.ssl._all
WHERE (ja3s = '15af977ce25de452b96affa2addb1036' OR ja4s = 't130200_1302_a56c5b993250')
Y id.resp_p = 27017
Y local_orig = TRUE
Y local_resp = VERDADERO
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
ORDENAR POR timestamp DESC
LÍMITE 1000
Búsqueda de posibles vulnerabilidades de MongoBleed
Incluso sin visibilidad de la carga útil, los intentos de explotación dejan huellas.
Aspectos a tener en cuenta:
- Intentos de conexión inusuales a los servicios de MongoDB
- Conexiones efímeras y repetidas desde hosts inesperados.
- Nuevo comportamiento del cliente MongoDB en sistemas que nunca lo habían utilizado antes
- Aumentos repentinos en las conexiones
- Tráfico de MongoDB procedente de sistemas que no son de aplicación (estaciones de trabajo, hosts de salto, servidores comprometidos)
Estos son los signos clásicos de:
- Reconocimiento
- Pruebas de explotación
- Sondeo automático de memoria
La visión centrada en las entidades de Vectra hace que esto destaque rápidamente, especialmente cuando se combina con la identidad y el contexto del host.
SELECCIONAR
id.orig_h,
id.resp_h,
id.resp_p,
duración,
conn_state,
marca de tiempo,
orig_ip_bytes,
bytes_resp_ip
DE network.isession._all
DONDE conn_state EN ('SF')
AND duration < 5000
Y orig_ip_bytes = 44
Y first_orig_resp_data_pkt = 'LAAAAAEAAAAAAAAA3AcAAA=='
Y marca de tiempo ENTRE date_add('day', -14, now()) Y now()
ORDENAR POR timestamp DESC
LÍMITE 100
Esta consulta es un ejemplo de cómo buscar tráfico MongoDB sin cifrar en el que el primer paquete tiene un tamaño de 44 bytes con un encabezado MongoDB que define un mensaje comprimido.
El formato del encabezado MongoDB se define de la siguiente manera:
El PoC publicado utiliza una longitud de 44 bytes con un código de operación de 2012 (datos comprimidos).
3. Profundizando con Vectra Match Suricata)
Los metadatos nos llevan lejos. Vectra Match nos Match ser precisos.
Mediante el uso de firmas basadas en Suricata, podemos identificar explícitamente el tráfico de MongoDB y los patrones de explotación. El Match Vectra Match se basa en el conjunto de reglas comercial ETPro y contiene las dos reglas siguientes para MongoBleed. La primera es detectar los intentos de autenticación entrantes y la segunda es detectar la propia explotación. Ambas están incluidas en el conjunto de reglas Vectra Match .
Detección del uso potencial de exploits
En el caso concreto de MongoBleed, las firmas pueden dirigirse a:
- Longitudes de protocolo malformadas o anormales
- Intentos repetidos de establecimiento de conexión sin autenticación
- Anomalías en el protocolo compatibles con intentos de divulgación de memoria.
- Comportamiento de sondeo de alta frecuencia contra los servicios de MongoDB
Esto no se basa únicamente en cargas útiles específicas de CVE, sino que se centra en el comportamiento, lo que resulta mucho más difícil de eludir para los atacantes.
alerta tcp cualquier cualquier -> $HOME_NET 27017 (mensaje: «ET INFO MongoDB SASL Authentication Detected»; flujo:establecido,al_servidor; bits_de_flujo:establecidos,ET.MongoDB_Auth_Attempt; bits_de_flujo:sin_alerta; contenido:"|dd 07 00 00|"; desplazamiento:12; profundidad:4; contenido:"saslstart"; fast_pattern; nocase; distance:0; reference: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)"; flujo: establecido, al servidor; bits de flujo: no establecido, ET.MongoDB_Auth_Attempt; contenido: «|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:intento-admin; sid:2066501; rev:1; metadatos:producto_afectado MongoDB, objetivo_del_ataque Servidor, creado_el 29_12_2025, cve CVE_2025_14847, despliegue Perímetro, despliegue Interno, confianza Baja, gravedad_de_la_firma Grave, actualizado_el 29_12_2025; objetivo:dest_ip;)
Texto sin cifrar, TLS y puertos no estándar: cubiertos
En todas estas búsquedas, la conclusión clave es sencilla:
- MongoDB de texto claro: protocolo + metadatos + firmas
- TLS MongoDB: metadatos + análisis de comportamiento + certificados
- Puertos no estándar: el comportamiento supera a los puertos en todo momento.
A los atacantes no les importa en qué puerto se ejecuta MongoDB, y a los defensores tampoco debería importarles.
Qué alertar frente a qué perseguir
Llama al médico de guardia cuando
- MongoDB conectado a Internet recibe ráfagas entrantes desde direcciones IP desconocidas.
- Los servidores internos de MongoDB reciben tormentas de conexiones similares a las de un escáner.
- Los nuevos clientes comienzan a comunicarse mediante el protocolo MongoDB en puertos no habituales.
Cazar cuando
- Ves el protocolo MongoDB en puertos no estándar (Nivel 2)
- Ves intentos de autenticación desde fuentes inusuales (Nivel 3)
- Se observa un aumento repentino en las conexiones de corta duración, incluso sin visibilidad de la carga útil (Nivel 2).
Mitigación (porque la detección no sustituye a la aplicación de parches)
Las instrucciones de MongoDB para solucionar el problema son sencillas: actualizar a las versiones corregidas (8.2.3 / 8.0.17 / 7.0.28 / 6.0.27 / 5.0.32 / 4.4.30). (jira.mongodb.org)
El NVD resume la vulnerabilidad como una discrepancia en el campo de longitud de los encabezados zlib que permite lecturas no autenticadas del montón. (NVD)
Existe un PoC público, lo que reduce el esfuerzo del atacante. (GitHub)
¿Por qué es importante?
MongoBleed es solo el último recordatorio de que las bases de datos no son una infraestructura pasiva. Son superficies de ataque activas.
Si no puedes responder:
- ¿Dónde se ejecuta MongoDB?
- ¿Quién puede alcanzarlo?
- ¿Quién lo está tocando ahora?
... entonces, los parches por sí solos no te salvarán.
Vectra AI le ofrece la visibilidad necesaria para responder a esas preguntas, así como la capacidad de búsqueda y detección para actuar antes de que la «pérdida de memoria» se convierta en una brecha a gran escala.