Explicación breve de la vulnerabilidad MongoBleed

 (bigdata.2minutestreaming.com)
2 puntos por GN⁺ 2025-12-30 | 1 comentarios | Compartir por WhatsApp
  • MongoBleed (CVE-2025-14847) es una grave vulnerabilidad de fuga de memoria presente en todas las versiones de MongoDB desde 2017, que permite a un atacante leer datos arbitrarios de la memoria heap de la base de datos
  • La vulnerabilidad se debe a un bug en la ruta de compresión zlib y puede explotarse sin autenticación, simplemente conectándose a la base de datos
  • Un atacante puede enviar una solicitud comprimida manipulada para hacer que el servidor asigne un búfer de tamaño incorrecto y así exponer memoria de operaciones previas (contraseñas, claves API, etc.) dentro de él
  • MongoDB distribuyó un parche el 19 de diciembre de 2025, pero las versiones EOL (3.6, 4.0, 4.2) no fueron corregidas
  • Esta vulnerabilidad, presente durante 8 años, afecta a más de 210 mil instancias de MongoDB expuestas a Internet y requiere aplicar el parche de inmediato o desactivar la compresión tanto en entornos en la nube como on-premise

Resumen de MongoBleed

  • MongoBleed (CVE-2025-14847) es una vulnerabilidad descubierta en la ruta de compresión de mensajes zlib 1 de MongoDB, y afecta a todas las versiones desde 2017
    • Un atacante puede leer datos arbitrarios de la memoria heap con solo conectarse a la base de datos, sin autenticación
    • Las versiones sin soporte (EOL) como MongoDB 3.6, 4.0 y 4.2 no fueron corregidas
  • Este bug fue introducido en un PR de mayo de 2017 y se hizo público oficialmente el 19 de diciembre de 2025
  • MongoDB anunció que aplicó el parche a todas las instancias, incluido su servicio en la nube Atlas

Estructura de comunicación de MongoDB

  • MongoDB usa su propio protocolo TCP en lugar de HTTP, y los mensajes se transmiten en formato BSON (Binary JSON)
  • Todas las solicitudes se componen con el comando OP_MSG y, cuando se comprimen, se envuelven en un mensaje OP_COMPRESSED
    • Los mensajes incluyen campos como uncompressedSize, originalOpcode y compressorId
    • uncompressedSize indica el tamaño esperado después de descomprimir

Etapa 1 del exploit — asignación incorrecta de búfer

  • El atacante configura uncompressedSize con un valor excesivamente grande respecto al real para hacer que el servidor reserve un búfer grande
    • Ejemplo: declarar un mensaje real de 1 KB como si fuera de 1 MB
  • El servidor MongoDB, después de descomprimir, no valida el tamaño real y confía en el tamaño indicado por el usuario
    • Como resultado, en memoria queda una estructura del tipo [datos reales | basura de heap no referenciada]
  • Como MongoDB está basado en C++, no inicializa la memoria, por lo que esa región puede contener datos sensibles de operaciones anteriores
    • Ejemplo: contraseñas, tokens de sesión, claves API, datos de clientes, configuraciones del sistema, etc.

Etapa 2 del exploit — filtración de datos

  • El atacante envía una entrada BSON malformada para inducir al servidor a interpretar como cadena la basura presente en memoria
    • El primer campo de BSON es una cadena y sigue la regla de C de cadena terminada en null (null-terminated string)
  • Si el atacante envía una cadena sin terminador null, el servidor sigue leyendo otros datos de memoria
    • Ejemplo: [ { "a | password: 123\0 | apiKey: jA2sa | ip: 219.117.127.202 ]
  • El servidor lo reconoce como un campo BSON inválido y responde incluyendo ese contenido en el mensaje de error
    • "errmsg": "invalid BSON field name 'a | password: 123'"
  • Repitiendo este proceso, el atacante puede escanear toda la memoria heap y recopilar información sensible

Impacto y nivel de riesgo

  • Ocurre en la etapa previa a la autenticación (pre-auth), por lo que un atacante puede acceder a datos sin iniciar sesión
  • Las instancias de MongoDB expuestas a Internet quedan en riesgo inmediato
    • Según búsquedas en Shodan, hay más de 213,000 instancias de MongoDB públicas
  • Es una vulnerabilidad que existió durante unos 8 años, de 2017 a 2025, y por su estructura simple tiene alta probabilidad de explotación real
  • MongoDB declaró que “hasta ahora no hay evidencia de explotación”, pero no publicó una disculpa oficial ni una línea de tiempo detallada

Mitigación

  • Actualizar a la versión parchada más reciente (8.0.17 o superior)
  • Como medida temporal, también puede mitigarse desactivando la compresión de red zlib
  • Para usuarios de MongoDB Atlas, el parche ya fue aplicado

Información adicional y discusión relacionada

Resumen

  • MongoBleed es una vulnerabilidad de fuga de memoria causada por un bug en el procesamiento de compresión zlib
  • Un atacante puede obtener datos de memoria previos (contraseñas, claves API, etc.) mediante solicitudes comprimidas manipuladas
  • Todas las versiones de MongoDB entre 2017 y 2025 están afectadas, y es indispensable aplicar el parche o desactivar la compresión
  • Más de 210 mil instancias expuestas a Internet son potenciales víctimas
  • MongoDB distribuyó un parche, pero se critica la falta de soporte para versiones EOL y la demora en la respuesta pública

Lecturas relacionadas

1 comentarios

 
GN⁺ 2025-12-30
Comentarios en Hacker News
  • Hace unos años modifiqué el memory allocator del runtime de Cloudflare Workers para que, al liberar memoria, sobrescribiera toda la memoria con un patrón fijo de bytes.
    Gracias a eso, la memoria no inicializada ya no conservaba datos significativos.
    Esperaba una caída de rendimiento, pero en la práctica no hubo ningún impacto medible.
    Creo que cualquiera que use lenguajes sin seguridad de memoria debería hacer esto. Este bug de Mongo también se habría podido mitigar de esta forma.
    • Las versiones recientes de macOS hacen zero-out automáticamente al liberar memoria.
      Gracias a eso mejora la eficiencia de la compresión de memoria y, en promedio, incluso mejora el rendimiento.
    • En FreeBSD, si configuras la variable de entorno MALLOC_CONF=opt.junk=free, malloc hace lo mismo.
      O sea, muchas implementaciones ya ofrecen esta función como opción.
    • En 2025, creo que todos los allocators de propósito general deberían inicializar la memoria en 0 por defecto.
      Si se necesita más rendimiento, se puede escribir un allocator personalizado para un caso específico.
      Eso también permitiría otras optimizaciones que no son posibles con el allocator del sistema.
    • OpenBSD llena la memoria recién asignada con 0xdb y la memoria liberada con 0xdf.
      Gracias a eso se pueden detectar rápido bugs de use-before-initialization o use-after-free.
      Y eso viene activado por defecto.
    • Me pregunto si esto equivale a activar la opción init_on_free=1 del kernel.
  • Parece que el autor no conocía bien el proceso interno de desarrollo de Mongo.
    Mongo desarrolla primero en un repositorio privado interno y luego mueve los commits al repositorio público mediante Copybara.
    La confusión con las fechas surgió por ese proceso.
    • Yo tampoco lo sabía. Me parecía raro que no hubiera revisión de PR, pero ahora tiene sentido.
      Voy a actualizar el artículo para explicar este hecho y la diferencia de fechas.
  • Parece que el autor entendió mal la línea de tiempo.
    Nuestros clusters de Atlas ya habían sido actualizados varios días antes de que se publicara el CVE.
    • Gracias. Ya actualicé el artículo.
  • En sistemas como las bases de datos, hacer zeroing o poisoning al liberar memoria es una buena decisión.
    Hoy en día la mayoría de los allocators deberían hacerlo por defecto.
    Chris mejoró esta parte en Blink, y el resultado se extendió a todo Chromium.
    La documentación relacionada también es interesante.
    Entrada del blog de Chromium
    Documentación de PartitionAlloc
  • Me pregunto con qué frecuencia las instancias de Mongo quedan expuestas a Internet.
    En el mundo SQL es raro, pero a veces pasa.
    • Por mi experiencia, la razón de existir de MongoDB es la “pereza”.
      La filosofía es no tener que preocuparse por nada: esquema, durabilidad, lecturas/escrituras, conectividad, etc.
      Así que no sorprende que tampoco se preocupen por la seguridad.
    • Las 3 organizaciones “serias” que conozco usan Mongo para evitar diseñar esquemas.
      Esa actitud lleva a pensar “que sea cómodo ahorita mismo”, y al final termina en problemas de seguridad como instancias de BD expuestas públicamente.
    • Estos comentarios me parecen demasiado extremos.
      En la práctica, lo común es usar SQL y NoSQL juntos.
      NoSQL tiene fortalezas en alta disponibilidad para grandes volúmenes de datos, y SQL es adecuado para almacenar datos relacionales.
      Por ejemplo, iMessage y el sistema de matchmaking de EA también usan NoSQL.
      Al final se necesitan ambos. No compiten; se complementan.
    • Según los resultados de búsqueda en Shodan, hay 213 mil instancias de Mongo expuestas.
    • Exponer un servidor SQL puede traer consecuencias todavía peores.
      Por ejemplo, PostgreSQL con la configuración por defecto puede obtener privilegios sobre todo el sistema.
      Por eso la mayoría de la gente conoce bien el riesgo de tener servidores SQL públicos.
  • MongoDB anunció el 24 de diciembre que “no había evidencia de explotación del CVE”, pero no hay que olvidar que “la ausencia de evidencia no es evidencia de ausencia”.
    • Entonces, ¿qué crees que deberían haber dicho?
  • No entiendo por qué siguen usando Mongo.
    • La replicación es sencilla y es más rápido que JSONB de Postgres.
      Personalmente preferiría no usarlo, pero hay casos en los que DynamoDB o MongoDB sí encajan técnicamente.
    • También está el chiste de que se usa porque es “web scale”.
      Video relacionado
    • Antes NoSQL estaba de moda, pero al final todo terminó reduciéndose a una simple base de datos key-value.
    • Esa lógica me parece demasiado agresiva como para aceptarla.
  • Esto me recuerda el optimismo de pensar que el OWASP Top 10 va a resolver las principales vulnerabilidades.
    Pero los buffer overflows siguen existiendo desde 2003.
    • Al final fue como ponerle un footgun en las manos a todo el mundo.
      Este tipo de problema va a repetirse para siempre, a menos que se bloquee desde el lenguaje.
      Mis condolencias para los desarrolladores de Mongo.
  • Cada vez que sale un artículo sobre NoSQL, queda claro que muchos “desarrolladores” nunca han manejado tráfico a gran escala.
    • Esta vez parece que solo te pasa a ti.
  • MongoDB siempre fue bastante malo… pero le decían “webscale”.
    Creo que sería mejor usar ToroDB o JSONB de PostgreSQL.