Descubrimiento técnico de las vulnerabilidades CVE-2025-23061 y CVE-2024-53900 de Mongoose

Al definir un esquema en Mongoose, se puede configurar un campo para que haga referencia a otro modelo utilizando la opción `ref`. A continuación, se utiliza el método populate() para sustituir el campo al que se hace referencia (un ObjectId) por el documento completo del modelo relacionado. Por ejemplo, en una aplicación de librería, el campo author del bookSchema hace referencia al documento Author, y el campo review hace referencia al documento Reviews. El método populate() permite a los desarrolladores sustituir el campo author (que es un ObjectId) por el documento completo Author al consultar el modelo book.

El método `populate()` permite a los desarrolladores sustituir el campo «author» (que es un ObjectId) por el documento «Author» completo al consultar el modelo «book »:

Además, el método `populate()` de Mongoose admite consultas personalizadas para definir qué documentos relacionados se recuperan y cómo se obtienen. Propiedades como `match` y `options` permiten a los desarrolladores filtrar, ordenar, limitar y omitir documentos relacionados, lo que ofrece una gran flexibilidad a la hora de recuperar datos.

En el ejemplo anterior, la opción «match» es un objeto de filtro que puede incluir operadores de consulta de MongoDB, tal y como se detalla en «Operadores de consulta y proyección» del Manual de MongoDB v8.0. Un operador destacado es «$where», que permite la ejecución de JavaScript directamente en el servidor de MongoDB. Sin embargo, esta ejecución en el servidor de MongoDB está limitada, ya que solo admite operaciones y funciones básicas.

Dat Phung llevó a cabo un análisis en profundidad del código fuente de Mongoose para comprender el flujo de trabajo del método `populate()`. Determinó que, una vez que la aplicación invoca el método `populate()` en el modelo, se activa la función `populate()`. Dentro de esta función, Mongoose llama a la función _execPopulateQuery() , que ejecuta la consulta con el operador $where en el servidor de MongoDB. Posteriormente, se recuperan todos los documentos de la colección externa para su población en los siguientes pasos.

Tras recuperar los datos de MongoDB, Mongoose ejecuta la función de llamada de retorno _done(), que a su vez llama a _assign() para preparar los datos antes de «unir» los dos modelos mediante la función assignVals().

La vulnerabilidad puede surgir cuando los datos recuperados se procesan mediante la función `assignVals()` de Mongoose. Esta función comprueba si la opción `match` es una matriz y, en caso afirmativo, pasa cada operador a la función `sift()`. La función `sift()` , que se importa desde una biblioteca externa del mismo nombre, procesa estas consultas de forma local en el servidor de la aplicación. Este procesamiento local supone un riesgo de seguridad, especialmente al gestionar entradas controladas por el usuario.

Para profundizar en el análisis, Dat Phung modificó los valores de la opción «match» con el fin de garantizar que se cumplieran las condiciones, lo que provocó la ejecución de la función «sift()» para realizar un análisis más detallado del flujo de datos.

Una vez establecida la condición, el operador $where se pasó a continuación a la función sift().

La biblioteca sift es una utilidad ligera de JavaScript diseñada para filtrar y consultar conjuntos de datos, como matrices u objetos JSON, utilizando una sintaxis similar a la de MongoDB. Según la documentación oficial, «Sift es una pequeña biblioteca que permite utilizar consultas de MongoDB en JavaScript». La función sift() evalúa operaciones de filtrado similares a las de MongoDB en el servidor de la aplicación en lugar de en el servidor de la base de datos, lo que puede exponer al sistema a importantes riesgos de seguridad al procesar entradas no fiables.

Continuando con su análisis, nuestro becario detectó un problema en la función `createDefaultQueryTester() ` de la biblioteca `sift`. Esta función convierte cada operación del array `match` en funciones JavaScript ejecutables, que luego se utilizan para filtrar y procesar los datos de los documentos de MongoDB de forma local. Para ello, `createDefaultQueryTester()` invoca la función `createNamedOperation()`, pasando como argumentos operaciones como `$where` del array `match`. 

Para cada operación de la matriz de coincidencias, createNamedOperation comprueba si la operación es compatible y, a continuación, la pasa a la función correspondiente.

Si la operación es $where, se genera una función JavaScript utilizando el valor sin procesar «params», que se deriva del operador $where en la matriz de coincidencias y puede ser controlado por el usuario.

Al principio, la consulta no pudo ejecutar otro proceso, lo que provocó el siguiente error:

Este error indica que Mongoose intenta ejecutar la operación $where en el servidor de MongoDB antes de pasar el control a la función sift(). Sin embargo, debido a las restricciones que se aplican a las funciones de JavaScript en la cláusula $where de MongoDB, se produce un error que impide que se ejecute la consulta. Como consecuencia, Mongoose detiene el proceso antes de que pueda llegar a la función sift() .

Para sortear esta limitación, nuestro compañero aprovechó la variable «global» presente en el servidor de aplicaciones, que no existe en el servidor de MongoDB. Este enfoque le permitió eludir la restricción del servidor de MongoDB y hacer que la consulta llegara a la función sift():

Con este valor, cuando Mongoose ejecuta la operación $where en MongoDB, la ausencia de la variable «global» hace que el operador ternario (typeof global != "undefined" ?global.process.mainModule.constructor._load("child_process").exec("calc") : 1)devuelva 1, lo que evita que MongoDB genere un error. En consecuencia, la consulta se ejecuta en el servidor de MongoDB sin problemas.

Sin embargo, cuando ese mismo valor llega a la función `sift()`, que se ejecuta en el servidor de aplicaciones donde está disponible la variable «global», se activa la creación de la siguiente función:

El vídeo muestra la demostración de concepto de la vulnerabilidad CVE-2024-53900, que afecta a las versiones de Mongoose anteriores a la 8.8.3, las cuales carecen de una validación adecuada de las entradas para evitar el uso indebido del operador $where junto con la biblioteca sift.

Este fragmento de código comprueba si la propiedad «match» pasada a la función «populate()» es una matriz. Si lo es, el código recorre cada objeto de la matriz para comprobar si contiene el operador «$where ». Si se detecta «$where», se genera un error, lo que impide que la carga maliciosa se propague a la función «sift()», que supone un riesgo.  

En consecuencia, la carga útil que aprovecha la vulnerabilidad CVE-2024-53900 no supera esta comprobación porque un objeto de la matriz «match» contiene «$where», lo que impide que llegue a la función «sift()».

Aunque esta actualización bloquea correctamente el uso directo de $where dentro de un único nivel de anidamiento, no detecta $where cuando se incluye dentro de un operador $or, una estructura que tanto MongoDB como la biblioteca sift admiten plenamente.

Como consecuencia, un atacante puede anidar $where dentro de $or para eludir la comprobación de un solo nivel del parche. Dado que Mongoose solo inspecciona las propiedades de primer nivel de cada objeto del array «match», la carga útil de elusión pasa desapercibida y acaba llegando a la biblioteca «sift», lo que permite la ejecución remota de código maliciosa.

Además, las vulnerabilidades CVE también pueden detectarse mediante MetaDefender Software Supply Chain, que aprovecha MetaDefender Core SBOM para identificar estas vulnerabilidades.