MongoDB ha parcheado un fallo crítico, rastreado como CVE-2026-118383, que puede permitir que un atacante remoto sin inicio de sesión bloquee un servidor de base de datos utilizando dos simples solicitudes de ping. El error tiene una puntuación CVSS v4.0 de 9.5.

Se encuentra en el código de replicación que se ejecuta cuando un nuevo servidor primario termina de ponerse al día. MongoDB anunció la solución el 10 de noviembre de 2026, y dijo que encontró el problema internamente. La empresa afirmó que no tiene conocimiento de intentos de aprovecharlo.

Vulnerabilidad de bloqueo de base de datos de MongoDB

El aviso de GitHub describe un error de use-after-free (uso después de liberar). Esto significa que el programa sigue utilizando una parte de la memoria después de que ya ha sido liberada.

El aviso indica que las solicitudes que no requieren autenticación pueden activar esta condición. El resultado puede ser un cierre repentino del servidor. Bajo algunas condiciones, también podría producirse la ejecución de código arbitrario dentro del proceso del servidor.

Solo se ven afectados los miembros del conjunto de réplicas. Esto incluye los miembros del servidor de configuración y del fragmento (shard) en clústeres fragmentados. Una instancia de mongod independiente no ejecuta el paso de ponerse al día, por lo que está a salvo de este error.

Investigadores de Datadog Security Labs explicaron la cadena. Cuando un miembro de un conjunto de réplicas gana una elección, primero aplica las escrituras que perdió. Solo entonces acepta nuevas. El error reside en la limpieza al final de ese paso.

Los servidores vulnerables aceptan un comando de ping antes del inicio de sesión. Un atacante envía dos de ellos con un valor de readConcern.afterOpTime. Cada uno deja una notificación pendiente, que MongoDB llama "waiter" (esperador). Estos "waiters" no hacen nada al principio. Permanecen en su lugar hasta que el miembro se reinicia, retrocede o deja su cargo.

El bloqueo necesita otras dos cosas que el atacante no puede controlar. Un miembro debe quedarse rezagado, y ese mismo miembro debe ganar entonces una elección. Esto puede ocurrir durante un mantenimiento o una interrupción del servicio.

Cuando termina el proceso de ponerse al día, la limpieza se ejecuta dos veces y toca la memoria liberada. Entonces el servidor se bloquea antes de realizar cualquier escritura. Activar la autenticación no detiene el primer paso.

Datadog construyó un conjunto de réplicas de cuatro miembros y forzó el retraso y la conmutación por error por su cuenta. En MongoDB 8.0.34, con ambas solicitudes de ping enviadas, el nuevo primario registró un fallo de segmentación y el proceso se bloqueó.

Sin las solicitudes, la misma conmutación por error funcionó correctamente. En la versión parcheada 8.0.37, el servidor rechazó ambas solicitudes como "No autorizadas" y siguió funcionando.

El equipo no logró la ejecución de código. También advirtió que su tiempo de prueba de aproximadamente 40 segundos no dice nada sobre la velocidad en el mundo real. El atacante no puede ver ni elegir la ventana de tiempo, razón por la cual la calificación CVSS clasifica la complejidad del ataque como alta.

Las versiones corregidas de MongoDB son 9.0.7, 8.3.16, 8.0.37, 7.0.48, 6.0.30, 5.0.35 y 4.4.32. Los clústeres de Atlas se actualizan durante el mantenimiento. MongoDB insta a los clientes que pospusieron el mantenimiento a aplicar la actualización pronto.

Si administras tus propios servidores, debes comprobar la versión en cada miembro, incluidos los contenedores y nodos que estuvieron fuera de línea durante el parcheo.

Si no puedes actualizar inmediatamente, limita el acceso de red a los sistemas que realmente lo necesiten. Esto reduce quién puede enviar las solicitudes de ping, pero no soluciona el error.

Un primario bloqueado puede dejar a un clúster sin un escritor hasta que otro miembro tome el control. En la prueba de Datadog, el clúster se quedó sin un primario.

Datadog aconseja revisar los registros estructurados del servidor en busca de entradas de consultas lentas de comandos ping que incluyan readConcern.afterOpTime y una espera expirada.

Busca también algún miembro que salga del proceso de ponerse al día dos veces en una sola transición, seguido de una señal fatal que mencione CatchupState::abort_inlock(). La configuración de los registros decide si estos campos aparecen, así que confirma que tus registros conserven el comando completo.

Este no es el primer problema de MongoDB previo al inicio de sesión este año. Se cubrió el CVE-2026-25611, un error de compresión que permitía a usuarios no autenticados bloquear servidores utilizando poco ancho de banda.

También se cubrió MongoBleed, el fallo de fuga de memoria que fue explotado activamente poco después de su divulgación. MongoBleed muestra lo rápido que se mueven los atacantes una vez que los detalles son públicos.

Deberías parchear este último fallo antes de que eso ocurra de nuevo, y deberías mantener los puertos de la base de datos fuera del internet abierto. La entrada de la NVD para CVE-2026-118383 contiene el registro oficial, y los tickets de seguimiento de MongoDB son SERVER-138119 y SERVER-138175.