¿Qué es la inyección NoSQL? Cómo funciona y cómo prevenirla

¿Qué es la inyección NoSQL?

La inyección NoSQL es una vulnerabilidad que permite a los atacantes manipular las consultas enviadas a bases de datos NoSQL mediante la inserción de operadores maliciosos, código JavaScript o sintaxis manipulada en entradas de usuario no saneadas. Clasificada formalmente en la enumeración de debilidades comunes (CWE) como CWE-943, "Neutralización incorrecta de elementos especiales en la lógica de consultas de datos", afecta a bases de datos como MongoDB, Redis, Cassandra y Elasticsearch, que usan lenguajes de consulta flexibles y sin esquemas en lugar de SQL estándar.

Una explotación exitosa va mucho más allá de una consulta maliciosa. Un atacante puede evadir por completo la autenticación, extraer datos confidenciales carácter por carácter, modificar registros, provocar condiciones de denegación de servicio o ejecutar código arbitrario en el servidor. Como señala la OWASP WSTG, "los posibles impactos son mayores que los de la inyección SQL tradicional", porque las cargas de inyección NoSQL pueden ejecutarse dentro de un lenguaje procedimental como JavaScript, no solo en un lenguaje de consultas declarativo.

Las bases de datos NoSQL sustentan hoy desde sistemas de inicio de sesión y plataformas de chat hasta catálogos de comercio electrónico y consolas de gestión de IoT. Su adopción creciente, sumada a la creencia errónea de que "sin SQL no hay inyección", convierte esta clase de vulnerabilidad en un riesgo persistente. Esa creencia es falsa, y los atacantes cuentan con ella. 

Antes de examinar cómo funciona la inyección NoSQL en la práctica, conviene entender cómo se clasifica en los marcos estándar de vulnerabilidades.

Clasificación de OWASP

OWASP clasifica la inyección NoSQL en la categoría Inyección tanto en la edición de 2021 como en el Top 10 de 2025. Comparte una categoría de riesgo con la inyección SQL, pero tiene una clasificación distinta de la causa raíz que influye en cómo se prueba y se informa.

La distinción clave es la correspondencia con CWE. La inyección SQL tradicional se clasifica como CWE-89 (Neutralización incorrecta de elementos especiales usados en un comando SQL), mientras que la inyección NoSQL corresponde a CWE-943 (Neutralización incorrecta de elementos especiales en la lógica de consultas de datos). CWE-943 abarca lenguajes de consulta distintos de SQL, incluidos los operadores Binary JSON (BSON) de MongoDB, los comandos del protocolo Redis y las consultas basadas en REST de CouchDB.

Si su programa de pruebas de seguridad o sus informes de cumplimiento solo hacen seguimiento de CWE-89, los hallazgos de inyección NoSQL pueden clasificarse incorrectamente o pasar inadvertidos. Adapte sus herramientas y su taxonomía a CWE-943 para eliminar ese punto ciego. 

Una vez establecida la clasificación, el siguiente paso es entender los mecanismos específicos que usan los atacantes para explotar las interfaces de consulta NoSQL.

¿Cómo funciona la inyección NoSQL?

La inyección NoSQL aprovecha la diferencia entre lo que su aplicación espera de las entradas del usuario y lo que realmente recibe. Mientras que la inyección SQL se dirige a un lenguaje de consulta universal, la inyección NoSQL varía según la base de datos. MongoDB usa operadores de consulta BSON/JSON, Redis usa el protocolo de comunicación Redis Serialization Protocol (RESP) y CouchDB ofrece una API REST HTTP. Cada base de datos presenta una superficie de ataque, pero el principio fundamental sigue siendo el mismo: los datos controlados por el usuario entran en una consulta sin la validación adecuada y alteran su lógica.

Inyección de operadores: el patrón más común

En una aplicación típica de Node.js respaldada por MongoDB, un endpoint de inicio de sesión podría construir una consulta como esta:

Una solicitud legítima envía {"username":"admin","password":"secret"}. Pero un atacante puede enviar:

El operador $ne (distinto de) indica a MongoDB que devuelva todos los usuarios cuyo nombre de usuario y contraseña sean distintos de "invalid", lo que incluye todas las cuentas válidas. La autenticación se elude con una sola solicitud, sin necesidad de ataques de fuerza bruta.

Inyección de JavaScript mediante $where

Cuando las aplicaciones pasan datos introducidos por el usuario al operador $where de MongoDB o a funciones como mapReduce, $accumulator o $function, la base de datos los evalúa como JavaScript del lado del servidor. Un atacante que inyecte una carga útil con un bucle de espera activa puede bloquear la instancia de MongoDB y provocar una denegación de servicio. Además del acceso a los datos, la ejecución de JavaScript arbitrario puede dar lugar a la ejecución remota de código en el servidor de la base de datos.

Extracción a ciegas

Cuando la aplicación no devuelve directamente los resultados de la consulta, los atacantes usan técnicas basadas en valores booleanos o en tiempos de respuesta para extraer los datos carácter por carácter. Al enviar patrones de expresiones regulares como password[$regex]=^a y observar si la respuesta difiere de la de una condición que se sabe falsa, un atacante puede reconstruir contraseñas, tokens y otros secretos sin ver nunca una filtración de datos.

Inyección de comandos de Redis mediante CRLF

En RESP, los comandos se separan mediante secuencias de retorno de carro y salto de línea (CRLF) (\r\n). Cuando una aplicación concatena datos introducidos por el usuario en comandos del protocolo Redis sin depurarlos, un atacante puede inyectar secuencias CRLF para terminar el comando actual y añadir comandos no autorizados a la misma conexión.

Redis almacena datos en pares clave-valor, y comandos inyectados como SET, GET y CONFIG pueden leer datos confidenciales, sobrescribir claves o reconfigurar por completo el servidor. Esta técnica suele combinarse con la falsificación de solicitudes del lado del servidor (SSRF): el atacante aprovecha una vulnerabilidad SSRF para llegar a una instancia interna de Redis no expuesta a internet y, después, inyecta comandos adicionales a través del canal SSRF.

Inyección en la API HTTP de CouchDB

CouchDB expone una API REST/HTTP, por lo que todas las operaciones de la base de datos se realizan mediante solicitudes HTTP estándar con cargas útiles JSON. La inyección se produce cuando una aplicación pasa datos introducidos por el usuario sin depurar a parámetros de consulta, definiciones de vistas u objetos selectores de Mango en CouchDB.

Dado que CouchDB utiliza vistas MapReduce escritas en JavaScript, presenta un riesgo de ejecución del lado del servidor similar al del operador $where de MongoDB. Un atacante que pueda influir en el JavaScript ejecutado dentro de una vista MapReduce puede ejecutar código arbitrario en el servidor de la base de datos. La función de replicación de CouchDB también puede explotarse mediante solicitudes HTTP manipuladas para lanzar ataques SSRF contra servicios internos.

Cada base de datos NoSQL presenta una superficie de ataque distinta, ya sea por los operadores BSON de MongoDB, la inyección CRLF en el protocolo de Redis o la API REST de CouchDB. Sus defensas contra la inyección NoSQL deben adaptarse a la interfaz de consulta específica de cada base de datos.

Estos mecanismos funcionan con distintos tipos de contenido, capas de transporte y frameworks. Sus causas fundamentales se repiten, y esa repetición da ventaja a los defensores.

Causas de la inyección NoSQL

La inyección NoSQL no surge de un único error de programación. Es el resultado de una combinación de supuestos arquitectónicos, comportamientos de los frameworks y capas de validación ausentes que se acumulan durante la ejecución.

Validación inadecuada de entradas y falta de control de tipos

Su aplicación puede suponer que un campo como password siempre llegará como una cadena de texto, pero los cuerpos de las solicitudes HTTP, las cargas JSON y los parámetros codificados en URL pueden contener objetos y arreglos. Cuando el body-parser de Express.js recibe password[$ne]=x, lo deserializa automáticamente en { password: { $ne: "x" } }, un objeto con un operador de MongoDB, antes de que el código de la aplicación lo procese.

Construcción dinámica de consultas

Cuando construye consultas mediante concatenación o interpolación de cadenas en lugar de usar objetos de consulta estructurados, los atacantes pueden alterar la sintaxis e inyectar nueva lógica. El foro de MongoDB confirma: "En la mayoría de los casos, las inyecciones externas se producen por una concatenación insegura de cadenas al crear consultas".

JavaScript del lado del servidor habilitado

MongoDB admite la ejecución de JavaScript mediante $where, mapReduce, $accumulator y $function. La lista de verificación de MongoDB recomienda explícitamente deshabilitar la ejecución de scripts del lado del servidor con --noscripting cuando no se utilizan estas operaciones. Mantenerlas habilitadas crea una superficie de ataque para la ejecución de código arbitrario.

Conversión de tipos a nivel de framework

PHP convierte automáticamente username[$ne]=toto en ['username' => ['$ne' => 'toto']]. El body-parser de Express.js hace lo mismo con los datos de formularios codificados en URL: deserializa password[$ne]=x en { password: { $ne: "x" } }, un objeto con un operador de MongoDB, antes de que la solicitud llegue al código de la aplicación. Estos comportamientos de los frameworks transforman parámetros HTTP aparentemente inofensivos en operadores de base de datos sin que el desarrollador intervenga deliberadamente.

Vulnerabilidades en la capa ORM

Aunque MongoDB esté reforzado, la biblioteca de mapeo objeto-relacional (ORM) de su aplicación puede introducir superficies de inyección. CVE-2024-53900 demostró que el operador $where de Mongoose podía explotarse mediante entradas controladas por el usuario, y CVE-2025-23061, una corrección incompleta de la primera vulnerabilidad, mostró que el operador $where aún podía eludirse anidándolo bajo $or en la función populate().match de Mongoose, eludiendo por completo las protecciones a nivel de servidor.

Validación del protocolo de comunicación desactivada

MongoDB valida los documentos entrantes a nivel del protocolo de comunicación mediante la configuración net.wireObjectCheck. Al desactivarla, se elimina una protección estructural que impide que los datos BSON malformados lleguen al motor de consultas.

Estas causas crean una superficie de ataque que abarca desde el análisis de solicitudes HTTP hasta la ejecución en la base de datos, lo que se traduce directamente en un riesgo empresarial.

Impacto y riesgo

La inyección NoSQL afecta a todas las dimensiones de la tríada de confidencialidad, integridad y disponibilidad (CIA), a menudo de forma simultánea.

• Confidencialidad: Los atacantes pueden leer documentos arbitrarios, enumerar nombres de campos y extraer credenciales carácter por carácter mediante técnicas de inyección ciega. En CVE-2021-22911, los investigadores filtraron hashes de contraseñas de administradores y tokens de restablecimiento de contraseñas de instancias de Rocket.Chat.
• Integridad: La inyección de operadores y el uso indebido de consultas sin procesar permiten a los atacantes modificar, reemplazar o eliminar documentos. Las consultas añadidas a otras pueden insertar registros completamente nuevos o sobrescribir los valores de campos existentes.
• Disponibilidad: Una carga maliciosa de $where con un bucle de espera activa puede saturar una instancia de MongoDB y dejar la base de datos fuera de servicio sin necesidad de inundar la red de tráfico.
• La evasión de la autenticación es uno de los impactos más documentados. Esto convierte la inyección NoSQL en una vía directa de acceso inicial a aplicaciones expuestas a Internet.
• El riesgo para la cadena de suministro y los usuarios posteriores amplifica el alcance de la inyección NoSQL en los productos de plataforma. Cuando una vulnerabilidad compromete una plataforma como Rocket. Chat o Parse Server, el impacto se extiende a los clientes y usuarios posteriores de esa plataforma. Una sola falla de inyección en un producto de backend como servicio puede exponer muchas aplicaciones creadas sobre esa plataforma y convertir una vulnerabilidad en múltiples entornos comprometidos.
• Las consecuencias normativas y de cumplimiento se derivan directamente de las vulneraciones de la confidencialidad. Cuando la inyección NoSQL facilita la exfiltración de datos personales, credenciales o comunicaciones de clientes, las organizaciones deben cumplir requisitos de notificación de brechas establecidos por marcos como GDPR, HIPAA, PCI DSS y las leyes de privacidad estatales. La técnica de extracción carácter por carácter empleada en los ataques de inyección ciega puede exfiltrar datos sensibles sin levantar sospechas durante períodos prolongados. Ese goteo lento es fácil de pasar por alto, por lo que la detección temprana es esencial.

• La ejecución remota de código está confirmada mediante la evaluación de JavaScript en el servidor. La guía OWASP WSTG afirma que «como JavaScript es un lenguaje con todas las funciones, esto no solo permite a un atacante manipular datos, sino también ejecutar código arbitrario». Un artículo del Simposio Internacional de Informática Forense y Seguridad Digital de 2025 (ISDFS) describe este riesgo sin rodeos: «Dada la potencia de JavaScript, exponer una vulnerabilidad así es comparable a entregar una ametralladora a un delincuente experto».

Los defensores que conocen el plan de ataque pueden frustrarlo en cada fase. Así es como se desarrolla.

Cómo explotan los atacantes la inyección NoSQL

Los atacantes siguen una metodología estructurada para detectar y explotar la inyección NoSQL, desde el reconocimiento hasta la exfiltración de datos o la ejecución de código.

Fase 1: Identificación de vectores de entrada

El atacante identifica los parámetros que se envían a un backend NoSQL: parámetros de URL, cuerpos JSON de solicitudes POST, encabezados HTTP y mensajes WebSocket. Envía caracteres de prueba (' " \ ; { }) y observar mensajes de error o cambios de comportamiento que revelen la interacción con la base de datos.

Fase 2: Confirmación de la inyección de operadores

En un endpoint de inicio de sesión, el atacante sustituye una cadena de credenciales normal por un operador $ne:

Si la aplicación inicia sesión correctamente como otro usuario, se confirma la inyección de operadores. El atacante también puede probar el operador $gt (mayor que) como confirmación alternativa:

El $gt con una cadena vacía coincide con cualquier contraseña no vacía. Si se inicia sesión en la cuenta de administrador sin una contraseña válida, la inyección de operadores queda confirmada por segunda vez.

Fase 3: Evasión de la autenticación

El atacante intensifica el ataque inyectando operadores en ambos campos:

Esto se dirige específicamente a las cuentas con privilegios y devuelve el primer usuario cuyo nombre de usuario figura en la lista y cuya contraseña es cualquier cadena no vacía.

Fase 4: Exfiltración de datos

Mediante $where con inyección de JavaScript, el atacante comprueba si existe un campo:

Si la respuesta coincide con un patrón cuya validez se conoce, el campo resetToken existe. Luego, el atacante extrae su valor carácter por carácter mediante una inyección ciega basada en condiciones booleanas. La técnica consiste en enviar un patrón de expresión regular como {"resetToken":{"$regex":"^A"}} y observar la respuesta HTTP. Un código de estado de éxito o un cuerpo de respuesta específico indica que el carácter coincide; una respuesta diferente indica que no coincide. El atacante prueba cada posición con todos los caracteres posibles. Como se documenta en CVE-2024-37405, esta extracción puede realizarse mediante solicitudes diferenciales repetidas, lo que convierte la inyección ciega en un ataque viable y no en una preocupación teórica.

Fase 5: Escalada de privilegios y movimiento lateral

Con las credenciales o los tokens de restablecimiento extraídos, el atacante obtiene acceso administrativo. Desde allí, puede pasar a sistemas de backend, acceder a otras colecciones mediante una inyección en el pipeline de agregación con $lookup o $unionWith (nominada por PortSwigger como una de las principales técnicas de ataque web), o establecer persistencia mediante la ejecución de código en el servidor. La inyección en el pipeline de agregación con $lookup tiene un gran impacto porque puede leer colecciones a las que la consulta de la aplicación nunca debía acceder. Así, rompe los límites de acceso entre colecciones y expone datos de toda la base de datos.

Cambio de Content-Type

Los atacantes suelen alternar entre application/x-www-form-urlencoded y application/json para encontrar puntos de inyección que solo existen en uno de los formatos. Esta técnica es especialmente eficaz contra las API REST que admiten varios formatos.

Estas técnicas de ataque son aplicables siempre que una base de datos NoSQL acepte entradas de los usuarios. Algunas aplicaciones están mucho más expuestas que otras.

¿A quién afecta?

La inyección NoSQL afecta a cualquier aplicación que envíe entradas controladas por usuarios a una base de datos NoSQL sin aplicar una validación adecuada de tipos. Según la evidencia confirmada de CVE, las categorías de aplicaciones más expuestas incluyen:

• Sistemas de autenticación: Los endpoints de inicio de sesión son la superficie de ataque habitual documentada en todas las fuentes principales.
• Plataformas de colaboración en equipo: Rocket.Chat acumula varias CVE de inyección NoSQL a lo largo de varios años, incluida una vulnerabilidad previa a la autenticación (CVE-2021-22911).
• Aplicaciones Node.js/Express que usan Mongoose: Mongoose, un mapeador de documentos a objetos (ODM), introduce superficies de inyección en la capa ORM, independientemente de los controles propios de MongoDB.
• Backends de plataforma como servicio: Parse Server (CVE-2022-24815, CVE-2026-30941) y Steedos Platform (CVE-2020-35666) muestran la exposición de los productos de backend como servicio.
• IoT y gestión de redes: Una vulnerabilidad de inyección NoSQL en UniFi Network Application de Ubiquiti, confirmada por el proveedor y registrada con un CVE, permitía la escalada de privilegios.
• Plataformas de comercio electrónico: Una vulnerabilidad de inyección NoSQL en la función de restablecimiento de contraseñas de AquilaCMS recibió una calificación CRÍTICA (CVE-2024-48573).
• API de GraphQL: Los argumentos de filtro de GraphQL que se incorporan directamente a las consultas de MongoDB sin sanitización crean una superficie de inyección que suele pasarse por alto.

MongoDB se utiliza ampliamente, al igual que Node.js/Express para el desarrollo de backends. Esta combinación crea una amplia superficie de ataque. NIST IR 8504 documenta formalmente la inyección NoSQL como una categoría de riesgo reconocida para los sistemas del gobierno de Estados Unidos. Esto subraya que el riesgo también afecta a las grandes empresas, no solo a las startups o los entornos SaaS.

Las API de GraphQL representan un vector cada vez más común porque los argumentos de filtro suelen incorporarse directamente a las consultas de MongoDB sin una lista explícita de valores permitidos. Las reglas tradicionales tradicionales de firewall de aplicaciones web (WAF) centradas en cargas útiles de tipo SQL apenas cubren este patrón.

El factor común no es el sector, sino el conjunto de tecnologías. Si usa MongoDB, Redis, CouchDB o Elasticsearch con datos introducidos por usuarios, su aplicación es un objetivo potencial, especialmente si se basa en frameworks de JavaScript que realizan conversiones automáticas de tipos. Los siguientes incidentes confirmados muestran cómo se explotan estas vulnerabilidades en la práctica.

Ejemplos reales

Los CVE confirmados y las cadenas de explotación publicadas muestran cómo se produce la inyección NoSQL en sistemas de producción de plataformas de colaboración, comercio electrónico, productos de backend como servicio e infraestructura de red.

Rocket.Chat: toma de control de una cuenta de administrador sin autenticación previa (CVE-2021-22911)

La investigación de SonarSource mostró que el método getPasswordPolicy() de Rocket.Chat podía invocarse sin autenticación. Al inyectar el operador $regex de MongoDB en el parámetro del token de restablecimiento de contraseña, un atacante podía extraer el token carácter por carácter mediante el envío de {"$regex":"^A"} y la observación de las diferencias en las respuestas.

El informe confirmado de HackerOne mostró la cadena de ataque: exposición de nombres de usuario de administradores, direcciones de correo electrónico, hashes de contraseñas y tokens de restablecimiento, hasta culminar en la toma de control total de una cuenta de administrador.

@feathersjs/mongodb: inyección de objetos mediante WebSocket (CVE-2026-29793)

Los clientes de Socket.IO podían enviar objetos JavaScript arbitrarios como argumento id a cualquier método de servicio de Feathers. La capa de transporte no comprobaba los tipos. Al enviar {$ne: null} como argumento id, se obtenían coincidencias con todos los documentos de una colección. La vulnerabilidad está registrada como CVE-2026-29793.

Ubiquiti UniFi: escalada de privilegios con autenticación (CVE-2026-22557)

Un aviso de la propia Ubiquiti confirmó una vulnerabilidad de inyección NoSQL con autenticación en UniFi Network Application que permitía la escalada de privilegios. Cualquier usuario autenticado podía explotarla para obtener acceso elevado y pasar de una cuenta con pocos privilegios al control administrativo total de la infraestructura de red.

Rocket.Chat Livechat: inyección encadenada (CVE-2024-37405)

Se identificaron dos puntos distintos de inyección NoSQL encadenados: la extracción de un token de visitante mediante una inyección ciega con $regex, seguida de una segunda inyección en el parámetro rid para extraer todos los mensajes de Livechat. Este ataque previo a la autenticación expuso datos de comunicaciones con clientes.

AquilaCMS: inyección crítica en el restablecimiento de contraseñas (CVE-2024-48573)

AquilaCMS, una plataforma de comercio electrónico de código abierto, recibió una calificación CRÍTICA (9.8) por una vulnerabilidad de inyección NoSQL en su función de restablecimiento de contraseñas. Un atacante no autenticado podía manipular el proceso de restablecimiento de contraseñas inyectando operadores de MongoDB en el parámetro del token de restablecimiento y eludir por completo la lógica de validación prevista. Dado que AquilaCMS impulsa tiendas de comercio electrónico, una explotación exitosa ponía en riesgo los datos de las cuentas de los clientes, la información de pago y los historiales de pedidos. La vulnerabilidad no requería autenticación y podía explotarse de forma remota mediante una solicitud HTTP estándar, por lo que cualquier atacante con acceso de red a la tienda podía aprovecharla.

Parse Server: vulnerabilidades de inyección recurrentes (CVE-2022-24815, CVE-2026-30941)

Parse Server, una plataforma de backend como servicio de código abierto ampliamente utilizada, ha presentado vulnerabilidades de inyección NoSQL recurrentes durante varios años. CVE-2022-24815 combinó la contaminación de prototipos con la inyección NoSQL y demostró cómo las vulnerabilidades de la capa JavaScript se combinan con las inyecciones en bases de datos para abrir vías de explotación que ninguna de las dos fallas permitiría por sí sola. Años después, CVE-2026-30941 reveló que la plataforma seguía teniendo puntos vulnerables a la inyección donde los valores de los tokens se pasaban a consultas de bases de datos sin validar su tipo. Los productos de backend como servicio son objetivos de alto valor porque una sola vulnerabilidad afecta a todas las aplicaciones creadas sobre la plataforma. Si Parse Server se ve comprometido, las aplicaciones móviles, las aplicaciones web y los backends de IoT que dependen de él pueden quedar expuestos de la misma manera.

Estos incidentes abarcan varios años y distintas tecnologías. La inyección NoSQL sigue reapareciendo en sistemas de producción, y la cronología muestra cuánto tiempo lleva repitiéndose este patrón.

Cronología de la inyección NoSQL

La concentración de CVE en 2026 indica un interés creciente de los investigadores por las tecnologías Node.js/MongoDB y sugiere que la inyección NoSQL vuelve a captar atención, en lugar de desaparecer. Esta tendencia convierte la detección en una prioridad. La buena noticia es que los indicios son bien conocidos.

Cómo detectar la inyección NoSQL

Detectar la inyección NoSQL exige combinar el análisis estático del código, las pruebas dinámicas en endpoints activos y la supervisión del comportamiento en tiempo de ejecución para identificar las explotaciones que otros controles pasan por alto.

Análisis estático y revisión del código

Revise su código para detectar patrones de alto riesgo. Marque cualquier .find(), .findOne(), o .populate() que pase directamente req.body, req.query o req.params sin aplicar controles de tipo. Busque cualquier uso de $where con entradas controladas por el usuario, cualquier pipeline de agregación que incorpore objetos de filtro controlados por el usuario y cualquier endpoint que acepte objetos de consulta JSON sin procesar de los clientes. Además, señale cualquier uso de eval(), Function() o literales de plantilla que concatenen entradas del usuario en cadenas de consulta. Los pipelines de agregación que utilicen $lookup o $unionWith con nombres de colecciones o etapas del pipeline controlados por el usuario requieren especial atención, ya que pueden vulnerar los límites de acceso entre colecciones.

Pruebas dinámicas

Siga la OWASP WSTG-INPV-05.6 metodología:

1. Envíe la cadena de prueba '"\{ ;$Foo} $Foo \xYZ` para identificar puntos de inyección de sintaxis.
2. Envíe los caracteres especiales ' " \ ; { } para identificar puntos de inyección de operadores.
3. Use HTTP Parameter Pollution para inyectar un parámetro $where y observe las respuestas de error de MongoDB.
4. Compare las respuestas booleanas ante condiciones verdaderas y falsas conocidas para detectar inyecciones ciegas.

También debe probar específicamente los canales WebSocket. CVE-2026-29793 demostró que los clientes de Socket.IO podían enviar objetos JavaScript arbitrarios como argumentos de métodos de servicio y eludir toda inspección en la capa HTTP. Muchos escáneres se centran exclusivamente en los endpoints HTTP y pasan por alto las superficies de inyección de WebSocket. Las pruebas de WebSocket manuales o especializadas cubren esa brecha en aplicaciones basadas en frameworks de comunicación en tiempo real.

Monitoreo del comportamiento en tiempo de ejecución

Monitoree su infraestructura para detectar indicadores de comportamiento de una explotación exitosa:

• Procesos de servicios de bases de datos (mongod, redis-server) que generan procesos secundarios o shells inesperados
• Patrones de consulta inusuales que contienen sintaxis de operadores de MongoDB ($where, $regex, $ne, $gt) en los registros de la aplicación
• Picos de uso de CPU en servidores MongoDB sin un aumento correspondiente de consultas legítimas
• Endpoints de restablecimiento de contraseñas endpoints que reciben objetos en lugar de cadenas en los campos de token
• Diferencias en los tiempos de respuesta de endpoints públicos que sugieren una inyección ciega basada en tiempos

Herramientas de pruebas de penetración

Las herramientas especializadas sirven para detectar inyecciones NoSQL durante las evaluaciones:

• NoSQLMap: Herramienta de código abierto diseñada específicamente para probar y explotar inyecciones NoSQL
• nosqli: Herramienta de línea de comandos para la detección automatizada de inyecciones NoSQL
• Burp Suite: Pruebas manuales mediante los módulos Repeater e Intruder, con extensiones para probar automáticamente cargas útiles NoSQL
• OWASP ZAP: Reglas de análisis activo aplicables a endpoints NoSQL

Saber dónde buscar es la mitad del desafío. La otra mitad es crear defensas que impidan la explotación desde el principio.

Cómo prevenir la inyección NoSQL

Para detener la inyección NoSQL, primero aplique una validación estricta de tipos a todos los datos introducidos por el usuario antes de que lleguen a la capa de base de datos. Las defensas siguientes abordan cada causa raíz identificada anteriormente, desde la conversión de tipos a nivel de framework hasta la evasión de la capa ORM.

Verifique los tipos antes de construir las consultas

Rechace cualquier campo de entrada que no contenga un valor escalar (cadena, número o booleano) antes de que llegue al ORM o al controlador de la base de datos. La conversión explícita de tipos es la defensa más eficaz:

Elimine o rechace las claves de operadores de MongoDB

Compruebe si todas las claves de req.body, req.query y req.params contienen el prefijo $ prefix y rechácelas antes de que lleguen a la capa de base de datos. Use la comprobación key.startsWith('$') en lugar de expresiones regulares, que presentan métodos de evasión conocidos, documentados en CVE-2021-22910.

Desactive JavaScript del lado del servidor

Use --noscripting o set security.javascriptEnabled: false en la configuración de MongoDB. Esto elimina por completo la superficie de ataque de $where. Priorice $expr y los constructores de consultas con tipos definidos para la lógica condicional.

Use frameworks de validación de esquemas

Valide los tipos de datos al inicio del ciclo de vida de la solicitud con bibliotecas como Joi, Ajv o Zod. Estas rechazan los arreglos u objetos cuando se esperan valores escalares e impiden que la inyección de operadores llegue a la base de datos.

Fije las versiones de Mongoose y ORM y supervise los avisos de seguridad

Las vulnerabilidades de la capa ORM pueden eludir por completo los controles de la aplicación y de la base de datos. CVE-2024-53900 y CVE-2025-23061 demostraron que la función populate().match de Mongoose podía explotarse incluso con JavaScript deshabilitado en el servidor de MongoDB. CVE-2025-23061 fue una corrección incompleta de CVE-2024-53900, lo que demuestra que los parches pueden ser insuficientes y requieren una verificación independiente.

Suscríbase a los avisos de seguridad de Mongoose y otras bibliotecas ODM/ORM, fije explícitamente las versiones de las dependencias y compruebe que cada parche de seguridad resuelva por completo la vulnerabilidad documentada antes de cerrar la incidencia de remediación.

Nunca acepte consultas JSON sin procesar de los clientes

La hoja de referencia de OWASP indica explícitamente: "No acepte consultas JSON sin procesar de los clientes." Una carga útil como { "$where": "this.balance > 0" } enviada por un cliente provoca la ejecución remota de código o el agotamiento de la CPU.

Configure la base de datos con privilegios mínimos

Use cuentas de base de datos específicas para la aplicación con los permisos mínimos. Nunca se conecte con credenciales de root o administrador. No exponga los puertos de la base de datos ni las consolas de administración a la Internet pública.

Mantenga activada la comprobación de objetos en el protocolo de comunicación

La configuración net.wireObjectCheck de MongoDB valida todos los documentos a nivel del protocolo de comunicación. Está activada de forma predeterminada. Nunca la desactive.

Proteja los filtros de GraphQL

Convierta los argumentos de filtro de GraphQL mediante una lista explícita de valores permitidos. Nunca incorpore objetos no confiables directamente a los filtros de consulta de MongoDB o Mongoose.

Los controles sólidos de la aplicación reducen la superficie de ataque. No pueden eliminarla por completo, y la detección y respuesta por capas cubren lo que logra eludirlos.

Herramientas de detección y prevención

Una defensa por capas contra la inyección NoSQL combina controles de la aplicación, herramientas de pruebas y supervisión en tiempo de ejecución.

• Defensas de la capa de aplicación incluyen bibliotecas de validación de entradas (Joi, Ajv, Zod), medidas de protección en la capa ORM (validación de esquemas de Mongoose, conversión explícita de tipos) y controles de seguridad integrados en MongoDB (--noscripting, wireObjectCheck, acceso basado en roles).
• Herramientas de pruebas como NoSQLMap, nosqli, Burp Suite y OWASP ZAP detectan posibles inyecciones NoSQL durante el desarrollo y los ciclos de pruebas de penetración.
• WAFs proporcionan una capa de defensa perimetral que puede bloquear patrones de inyección conocidos. Sin embargo, los WAFs funcionan con reglas basadas en firmas y no pueden detener cargas útiles nuevas, operadores ofuscados ni inyecciones a través de canales WebSocket.
• La supervisión del comportamiento en tiempo de ejecución cubre la brecha que dejan los WAFs. Las cargas útiles nuevas, las vulnerabilidades de la capa ORM como el problema de populate().match de Mongoose o los canales WebSocket que los WAFs no inspeccionan pueden eludir los controles de la aplicación. La supervisión en tiempo de ejecución observa las consecuencias de una inyección exitosa, como procesos de base de datos que generan shells inesperadas, patrones anómalos de ejecución de JavaScript o volúmenes de consultas inusuales, independientemente de cómo se haya enviado la carga útil. Cuando una carga útil de inyección evade la inspección basada en firmas y llega a la base de datos, el comportamiento anómalo resultante se convierte en el indicador de compromiso más fiable.

¿Cómo puede ayudar SentinelOne?

La inspección de cargas útiles corresponde al WAF. SentinelOne observa lo que sucede después, detecta y detiene las consecuencias de una inyección NoSQL exitosa: las anomalías en los procesos, el movimiento lateral y la actividad posterior a la explotación que los controles de la aplicación no detectan.

La Singularity™ Platform de SentinelOne incluye Singularity AI SIEM, que correlaciona la telemetría de endpoints, cargas de trabajo en la nube, sistemas de identidad y fuentes de terceros en un único lago de datos. En las evaluaciones MITRE ATT&CK de 2024, Singularity Platform logró un 100% de detección sin demoras y generó un 88% menos de alertas que la mediana. Menos alertas innecesarias permiten a su equipo centrarse en las amenazas confirmadas. Cuando un ataque de inyección NoSQL pasa de una aplicación web a un servidor de bases de datos y culmina en el robo de credenciales, AI SIEM vincula esos eventos en las distintas superficies sin correlación manual.

En Singularity Endpoint, la tecnología Storyline vincula continuamente los eventos de creación de procesos, las conexiones de red, las modificaciones de archivos y el uso de credenciales en cada endpoint protegido para formar cadenas de procedencia coherentes. Ante un ataque basado en $where que ejecuta JavaScript en el servidor, Storyline vincula de forma autónoma el proceso del servidor web que recibe la solicitud maliciosa, el servicio de base de datos que presenta un comportamiento anómalo, el proceso del intérprete iniciado y cualquier shell secundario, todos bajo un único ID de Storyline. Las reglas personalizadas de Storyline Active Response (STAR) se activan cuando procesos de bases de datos como mongod o redis-server inician procesos secundarios inesperados, un indicador de comportamiento de alta fidelidad de que la inyección de comandos tuvo éxito.

Purple AI™ acelera la investigación mediante consultas en lenguaje natural. Según IDC, los clientes de Purple AI identifican las amenazas un 63% más rápido y reducen un 55% el tiempo medio de remediación (MTTR). Puede preguntar "muéstreme todos los procesos iniciados por mongod en las últimas 24 horas" o hacer referencia directamente a técnicas de MITRE ATT&CK como T1190 (Explotación de aplicaciones expuestas al público) y T1059 (Intérprete de comandos y scripts). La capacidad de investigación automática de Purple AI recopila de forma autónoma pruebas de toda la pila tecnológica, sintetiza datos sobre amenazas y construye cronologías completas de los ataques, reduciendo a minutos investigaciones que antes tomaban horas.

Seguridad de cargas de trabajo en la nube protege las bases de datos NoSQL alojadas en la nube durante su ejecución. Supervisa el comportamiento de las cargas de trabajo en tiempo real y utiliza Verified Exploit Paths para identificar hallazgos basados en pruebas. Así puede ver cuándo una inyección NoSQL contra una instancia de MongoDB o Redis alojada en la nube deriva en actividad posterior a la explotación.

Para las organizaciones que ejecutan bases de datos NoSQL a escala, estas capacidades cierran la brecha entre la prevención a nivel de aplicación y la visibilidad de la actividad posterior a la explotación. 

Solicite una demo de SentinelOne para ver estas capacidades en acción.

Vulnerabilidades relacionadas

La inyección NoSQL comparte causas fundamentales y patrones de ataque con varias clases de vulnerabilidades relacionadas:

• Inyección SQL (CWE-89): Su equivalente en bases de datos relacionales. Ambas explotan la neutralización inadecuada de las entradas del usuario en las consultas a bases de datos, pero la capacidad de la inyección NoSQL para ejecutar lenguajes procedimentales amplía su impacto más allá de la manipulación de datos hasta la ejecución de código arbitrario.
• Falsificación de solicitudes del lado del servidor (SSRF): La inyección CRLF en Redis suele combinarse con SSRF. Un atacante usa SSRF para llegar a una instancia interna de Redis y luego inyecta comandos adicionales mediante secuencias CRLF.
• Inyección de comandos (CWE-78): Cuando la inyección NoSQL logra ejecutar JavaScript en el servidor mediante $where, la capacidad resultante se asemeja mucho a la inyección de comandos del sistema operativo.
• Contaminación de prototipos: CVE-2022-24815 en Parse Server combinó la contaminación de prototipos con la inyección NoSQL, lo que demuestra cómo las vulnerabilidades de la capa de JavaScript agravan la inyección en bases de datos.
• Secuencias de comandos entre sitios (XSS): Tanto XSS como la inyección NoSQL se deben a una validación insuficiente de las entradas. Las organizaciones vulnerables a una suelen presentar deficiencias de validación sistémicas que también las exponen a la otra.

Comprender estas relaciones le permite priorizar las pruebas y la corrección en las clases de vulnerabilidades relacionadas, en lugar de abordar cada una por separado. La siguiente tabla enumera las CVE confirmadas de inyección NoSQL como referencia.