Se descubrió una vulnerabilidad crítica (CVE-2026-118383) en MongoDB que permite a un atacante no autenticado provocar la caída del servidor mediante dos solicitudes específicas. El fallo ocurre cuando un servidor afectado es elegido como primario en un conjunto de réplicas, pudiendo causar corrupción de memoria o ejecución de código. MongoDB ya lanzó versiones corregidas y recomienda actualizar todos los miembros del clúster inmediatamente.







Un fallo crítico en MongoDB Server permite que un atacante no autenticado envíe dos solicitudes que provocan la caída del servidor de la base de datos. El colapso ocurre solo si ese servidor es elegido posteriormente para asumir el rol de servidor principal mientras aún carece de algunos cambios recientes.

MongoDB, la empresa que fabrica la base de datos, lanzó versiones corregidas a principios de esta semana.

Los servidores afectados son miembros de un conjunto de réplicas, un grupo de servidores MongoDB que mantienen copias de los mismos datos. Un miembro, el primario, actúa como servidor principal y gestiona todas las nuevas escrituras, mientras que los demás las replican. Si el primario deja de estar disponible, los otros miembros celebran una elección para elegir un nuevo primario.

Investigadores de Datadog Security Labs reprodujeron la caída en un laboratorio y publicaron sus hallazgos ayer. En versiones vulnerables, activar la autenticación no detiene las dos solicitudes. Un atacante no puede hacer que el miembro objetivo se retrase o gane una elección, ni ver cuándo ocurre ninguna de las dos cosas, según los investigadores.

El fallo, rastreado como CVE-2026-118383, es un error de tipo use-after-free: el servidor termina utilizando memoria que ya ha liberado. MongoDB lo calificó con un 9.5 sobre 10 en la escala de severidad CVSS 4.0. La empresa afirmó que ella misma encontró el fallo y que "no tiene conocimiento de ningún intento de aprovechar esta vulnerabilidad".

Los miembros afectados incluyen los miembros del servidor de configuración y fragmentación (shard) de los clústeres fragmentados. Un mongod independiente, un único servidor fuera de cualquier conjunto de réplicas, no se ve afectado.

Cada rama afectada tiene una versión corregida, enumerada a continuación y en el registro del CVE https://www.cve.org/CVERecord?id=CVE-2026-118383. Todas las versiones anteriores de una rama están afectadas, hasta la primera versión de dicha rama.

Los clústeres de MongoDB Atlas reciben automáticamente las versiones corregidas durante el mantenimiento, informó la empresa en su anuncio de seguridad https://www.mongodb.com/community/forums/t/important-mongodb-security-update-available-action-required-november-10-2026/344843. Los clientes que pospongan el mantenimiento deben aplicar la actualización lo antes posible.

Los despliegues autogestionados necesitan la versión corregida en cada miembro del conjunto de réplicas. Después de actualizar, verifica la versión que ejecuta cada miembro, incluidos los miembros en contenedores y cualquiera que haya estado fuera de línea durante el mantenimiento.

La rama 8.2 no se encuentra entre las versiones afectadas enumeradas, y su versión más reciente es la 8.2.12. Pero una prueba de concepto publicada en GitHub informa que la 8.2.12 todavía presentaba el error en una prueba de laboratorio utilizando una configuración solo de prueba.

La rama 8.2 llegó al final de su vida útil el 31 de julio, según el calendario de ciclo de vida de la empresa https://www.mongodb.com/legal/support-policy/lifecycles. Después de esa fecha, una versión ya no recibe correcciones, incluidas las de seguridad.

Hasta que un miembro pueda ser actualizado, los investigadores aconsejan restringir el acceso de red a la base de datos únicamente a los sistemas que lo necesiten. Eso limita quién puede enviar las dos solicitudes, pero no soluciona el fallo.

Análisis técnico del fallo

Un miembro que gana una elección primero se pone al día aplicando las escrituras que perdió antes de aceptar nuevas. El fallo está en la limpieza que se ejecuta cuando termina este paso de puesta al día, según el análisis técnico de los investigadores de Datadog https://securitylabs.datadoghq.com/articles/cve-2026-118383-mongodb-server-use-after-free/.

Las dos solicitudes son comandos ping que llevan un valor readConcern.afterOpTime. Cada una pide al servidor que espere hasta que la replicación llegue a un punto determinado, y el servidor registra una notificación pendiente para ello, llamada "waiter".

Plantar los "waiters" no provoca la caída del servidor. Estos no caducan y permanecen en su lugar hasta que el miembro se reinicia, vuelve atrás o deja de ser el primario.

La caída requiere que el miembro que recibió las solicitudes gane una elección posterior, aunque esté retrasado respecto a otro miembro. Cuando termina la puesta al día, la limpieza se ejecuta dos veces, reutilizando memoria que ya había sido liberada, y el nuevo primario colapsa antes de aceptar cualquier escritura. Una vez cumplidas esas condiciones, la caída no depende de ganar una carrera de tiempo, dijeron los investigadores.

En el laboratorio, los investigadores hicieron que el miembro se retrasara y forzaron un failover ellos mismos utilizando acceso de administrador para pausar y detener los procesos mongod. Solo las dos solicitudes provinieron de un cliente sin credenciales, y ese cliente no podía escribir en la base de datos.

En la versión 8.0.34, el miembro colapsó con un fallo de segmentación, dejando el clúster del laboratorio sin un primario. Otro despliegue podría elegir un nuevo primario y seguir funcionando.

En la versión corregida 8.0.37, el servidor rechazó ambas solicitudes como no autorizadas a la vez, y el miembro siguió funcionando. Una parte de la corrección permite que solo los usuarios del sistema utilicen readConcern.afterOpTime.

MongoDB dice que el fallo también podría resultar en la ejecución de código arbitrario en el proceso del servidor bajo ciertas condiciones. Sin embargo, en el laboratorio, "no logramos la ejecución de código", dijeron los investigadores. Sus resultados tampoco muestran con qué frecuencia funcionaría el ataque en otras configuraciones.

El código de prueba de concepto https://github.com/googlesky/CVE-2026-118383 reproduce el error en un conjunto de réplicas de laboratorio, según su autor. Su modo fiable requiere una configuración solo de prueba que un atacante remoto no puede habilitar. Su impacto declarado es una caída o corrupción de memoria, sin afirmar la ejecución de código.

La segunda parte de la corrección evita que la limpieza se ejecute dos veces incluso cuando ya hay "waiters" instalados, dijeron los investigadores. Ellos mismos no probaron esa parte.

En la prueba de laboratorio de la prueba de concepto, que se ejecutó con la autenticación desactivada, la versión corregida 8.0.37 aceptó los "waiters" plantados pero ejecutó la limpieza solo una vez.

Para buscar la plantación de "waiters" o una caída, revisa los registros estructurados del servidor en busca de estas señales de la ejecución vulnerable de los investigadores:

• * Evento de registro: una entrada de comando "Slow query" (ID 51803) para un ping no autenticado que lleva readConcern.afterOpTime y terminó con MaxTimeMSExpired.
• * Evento de registro: un miembro entrando en la puesta al día del primario (ID 21359), y luego saliendo de ella dos veces (ID 21363) en una sola transición.
• * Evento de registro: una señal fatal o backtrace que involucre a CatchupState::abort_inlock() después de esas salidas.

Una elección normal o una única salida de puesta al día no indican este fallo. Las solicitudes también pueden llegar antes del failover, así que revisa también los registros anteriores del mismo miembro.

Si los campos de la solicitud se registran o no depende de la configuración de registro, y el campo attr.remote puede mostrar una dirección de bucle invertido (loopback) en lugar de la IP real del cliente.

Fuente:
THN