Recientemente se ha descubierto una vulnerabilidad de alta puntuación en el conocido sistema de bases de datos NoSQL, MongoDB. Esta vulnerabilidad ha sido apodada como “MongoBleed” y se le ha asignado el identificador de vulnerabilidad CVE-2025-14847.
En esencia, este riesgo de seguridad es comparable en impacto al histórico Heartbleed, ya que posibilita la extracción de datos sensibles residentes en la memoria del servidor que exponga este servicio. Esto incluye la posible sustracción de credenciales, tokens de sesión o información confidencial de clientes.
¿De qué trata MongoBleed?
El CVE-2025-14847, también conocido como MongoBleed, es una vulnerabilidad de lectura de memoria no autenticada que reside en la implementación del protocolo de compresión zlib del servidor de MongoDB. El fallo ocurre específicamente en la lógica de descompresión de mensajes en las peticiones, cuando el servidor procesa una solicitud comprimida malformada, calcula incorrectamente la longitud de los datos. Como resultado, el servidor devuelve fragmentos de memoria dinámica (heap) no inicializada.
Esto lo podemos observar en el commit https://github.com/mongodb/mongo/commit/505b660a14698bd2b5233bd94da3917b585c5728 que da solución a este problema, en el cuál se modifica el fichero message_compressor_zlib.cpp para que devuelva únicamente la longitud real de los datos descomprimidos, en vez de la totalidad de los datos almacenados en memoria.
Lo interesante de este error es que se produce antes de que se verifique la autenticación, provocando que cualquier instancia de MongoDB expuesta a Internet (o accesible dentro de una red interna) pueda ser atacada por cualquier persona sin necesidad de usuario ni contraseña. Al explotarlo, el atacante recibe «trozos» aleatorios de la memoria del servidor, que podrían contener datos residuales de otras consultas recientes, claves de cifrado o contraseñas en texto plano.
Esta vulnerabilidad afecta a una amplia gama de versiones de MongoDB Server, desde ramas antiguas hasta las más recientes, incluyendo las series 4.4, 5.0, 6.0, 7.0 y 8.0, a menos que se hayan aplicado los parches de seguridad liberados a finales de diciembre de 2025.
El impacto de esta vulnerabilidad
La vulnerabilidad ha sido catalogada con una severidad Alta según el sistema de puntuación estándar, alcanzando una nota base de 8.7 en la escala CVSS. Esta clasificación responde a que el fallo es explotable de forma remota a través de la red y no requiere privilegios ni interacción por parte del usuario, aunque su impacto se limita principalmente a la confidencialidad de los datos y no afecta directamente a la integridad o disponibilidad del sistema en primera instancia.
El riesgo principal de este CVE reside en la exposición de la memoria dinámica del servidor. Al enviar paquetes malformados, un atacante no autenticado puede recuperar fragmentos de datos residentes en la memoria, lo que podría incluir información altamente sensible como tokens de sesión, credenciales en texto plano o claves de cifrado utilizadas por la base de datos. La disponibilidad pública de pruebas de concepto funcionales facilita la automatización de este ataque contra instancias expuestas.
A día de la redacción de esta noticia, se pueden utilizar buscadores especializados para comprobar que existen más de 80000 servidores de MongoDB expuestos a internet que utilizan versiones vulnerables.
Soluciones y recomendaciones
La solución principal consiste en actualizar el servidor de MongoDB a las versiones parcheadas proporcionadas por el fabricante. Las versiones seguras que corrigen el manejo de zlib son:
- MongoDB 8.2.x: Actualizar a 8.2.3 o superior.
- MongoDB 8.0.x: Actualizar a 8.0.17 o superior.
- MongoDB 7.0.x: Actualizar a 7.0.28 o superior.
- MongoDB 6.0.x: Actualizar a 6.0.27 o superior.
- MongoDB 5.0.x: Actualizar a 5.0.32 o superior.
- MongoDB 4.4.x: Actualizar a 4.4.30 o superior.
También se aconseja limitar el acceso a la red donde se encuentra la instancia del servidor de MongoDB. En la mayoría de los casos no es necesaria su exposición a internet y, si lo fuera, se deberían implementar reglas de enrutamiento para aceptar conexiones solo desde direcciones IP o dominios que sean de confianza.
Adicionalmente, se recomienda rotar cualquier credencial, clave de API o certificado que pudiera haber estado en uso en el servidor afectado, asumiendo que podrían haber sido comprometidos antes del parcheado.
Más información
– CVE-2025-14847 Detail https://nvd.nist.gov/vuln/detail/CVE-2025-14847
– CVE-2025-14847 https://www.incibe.es/incibe-cert/alerta-temprana/vulnerabilidades/cve-2025-14847
– Vulnerability Bulletins CVE-2025-14847 https://www.ccn-cert.cni.es/en/component/vulnerabilidades/view/48485.html?search=act&Itemid=11904
Deja una respuesta