Se puede acceder a tu CVE. Pero, ¿se puede explotar?

Cualquier herramienta de « SCA » que se precie cuenta hoy en día con análisis de alcanzabilidad . Cuando una dependencia presenta una vulnerabilidad conocida, estas herramientas pueden indicarte si tu código llama a la función afectada. Esto es prácticamente imprescindible, ya que ayuda a los equipos a centrar sus esfuerzos en la seguridad en lugar de perder el tiempo con información irrelevante. Todos los demás pasos para priorizar los CVE de las dependencias se basan en ello.

Pero el hecho de que se pueda acceder a la función vulnerable no significa que sea explotable. La accesibilidad implica que tu código puede ejecutar la función vulnerable, mientras que la explotabilidad significa que un atacante puede cumplir las condiciones necesarias para que el fallo cause daños.

Por eso, los equipos de ingeniería que solo cuentan con análisis de alcanzabilidad siguen teniendo que rastrear manualmente qué CVE suponen realmente un problema o determinar cuáles son los hallazgos más urgentes. Muchos equipos se saltan por completo la clasificación manual y simplemente aplican parches a todo lo que supere un umbral de CVSS, y ahí es donde surgen el ruido y el esfuerzo desperdiciado.

Veamos cómo « análisis de explotabilidad » va más allá de « análisis de alcanzabilidad ».

¿Qué es « análisis de alcanzabilidad »?

La mayoría de los equipos clasifican los CVE según la gravedad del CVSS, a menudo mediante las etiquetas predeterminadas que muestran sus herramientas de seguridad, y algunos añaden además el EPSS y el KEV (véase el glosario al final para las siglas). Estas señales describen el CVE en términos generales y otorgan la misma puntuación a todas las aplicaciones que utilizan el paquete, por lo que no aportan información alguna sobre cómo se comporta en tu código.

análisis de alcanzabilidad comprueba si tu código puede ejecutar la función vulnerable en una dependencia, normalmente representando gráficamente cómo tu código realiza llamadas a sus dependencias en forma de gráfico de llamadas. Si nunca se llama a la función vulnerable, prácticamente no hay ningún riesgo (a menos que la aplicación cambie). 

Antes de análisis de alcanzabilidad y SCA , las herramientas detectaban todos los CVE de todas las dependencias, incluidos los paquetes transitivos que tu código ni siquiera llamaba. Los equipos aplicaban parches a todo lo que superara un umbral de CVSS o realizaban una clasificación manual. Reachability cambió eso al vincular cada hallazgo con tu código real, de modo que los ingenieros pudieran dedicar su tiempo a los hallazgos que realmente importaban en producción. Convirtió una cola de alertas de dependencias en algo que realmente podían gestionar.

La accesibilidad funciona en dos niveles. 

• La comprobación de accesibilidad a nivel de dependencia verifica si tu código importa o utiliza en absoluto el paquete vulnerable. Esto descarta los paquetes que solo figuran en tu archivo de bloqueo como dependencias transitivas no utilizadas. 
• La accesibilidad a nivel de función va más allá y comprueba si tu código llama a la función específica que contiene el error; así, una aplicación que solo utiliza una biblioteca XML para generar documentos queda exenta de responsabilidad por un CVE en el analizador sintáctico de dicha biblioteca.

Por qué el código accesible puede seguir siendo seguro

Sin embargo, el código accesible no es necesariamente explotable. El código accesible puede seguir siendo seguro cuando un atacante no puede cumplir las condiciones necesarias para que el fallo se active. La mayoría de las vulnerabilidades requieren algo más que la ejecución de la función. Necesitan una entrada controlada por el atacante que adopte una forma específica, que se active una determinada configuración o función, un nivel de privilegios concreto o un entorno de implementación en el que el resultado pueda realmente causarte daño.

La lista de justificaciones de la CISA sobre el estado de VEX (Vulnerability Exploitability eXchange) incluye «código vulnerable que no se encuentra en la ruta de ejecución» y «código vulnerable que no puede ser controlado por un atacante» como motivos independientes por los que un producto no se ve afectado. El primero describe un veredicto de accesibilidad y el segundo, un veredicto de explotabilidad.

¿Qué hace que una vulnerabilidad CVE sea explotable en una aplicación?

Un exploit suele depender de que se den varias condiciones a la vez, por lo que, si en tu aplicación falta alguna de ellas, los ataques fracasarán. El CVSS recoge algunas de estas condiciones en sus métricas de explotabilidad, como los privilegios necesarios y la interacción del usuario. La exposición real de tu aplicación puede situarse muy por encima o muy por debajo de la puntuación publicada.

Accesibilidad frente a explotabilidad en un CVE de Lodash

CVE-2021-23337 Se trata de una inyección de comandos en la biblioteca de utilidades de JavaScript, Lodash. La vulnerabilidad se encuentra en el archivo de Lodash _.plantilla que afecta a las versiones anteriores a la 4.17.21. lodash inserta un valor en el código fuente de la función sin depurarlo, por lo que un atacante que controle esa opción puede introducir código en lugar de un nombre de variable y ejecutarlo cuando se compile la plantilla.

Este CVE tiene una puntuación CVSS de 7,2 y, a fecha de octubre de 2026, una puntuación EPSS de aproximadamente el 21 %, superior al 97 % de los CVE puntuados. No figura en KEV. Esas cifras pueden dar miedo, pero esta información es, por supuesto, totalmente independiente del contexto de tu aplicación. 

Veamos tres aplicaciones que dependen todas de una versión vulnerable de lodash, pero que presentan diferentes grados de accesibilidad y vulnerabilidad.

• La aplicación A nunca llama _.plantilla y solo utiliza herramientas de recopilación como mapa y filtro. análisis de alcanzabilidad puede descartar este hallazgo porque la función vulnerable nunca se ejecuta.
• La aplicación B realiza llamadas _.plantilla para generar un correo electrónico, con la cadena de la plantilla y las opciones codificadas de forma fija por el desarrollador. Reachability lo señala como vulnerable, ya que la función se ejecuta en cada solicitud. Sin embargo, un atacante no puede influir en la variable «option», por lo que análisis de explotabilidad puede rebajar la gravedad del hallazgo con una justificación por escrito.
• La aplicación C distribuye los datos de la solicitud entre las opciones de la plantilla. La función es accesible y los datos introducidos por el atacante llegan a la variable «option», por lo que la gravedad del hallazgo sigue siendo alta. análisis de explotabilidad aumentaría la gravedad o la prioridad del problema.

Un mismo CVE requiere respuestas diferentes en función de la aplicación. 

La vulnerabilidad puede variar a medida que cambia el código.

Si una herramienta de análisis de explotabilidad indica que tu código «no es vulnerable», eso solo refleja el estado actual de tu código y tu implementación. Un nuevo punto de llamada, una nueva ruta de entrada, un cambio en la configuración o una actualización de la imagen base pueden dar la vuelta a ese veredicto.

La corrección de Lodash de 2021 añadió la validación de la opción «variable», pero se le pasó por alto options.imports nombres de claves, que alimentan el mismo Function() constructor. Esa segunda ruta se convirtió en CVE-2026-4800, corregida en lodash 4.18.0.

Así pues, en el ejemplo anterior, la contaminación de prototipos en cualquier otra parte de la aplicación podría alterar la vulnerabilidad de la aplicación B. La contaminación de prototipos permite a un atacante añadir propiedades a Object.prototype (que, si no eres desarrollador de JS, es de lo que heredan casi todos los objetos de JavaScript). _.plantilla copia las propiedades heredadas en las importaciones, por lo que un error de contaminación de prototipos en cualquier otro lugar de la aplicación B podría proporcionar a un atacante esa vía sin que se produzca ningún cambio en la aplicación B. _.plantilla código.

Cómo comprueba Aikido si un CVE es explotable

El CVE de Aikido análisis de explotabilidad lee el código del repositorio junto con el contexto del contenedor vinculado, incluyendo el Dockerfile, la imagen base, la distribución y cómo se está ejecutando el contenedor. Utiliza el agente de Aikido, que analiza cómo se utiliza el paquete vulnerable en tu código o en la imagen del contenedor y decide si el hallazgo es explotable en tu entorno. A continuación, el agente lleva a cabo las acciones de clasificación que tú autorices, que pueden ser ignorar, posponer, rebajar la versión o actualizar. Cada decisión va acompañada de una justificación por escrito del agente, que el revisor puede leer antes de dar su aprobación.

Antes de clasificar un CVE accesible, hay que averiguar si los datos introducidos por un atacante pueden llegar al parámetro vulnerable y cómo deben ser la configuración y el entorno de implementación para que se active el fallo. CVE análisis de explotabilidad realiza esa comprobación para cada CVE incluido en el ámbito de análisis y registra el razonamiento que sustenta cada veredicto.

Puedes activar CVE análisis de explotabilidad para tus repositorios y contenedores vinculados desde la configuración de «Triage» de Aikido. La guía de configuración te explica paso a paso cómo elegir un ámbito de aplicación y las acciones que puede realizar el agente.

Preguntas frecuentes

¿Qué es un CVE?

Un CVE (Common Vulnerabilities and Exposures) es un identificador único para una vulnerabilidad de seguridad dada a conocer públicamente, como CVE-2021-23337. MITRE gestiona el programa CVE, y las organizaciones autorizadas, denominadas «autoridades de numeración CVE», asignan los identificadores, de modo que todas las herramientas y avisos puedan referirse a la misma vulnerabilidad con el mismo nombre.

¿Qué es el CVSS?

El CVSS (Sistema Común de Puntuación de Vulnerabilidades) evalúa la gravedad de una vulnerabilidad en una escala del 0 al 10, basándose en el propio fallo. FIRST se encarga de mantener este estándar, que actualmente se encuentra en su versión 4.0, y las puntuaciones se corresponden con niveles de gravedad que van desde «baja» hasta «crítica». Una puntuación CVSS describe la vulnerabilidad en términos generales, por lo que no tiene en cuenta cómo utiliza tu aplicación el código afectado.

¿Qué es el EPSS?

El EPSS (Exploit Prediction Scoring System) calcula la probabilidad de que una vulnerabilidad CVE sea explotada en algún lugar de Internet en los próximos 30 días. FIRST publica una puntuación entre 0 y 1 para cada vulnerabilidad CVE publicada y la actualiza a diario. Una puntuación alta en el EPSS indica que existe interés por parte de los atacantes en Internet, pero no permite saber si tu propia aplicación está expuesta.

¿Qué es KEV?

KEV es el catálogo de vulnerabilidades explotadas conocidas de la CISA, una lista de CVE cuya explotación se ha confirmado en el entorno real. Las agencias federales de EE. UU. deben corregir las CVE incluidas en el KEV en los plazos establecidos en la Directiva Operativa Vinculante 22-01, y la CISA recomienda a todas las organizaciones que utilicen el catálogo para priorizar la aplicación de parches. A fecha de octubre de 2026, el catálogo recoge unas 1.700 CVE.