MongoDB corrige una vulnerabilidad crítica sin autenticación que afecta a los replica sets

0 0 votos

Valora la Publicación

MongoDB publicó el 10 de noviembre parches para CVE-2026-118383, una vulnerabilidad crítica (CVSS 9.5 sobre 10) que se dispara con pedidos que no necesitan usuario ni contraseña. Afecta a los miembros de un replica set en todas las ramas con soporte, de la 4.4 a la 9.0.

En el peor caso, el servidor que acaba de quedar como primario se cae y el cluster se queda sin quién acepte escrituras. MongoDB dice que, en ciertas condiciones, también podría ejecutarse código en el servidor. La empresa encontró la falla con su propio programa de seguridad y dice que no conoce intentos de explotarla.

Qué es un replica set y por qué importa acá

Un replica set es un grupo de servidores MongoDB con copias de los mismos datos. Uno es el primario, el único que recibe escrituras; los demás son secundarios que van copiando lo que hace el primario.

Si el primario se cae, los secundarios votan uno nuevo (una elección). Es la configuración estándar de cualquier MongoDB en producción, y también la base de los clusters con sharding: cada shard y los config servers son replica sets. Por eso la falla alcanza a casi todas las instalaciones serias. Según el registro oficial del CVE, un mongod standalone (un solo servidor, sin réplicas) no está afectado.

Cómo funciona la falla

Es un use-after-free: el programa libera un pedazo de memoria y después lo vuelve a usar como si siguiera siendo suyo. Ese tipo de error puede tirar el proceso o, si alguien controla lo que queda en esa memoria, desviar lo que ejecuta.

El análisis de Datadog Security Labs lo reprodujo así:

Un cliente sin autenticación manda dos comandos ping con un valor readConcern.afterOpTime. Las versiones vulnerables aceptan ping antes del login.
Cada pedido deja una espera pendiente en el servidor, que sigue ahí hasta que el miembro se reinicia, hace rollback o deja de ser primario.
Si más tarde ese miembro estaba atrasado respecto de otro y gana una elección, al terminar de ponerse al día (el catch-up) limpia esas esperas dos veces sobre memoria ya liberada.
El nuevo primario se cae antes de aceptar escrituras.

El atacante no puede forzar la elección ni saber cuándo pasa: tiene que esperar a que el cluster tenga un failover por su cuenta. Por eso el puntaje marca complejidad alta. Datadog logró la caída en laboratorio, pero no la ejecución de código. Ya hay una prueba de concepto pública en GitHub.

Versiones afectadas y corregidas

Según el registro del CVE, están afectadas todas las versiones de cada rama desde su primera publicación hasta la corregida:

Rama 9.0: corregida en 9.0.7.
Rama 8.3: corregida en 8.3.16.
Rama 8.0: corregida en 8.0.37.
Rama 7.0: corregida en 7.0.48.
Rama 6.0: corregida en 6.0.30.
Rama 5.0: corregida en 5.0.35.
Rama 4.4: corregida en 4.4.32.

La rama 8.2 no figura en la lista y llegó al fin de soporte el 31 de julio. Una prueba de concepto publicada en GitHub reporta que la 8.2.12 mostró el error en un laboratorio con una opción de testing, así que quien siga en 8.2 tiene un motivo más para pasar a 8.3 u 8.0.

En MongoDB Atlas, el servicio administrado, los clusters se actualizan solos en la ventana de mantenimiento. El aviso de MongoDB pide a quien esté postergando ese mantenimiento que lo aplique cuanto antes.

Qué hacer

Actualizar cada miembro del replica set a la versión corregida de su rama, incluidos los shards, los config servers, los que corren en contenedores y los que estaban apagados durante el último mantenimiento.
Confirmar la versión que corre en cada miembro con db.version() desde mongosh, no la que dice el inventario.
Mientras tanto, limitar por red quién llega al puerto de MongoDB (por defecto 27017) solo a las aplicaciones que lo necesitan. Reduce quién puede mandar los pedidos, pero no corrige la falla.
En Atlas, revisar si hay mantenimiento postergado y aplicarlo.
Si usan una distribución de terceros (Percona, paquetes de la distribución de Linux, imágenes de contenedores), verificar que su versión incluya el arreglo.

Qué buscar en los logs

Datadog publicó señales para detectar intentos. Pueden aparecer bastante antes de la caída, así que conviene mirar logs viejos también:

Eventos COMMAND lentos (id 51803) de clientes sin autenticar, con tiempos de read concern raros y errores MaxTimeMSExpired.
Un miembro que entra en catch-up (id 21359), sale dos veces en la misma transición (id 21363) y después registra una señal fatal con CatchupState::abort_inlock().

El detalle depende de la configuración de logs: el muestreo de operaciones lentas puede omitir los campos del comando, y la dirección del cliente puede aparecer como local si hay un proxy en el medio.

¿Saben quién puede llegar al puerto de sus bases?

Esta falla no pide credenciales: alcanza con llegar por red al servidor. ¿Ya revisaron qué sistemas tienen acceso a sus replica sets y en qué versión está cada miembro? Te leemos en los comentarios.

Fuentes

Escrito por

Pablo Ariel Di Loreto

Profesor. Informático. Fanático del helado de dulce de leche. Director de Ingeniería en MODO, y Secretario del Microsoft Users Group Asociación Civil. Además, soy owner de iniciativas como ConoSurTech y Aprender IT.

Ver todas las entradas de Pablo Ariel Di Loreto →