Una vulnerabilidad grave que afecta a múltiples versiones de MongoDB, denominada MongoBleed (CVE-2025-14847), se está explotando activamente en la naturaleza, con más de 80.000 servidores potencialmente vulnerables expuestos en la web pública.
Se encuentran disponibles un exploit público y los detalles técnicos que lo acompañan, que muestran cómo los atacantes pueden activar la falla para extraer de forma remota secretos, credenciales y otros datos confidenciales de un servidor MongoDB expuesto.
A la vulnerabilidad se le asignó una puntuación de gravedad de 8,7 y se ha tratado como una «solución crítica», con un parche disponible para instancias de autohospedaje desde el 19 de diciembre.
Explotar secretos de filtraciones
La vulnerabilidad MongoBleed surge de cómo el servidor MongoDB maneja los paquetes de red procesados por la biblioteca zlib para una compresión de datos sin pérdidas.
Investigadores de Ox Security explicar que el problema se debe a que MongoDB devuelve la cantidad de memoria asignada al procesar mensajes de red en lugar de la longitud de los datos descomprimidos.
Un actor de amenazas podría enviar un mensaje con formato incorrecto afirmando un tamaño mayor cuando se descomprime, lo que provocaría que el servidor asigne un búfer de memoria más grande y filtrara al cliente datos en memoria con información confidencial.
El tipo de secretos filtrados de esta manera podría variar desde credenciales, API y/o claves de nube, tokens de sesión, información de identificación personal (PII), registros internos, configuraciones, rutas y datos relacionados con el cliente.
Debido a que la descompresión de los mensajes de red ocurre antes de la etapa de autenticación, un atacante que explote MongoBleed no necesita credenciales válidas.
El exploit público, lanzado como prueba de concepto (PoC) denominado «MongoBleed» por el investigador de seguridad de Elastic. Joe De Simoneestá creado específicamente para filtrar datos confidenciales de la memoria.
El investigador de seguridad Kevin Beaumont dice que el código de explotación PoC es válido y que solo requiere «una dirección IP de una instancia de MongoDB para comenzar a descubrir en la memoria cosas como contraseñas de bases de datos (que son texto sin formato), claves secretas de AWS, etc.»
fuente: Kevin Beaumont
Según la plataforma Censys para el descubrimiento de dispositivos conectados a Internet, al 27 de diciembre existían más de 87.000 instancias de MongoDB potencialmente vulnerables expuestos en la red pública de Internet.
Se observaron casi 20.000 servidores MongoDB en Estados Unidos, seguido de China con casi 17.000 y Alemania con poco menos de 8.000.
fuente: Censys
Explotación y detección
El impacto en todo el entorno de la nube también parece ser significativo, ya que los datos de telemetría de la plataforma de seguridad en la nube Wiz mostraron que el 42% de los sistemas visibles «tienen al menos una instancia de MongoDB en una versión vulnerable a CVE-2025-14847».
Los investigadores de Wiz señalan que los casos que observaron incluyeron tanto recursos internos como expuestos públicamente. La empresa dice que observó la explotación de MongoBleed (CVE-2025-14847) en estado salvaje y recomienda que las organizaciones den prioridad a la aplicación de parches.
Si bien no están verificados, algunos actores de amenazas afirman haber utilizado la falla MongoBleed en una reciente de incumplimiento de Ranbow Six Siege de Ubisoft plataforma en línea.
El cofundador de Recon InfoSec, Eric Capuano, advierte que la aplicación de parches es sólo una parte de la respuesta al problema de MongoBleed y aconseja a las organizaciones que también comprueben si hay signos de compromiso.
En una publicación de blog ayer, el investigador explica un método de detección que incluye buscar “una IP de origen con cientos o miles de conexiones pero cero eventos de metadatos”.
Sin embargo, Capuano advierte que la detección se basa en el código de explotación de prueba de concepto actualmente disponible y que un atacante podría modificarlo para incluir metadatos de cliente falsos o reducir la velocidad de explotación.
Florian Roth, el creador del escáner THOR APT y miles de reglas YARA, utilizó la investigación de Capuano para crear el detector de sangrado Mongo – una herramienta que analiza los registros de MongoDB e identifica la posible explotación de la vulnerabilidad CVE-2025-14847.
Herramientas de compresión seguras y sin pérdidas
MongoDB abordó la vulnerabilidad MongoBleed hace diez días, con una fuerte recomendación para que los administradores actualicen a una versión segura (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 o 4.4.30).
El proveedor advierte que una gran lista de versiones de MongoDB se ven afectadas por MongoBleed (CVE-2025-14847), algunas versiones heredadas lanzadas a finales de 2017 y algunas tan recientes como noviembre de 2025:
- MongoDB 8.2.0 a 8.2.3
- MongoDB 8.0.0 a 8.0.16
- MongoDB 7.0.0 a 7.0.26
- MongoDB 6.0.0 a 6.0.26
- MongoDB 5.0.0 a 5.0.31
- MongoDB 4.4.0 a 4.4.29
- Todas las versiones de MongoDB Server v4.2
- Todas las versiones de MongoDB Server v4.0
- Todas las versiones de MongoDB Server v3.6
Los clientes de MongoDB Atlas, el servicio de base de datos multinube totalmente gestionado, recibió el parche automáticamente y no es necesario realizar ninguna acción.
MongoDB dice que no existe ninguna solución para la vulnerabilidad. Si no es posible pasar a una nueva versión, el proveedor recomienda que los clientes deshabiliten la compresión zlib en el servidor y proporciona instrucciones sobre cómo hacerlo.
Las alternativas seguras para la compresión de datos sin pérdidas incluyen Zestándar (zstd) y Rápido (anteriormente Zippy), mantenido por Meta y Google, respectivamente.
La IAM rota no es sólo un problema de TI: el impacto se extiende a toda su empresa.
Esta guía práctica cubre por qué las prácticas tradicionales de IAM no logran mantenerse al día con las demandas modernas, ejemplos de cómo es un «buen» IAM y una lista de verificación simple para construir una estrategia escalable.
