A finales de diciembre de 2025 se hizo pública MongoBleed (CVE-2025-14847), una vulnerabilidad de divulgación de memoria en MongoDB Server que recuerda, por su mecánica y su nombre, al célebre Heartbleed de OpenSSL. El 29 de diciembre la agencia estadounidense CISA confirmó su explotación activa y la añadió a su catálogo de Vulnerabilidades Explotadas Conocidas (KEV), fijando como plazo de parcheo para las agencias federales el 19 de enero de 2026.
Qué es la vulnerabilidad
El fallo reside en cómo MongoDB Server procesa los paquetes de red cuando la compresión zlib está habilitada (una configuración por defecto en muchos despliegues). La descripción oficial del NVD es precisa: “campos de longitud no coincidentes en las cabeceras del protocolo comprimido con zlib pueden permitir la lectura de memoria heap no inicializada por parte de un cliente no autenticado”.
Dicho de otro modo: un atacante envía mensajes comprimidos manipulados con un campo de longitud manipulado, y el servidor responde devolviendo trozos de memoria del proceso que no debería exponer. Es un patrón clásico de over-read de memoria, idéntico en espíritu a Heartbleed.
A quién afecta
La vulnerabilidad afecta a un rango muy amplio de versiones de MongoDB Server, incluidas las ramas 4.4, 5.0, 6.0, 7.0, 8.0 y 8.2. Las versiones corregidas son 4.4.30, 5.0.32, 6.0.27, 7.0.28, 8.0.17 y 8.2.3 y posteriores. La condición clave es tener la compresión zlib activa y el puerto de MongoDB accesible desde la red.
La exposición es masiva: Shadowserver localizó más de 74.000 instancias expuestas y Censys rastreó más de 87.000 direcciones IP potencialmente vulnerables. Según Wiz, el 42 % de los sistemas cloud visibles tenían al menos una instancia de MongoDB en una versión afectada.
Gravedad
Está clasificada como alta, con una puntuación CVSS 4.0 de 8.7 (y 7.5 en CVSS 3.1). El vector confirma lo peligroso del caso: explotable por red (AV:N), de baja complejidad (AC:L), sin autenticación (PR:N) y sin interacción del usuario (UI:N), con alto impacto en confidencialidad.
El peligro real está en lo que se puede extraer de esa memoria filtrada: credenciales, claves de API y de nube, tokens de sesión, logs internos y datos personales (PII). Un investigador de Elastic publicó una prueba de concepto que demuestra la fuga de datos sensibles de hosts sin parchear, lo que eleva el riesgo de explotación generalizada.
Mitigación y parche
MongoDB corrigió el fallo el 19 de diciembre de 2025. La recomendación principal es actualizar a las versiones parcheadas indicadas arriba. Si la actualización inmediata no es viable, la mitigación temporal es deshabilitar la compresión zlib en el servidor, lo que cierra el vector de ataque.
Como medidas adicionales conviene aplicar siempre el principio de mínima exposición: no exponer el puerto de MongoDB directamente a Internet, restringir el acceso por firewall y red, y exigir autenticación. Dado que existe explotación activa y PoC público, este parche debe tratarse como prioritario en cualquier inventario.