Restaurar un volcado ajeno te puede crear una cuenta root

El 3 de noviembre de 2026, MongoDB publicó cuatro avisos de seguridad de golpe. Ninguno de los cuatro se parchea en tu base de datos. Los cuatro se arreglan actualizando las Database Tools a la versión 100.20.1: ese puñado de binarios de línea de comandos —mongodump, mongorestore, mongofiles, mongoimport— que no vive en el servidor, sino en el portátil de quien restaura, en la imagen del contenedor que hace la copia de noche y en el jump host por el que entra todo el mundo. Tu clúster puede estar al día y tener las cuatro.

Lo que dice el aviso, sin adornos

El grave de los cuatro es CVE-2026-119675, y conviene leerlo tal cual porque la frase corta no se sostiene sola. Según la descripción publicada, mongorestore «trata de forma inconsistente el prefijo system.buckets. al validar nombres de colección en un volcado no confiable», y por eso «un nombre de colección especialmente construido puede saltarse las protecciones de colecciones especiales y los filtros de espacio de nombres del operador, haciendo que una restauración cree una cuenta de base de datos no autorizada y elegida por el usuario, incluyendo una cuenta con el rol root».

El changelog del proyecto es más explícito que el aviso sobre el mecanismo. El ticket que lo cierra se titula, literalmente, «mongorestore should reject crafted collection names that resolve to $admin.system.auth collections». El nombre no acababa en una colección cualquiera: acababa resolviendo en la colección donde Mongo guarda los usuarios. No hay escalada de privilegios ni explotación de memoria: el fichero trae documentos, la herramienta los escribe donde le dicen, y donde le dicen es el padrón de cuentas.

Hay dos condiciones y las dos importan. La primera, que el volcado venga de fuera de tu control. La segunda, que quien restaura lo haga «con credenciales con privilegios suficientes de gestión de usuarios en el despliegue de destino». Ninguna de las dos es exótica. La mayoría de la gente restaura con la cuenta que tiene a mano, y la que tiene a mano suele ser la que lo puede todo.

Las otras tres son la misma idea

Las cuatro se publicaron el mismo día, a la misma hora, y todas se cierran en 100.20.1. Las puntuaciones son las que les asignó MongoDB como CNA, en las dos versiones del baremo:

La columna de la derecha tiene una rareza: en este mismo lote, del mismo fabricante y del mismo día, las dos versiones del baremo se contradicen en sentidos opuestos. La de mongorestore es un 5,2 en CVSS 4.0 y un 8,6 en 3.1; la de mongofiles, un 5,9 en 4.0 y un 4,8 en 3.1. Quien filtre por «a partir de 7» verá una, dos o ninguna según de dónde saque el número.

De las tres menores, la que da más vértigo operativo es CVE-2026-119674, un 2,1 raquítico: mongorestore descodifica mal el nombre original de una colección cuando el nombre del fichero del volcado se ha truncado, y los documentos acaban en una colección distinta de la prevista. El aviso añade dos consecuencias que ningún número de dos cifras transmite: «cuando los dos nombres de colección resuelven al mismo destino, los documentos respaldados pueden omitirse» y «el uso de --drop también puede reemplazar la colección de destino no prevista». Traducido: una restauración que termina sin error, con datos que faltan, y un --drop que se lleva por delante algo que no ibas a tocar.

La de mongofiles (CVE-2026-119672) es casi elegante por lo pequeña. Al recuperar un fichero por su identificador (get_id), la herramienta usa como destino de salida el nombre de fichero que está guardado en la base de datos, si no le pasas --local. Quien pueda editar esos metadatos pone como nombre un guion, y la siguiente descarga legítima ya no escribe un fichero: escribe por salida estándar. Si esa salida se está capturando en algún sitio al que el atacante llega —el log de un pipeline, por ejemplo—, se lleva el contenido. Un guion. Y arrastra desde la versión 3.1.4, de una numeración anterior a que estas herramientas se separaran en la serie 100.x.

La confianza iba en el sentido contrario

Estamos acostumbrados a pensar la seguridad de una base de datos en una sola dirección: el servidor desconfía del cliente, le pide credenciales, le limita los roles. Estas cuatro van al revés. Aquí el cliente se cree lo que le llega del otro lado: un nombre de colección escrito dentro de un fichero, un nombre de fichero devuelto por el servidor, un guion que resulta que significa «escribe por pantalla». La herramienta hace de intérprete entre dos mundos y se fía del que no debería.

Esa lectura no es nuestra deducción: está en el changelog de 100.20.1, publicado el 2 de noviembre de 2026, un día antes de los avisos. Entre las tareas cerradas hay tres arreglos de seguridad que no llevan CVE asignada. El tercero explica por qué mongoimport también entra en el lote: se titula «Mongoimport allows query-operator injection into the selector». Los otros dos sitúan el patrón. Uno se titula «Mongodump: validate server-returned collection names to prevent path traversal»: o sea, también en la dirección de volcar, no solo de restaurar, un servidor que no controlas podía hacer que tu mongodump escribiese fuera del directorio de destino. El otro, «Redact secrets from connection strings in error messages»: la cadena de conexión, con su contraseña dentro, aparecía en los mensajes de error. Donde van los mensajes de error de un trabajo automatizado es al log, y el log lo lee más gente que la base de datos.

Por qué tu escáner no va a encontrar nada

Dos de los cuatro vectores son AV:L, local. Los cuatro necesitan interacción de una persona: UI:P en 4.0, UI:R en 3.1. Eso cambia la aritmética de la exposición. Con un servicio expuesto, lo que se cuenta son los días entre el parche y su aplicación; aquí no hay cuenta que llevar, porque no hay nada escuchando en un puerto. La ventana no se abre el día del aviso: se abre la próxima vez que alguien restaura. Puede ser esta tarde o puede ser en marzo.

Y hay un detalle que lo remata, y es el que convierte esto en un problema de inventario y no de parcheo. En el rastreador de seguridad de Ubuntu, la prioridad asignada a CVE-2026-119675 es media, y el estado del paquete mongo-tools es «no está en la release» para 22.04, 24.04, 26.04 y 26.10; solo queda pendiente de evaluar en 18.04 y 20.04. En una Ubuntu moderna este paquete no lo instala ni lo actualiza tu gestor de paquetes, porque no lo trae. Lo bajó alguien a mano, o entró dentro de una imagen de contenedor. Tus actualizaciones desatendidas no lo van a tocar nunca. Es la misma dinámica que contábamos con el fin de soporte de PostgreSQL 14: lo que no está en el inventario no tiene quien lo avise.

¿De dónde sale un volcado «ajeno»?

«Volcado no confiable» suena a laboratorio hasta que te pones a enumerar de dónde llegan los volcados que restauras. Nosotros movemos datos entre sistemas para vivir —integraciones y ETL— y la lista real es más corta y más incómoda de lo que parece:

El tercero es el que nos interesa de verdad, porque es el que convierte un 5,2 en un problema de continuidad. Si estás restaurando a las tres de la mañana desde una copia de un sistema que acaba de ser atacado, estás ejecutando contenido de origen dudoso con la cuenta que lo puede todo, en el único entorno que te queda en pie. Es el argumento que ya hicimos al hablar de por qué restaurar no es recuperar, y esta vez el fabricante lo pone por escrito en un aviso.

Cuándo esto NO corre prisa

Lo decimos porque sería fácil vender lo contrario. Si los únicos volcados que restauras los produjo tu propio clúster, si la cuenta con la que restauras no puede gestionar usuarios, y si no usas mongofiles para nada, el riesgo realista de estas cuatro es muy bajo y no hay que tocar nada hoy: entra en tu ventana normal y ya está. Un 2,1 y un 1,0 no son una emergencia por mucho que lleven las siglas CVE delante.

Lo que lo hace urgente es una combinación concreta: restauras ficheros que no has generado tú, con una cuenta que puede crear usuarios, y lo haces directamente contra una instancia que importa. Si las tres cosas son ciertas en tu casa, las cuatro CVE dejan de ser una nota al pie y la que crea cuentas root se convierte en el camino más corto que tiene alguien para entrar en tu base de datos sin pelearse con tu cortafuegos. Y el arreglo no es un proyecto: es un binario.

El censo: seis comprobaciones

Ninguna modifica nada y ninguna necesita comprar nada. Son nuestras, no del aviso:

La número 2 es la que casi nunca tiene respuesta, y es la interesante. La 1 se contesta en treinta segundos y da una falsa tranquilidad: el portátil del que mira está actualizado, y el contenedor que restaura de verdad lleva la imagen de hace catorce meses.

Lo que nos llevamos de esto

No somos una consultora de MongoDB y no vamos a fingirlo. Lo que sí hacemos todos los días es mover datos entre sistemas que no se hablaban —integraciones y ETL, con sus trabajos de copia y sus restauraciones de prueba— y ahí el patrón de estas cuatro CVE es viejo conocido: el conector. El binario que traduce entre dos lados, que nadie inventarió porque no ocupa un puerto, y que se actualiza cuando alguien se acuerda. De los motores de base de datos se ocupa medio mundo. De los conectores, el que se acuerde.

Por eso los simulacros de recuperación que metemos en un plan de disaster recovery van cada trimestre y con cronómetro. Un simulacro de verdad contesta la pregunta 2 de la lista de arriba sin que nadie la formule, porque obliga a abrir la máquina desde la que se restaura de verdad. Nuestro último ensayo de recuperación completa salió en catorce minutos —dato interno, prueba y no promesa—. Y el valor de cronometrarlo no está solo en el minutero: un simulacro obliga a escribir la lista de máquinas y versiones desde las que se restaura, que casi nunca está escrita en ninguna parte.

Fuentes (verificadas el 07-11-2026): descripciones literales, fechas de publicación (03-11-2026), vectores y puntuaciones CVSS 4.0 y 3.1 asignadas por MongoDB como CNA, rangos de versiones afectadas y versión corregida (100.20.1) de las cuatro CVE — NVD, CVE-2026-119675, CVE-2026-119674, CVE-2026-119673 y CVE-2026-119672; listado de los cuatro avisos con sus títulos y productos afectados — MongoDB Alerts; fecha de la versión 100.20.1 (02-11-2026) y títulos literales de los tickets TOOLS-4352, TOOLS-4417, TOOLS-4422, TOOLS-4446 y TOOLS-4448 — changelog de mongo-tools; prioridad asignada y estado del paquete mongo-tools por release — Ubuntu Security tracker; numeracion separada de las Database Tools a partir de la 100.0.0 (antes compartian version con el servidor) — MongoDB Docs, Database Tools 100.0.0. La tabla comparativa, la lectura sobre la dirección de la confianza, la lista de orígenes de un volcado y las seis comprobaciones son elaboración nuestra. El dato de los catorce minutos es un registro interno de un simulacro propio, no una garantía de servicio. Fotografía: «Interior of StorageTek tape library at NERSC (2)», de Derrick Coetzee, CC0 vía Wikimedia Commons, recortada y aclarada por nosotros.