¿Qué es un CVE? Vulnerabilidades, CVSS y EPSS Explicados

Cuando realizas un análisis de seguridad en tu aplicación o servidor, a menudo obtienes una lista de CVE con puntuaciones como 9,8 Crítico o 5,5 Medio.

Pero, ¿qué significan realmente estas cifras? ¿Hay que corregirlo todo de inmediato? ¿Y por qué algunas vulnerabilidades «críticas» son a veces menos urgentes que otras?

En esta guía encontrarás las respuestas a estas preguntas:

• Qué es un CVE y por qué es útil.
• Cómo interpretar las puntuaciones CVSS sin entrar en pánico.
• Cómo utilizar el EPSS para saber qué vulnerabilidades se están explotando realmente.
• Por qué «0 CVE» no significa «0 riesgo».
• Cómo priorizar correcciones de forma pragmática.
• Cómo buscar CVE desde la web y desde Kali Linux.

¿Qué es CVE y para qué sirve?

CVE (Common Vulnerabilities and Exposures), también conocido como identificador común de vulnerabilidades, es un sistema que asigna un número de identificación único a las vulnerabilidades de software y hardware. Fue creado por la organización sin ánimo de lucro estadounidense MITRE Corporation y permite a los profesionales de la seguridad de todo el mundo consultar información común sobre vulnerabilidades.

En pocas palabras: CVE es un catálogo mundial de vulnerabilidades de seguridad conocidas. Cada vez que se descubre un problema de seguridad en un software o sistema, se le asigna un número único. Ese número es un CVE.

Ejemplo: CVE-2021-44228 es la vulnerabilidad conocida como Log4Shell, detectada en la biblioteca Log4j. Cuando los especialistas en seguridad ven ese identificador, entienden sin lugar a dudas de qué problema se trata, independientemente de la fuente de información o el idioma.

El problema antes del CVE

Antes de la aparición de CVE (sistema lanzado en 1999), muchas vulnerabilidades de seguridad se notificaban sin estar estandarizadas. Cada editor le daba un nombre diferente a la misma vulnerabilidad; los equipos de seguridad no sabían si dos alertas se referían al mismo problema; era difícil hacer un seguimiento de las correcciones.

La gestión y el intercambio de información resultaban difíciles, lo que provocaba con frecuencia retrasos en la aplicación de medidas rápidas.

Cómo resuelve CVE ese problema

CVE resolvió este problema al convertirse en una base de datos unificada para vulnerabilidades. Al asignar un identificador único (CVE-ID) a todas las vulnerabilidades, mantiene la coherencia de la información entre diferentes herramientas y plataformas.

Los escáneres de vulnerabilidades, los sitios web de información de seguridad y las herramientas de seguridad pueden interoperar utilizando el CVE-ID. Además, dado que la lista CVE es abierta y accesible para cualquiera, contribuye en gran medida a la mejora de la seguridad a nivel mundial.

Tanto los atacantes como los defensores consultan la información de CVE para conocer las vulnerabilidades más recientes.

Historia y origen del CVE

CVE fue iniciado en 1999 por MITRE Corporation. El motivo fue el problema de que, en aquel momento, muchas vulnerabilidades de seguridad se notificaban sin estar estandarizadas. El objetivo del CVE fue resolver este problema y unificar la información sobre seguridad. Actualmente se utiliza en todo el mundo como marco básico en el ámbito de la ciberseguridad.

Desde su creación, el sistema CVE está gestionado por MITRE Corporation, que actúa como coordinadora del programa y como la denominada «Root CNA». MITRE mantiene la lista de registros CVE, gestiona el sitio web CVE.org y coordina el trabajo de la comunidad. MITRE es una organización respetada en todo el mundo que cuenta con más de 9 000 empleados, muchos de los cuales participan en diversos aspectos de la ciberseguridad, incluyendo CVE, CWE y ATT&CK.

El patrocinador histórico ha sido la Agencia de Seguridad Cibernética y de Infraestructuras (CISA, una división del Departamento de Seguridad Nacional de los EE. UU.) y, anteriormente, organismos del Departamento de Defensa de los EE. UU. (DoD). La financiación se realizaba mediante contratos: el Estado firma un contrato con MITRE para el mantenimiento del CVE.

Con el crecimiento del ámbito de la seguridad de la información, la base de datos CVE ha alcanzado unas dimensiones enormes: en 2025 se publicaron 48 185 CVE, un aumento del 20,6% respecto a los aproximadamente 40 000 de 2024, llevando el total acumulado por encima de las 308 000 entradas, según las métricas oficiales del programa CVE.

Cómo se estructura un identificador CVE

Los números CVE adoptan el siguiente formato:

CVE-YYYY-NNNNN

Ejemplo completo: CVE-2025-22457

Esto significa «vulnerabilidad número 22457 registrada en 2025». Es como un número de serie que permite a todo el mundo referirse a la misma vulnerabilidad, independientemente del idioma o el país. Cuando tu escáner muestra CVE-2024-3094, puedes buscar ese identificador en cualquier base de datos para entender el problema, comprobar si tu proveedor ha publicado un parche y comparar con otras herramientas que usan el mismo número.

Evolución del formato (2014)

El formato del CVE-ID ha evolucionado con el paso del tiempo. Antes de 2014, el número de dígitos del identificador estaba limitado a cuatro. Debido al aumento de las vulnerabilidades notificadas, se amplió el número de dígitos, pasando de CVE-YYYY-NNNN a CVE-YYYY-NNNNNNN.

Gracias a este cambio, el CVE puede gestionar un mayor número de vulnerabilidades y, en la actualidad, cuenta con cientos de miles de entradas registradas. Paralelamente, el formato estructurado de los registros CVE ha evolucionado hacia versiones más recientes (actualmente la serie 5.x), lo que facilita el intercambio automatizado y la interoperabilidad entre herramientas.

Cómo llega una vulnerabilidad a la lista CVE

El papel de las CNA

Para hacer frente al crecimiento de las vulnerabilidades, el sistema CVE funciona como un modelo descentralizado y federativo. En él desempeñan un papel clave las CNA (CVE Numbering Authorities): organizaciones autorizadas a las que se ha delegado el derecho a asignar identificadores CVE.

Al inicio de CVE, el único organismo de este tipo era el propio MITRE, pero hace ya muchos años que se ha formado una amplia red de CNA en todo el mundo. A fecha de 2024, más de 450 organizaciones de más de 40 países participan en el programa CVE como CNA.

Quiénes son CNA

Fabricantes de software y hardware. Los grandes proveedores asignan ellos mismos los CVE a las vulnerabilidades de sus productos. Microsoft asigna CVE a todas las vulnerabilidades detectadas en Windows, Office y otros productos (y publica boletines mensuales de Patch Tuesday con estos CVE). Google es CNA para sus proyectos (Android, Chrome, servicios en la nube), Red Hat para su software de código abierto, Oracle para bases de datos Java y software corporativo, Cisco para equipos de red de Cisco. Casi todos los grandes fabricantes de software o hardware son hoy en día CNA.

Fabricantes de productos de seguridad de la información. Rapid7 (creadores de Metasploit), Tenable (Nessus) y Qualys tienen la condición de CNA. Pueden asignar un CVE-ID a las vulnerabilidades detectadas por sus departamentos de investigación antes de su divulgación pública.

Coordinadores nacionales/regionales (CERT/CSIRT). CERT/CC (centro de coordinación CERT de la Universidad Carnegie Mellon, EE. UU.) es uno de los primeros CNA. JPCERT/CC actúa como CNA para las empresas y los investigadores japoneses. En Europa hay varios CERT nacionales que actúan como CNA.

Otros. ICS-CERT (actualmente dentro de la CISA) es CNA para vulnerabilidades de sistemas de automatización industrial y SCADA. La propia CISA recibió en 2023 el estatus de Top-Level Root CNA para la industria y los dispositivos médicos. También pueden actuar como CNA grandes proyectos de código abierto a través de coordinadores designados.

El proceso paso a paso

1. Investigación y detección. Las vulnerabilidades son detectadas por investigadores de seguridad: especialistas de empresas, expertos independientes, participantes en programas de bug bounty o equipos de análisis de vulnerabilidades. Cuando se encuentra una nueva brecha, lo correcto es notificarla al desarrollador del producto vulnerable (divulgación responsable) y asignarle un identificador.

2. Recurso a la CNA. La organización autorizada (CNA) es la responsable de asignar el número CVE. Si la vulnerabilidad se encuentra en un producto de un fabricante concreto que es CNA, a menudo es el propio fabricante quien asigna el número CVE. En otros casos, el investigador puede dirigirse a MITRE o a un centro de coordinación (por ejemplo, CERT) para que actúen como CNA.

3. Asignación del CVE-ID. La CNA comprueba que la información sobre la vulnerabilidad cumpla los criterios del CVE: que se trate realmente de un problema nuevo y no de un duplicado de uno ya conocido. A continuación, se asigna un identificador CVE único y se crea un registro con el número, la descripción del problema y enlaces a las fuentes (por ejemplo, avisos de seguridad del fabricante, informes de investigadores).

4. Publicación. La información se hace pública y el registro CVE aparece en el sitio web oficial de la Lista CVE. El contenido inicial del registro puede ser breve, aunque un número creciente de CNA incluyen ya CVSS, CWE y CPE directamente en el registro. Paralelamente, el Instituto Nacional de Estándares y Tecnología (NIST), a través de su Base Nacional de Vulnerabilidades (NVD), recibe esta entrada y la enriquece con detalles técnicos adicionales cuando los procesa. De este modo, MITRE/CVE proporciona el identificador y la descripción, mientras que el NIST/NVD aporta análisis complementario.

5. Uso. Tan pronto como se publica el CVE, los fabricantes de software pueden hacer referencia a él en boletines de seguridad, los escáneres y los SIEM pueden incluirlo en sus bases de datos para la detección, y los analistas pueden utilizarlo en la investigación de incidentes.

Es importante señalar que el CVE solo cataloga las vulnerabilidades reveladas públicamente. Si un problema no se divulga o no se ajusta a la definición (por ejemplo, los errores de configuración no siempre reciben un CVE), es posible que no se incluya en la lista.

Bases de datos relacionadas con CVE

CVE proporciona la base para identificar las vulnerabilidades, pero no proporciona directamente información detallada (como el alcance del impacto o métodos de corrección específicos). Para eso se utilizan bases de datos complementarias.

NVD (National Vulnerability Database): CVE enriquecido con CVSS y CPE

La NVD, mantenida por el NIST en nvd.nist.gov, es una base de datos ampliada que consume los registros CVE. Mientras que CVE proporciona el identificador y la descripción base, la NVD enriquece los registros con puntuaciones CVSS (incluyendo vectores), CPE, clasificaciones CWE, configuraciones afectadas y referencias a parches.

En la práctica actual, existe un backlog significativo en el análisis y enriquecimiento NVD, por lo que un número creciente de CVE publicados por CNA incluyen ya CVSS, CWE y CPE directamente en el registro CVE. Puedes consultar el volumen de entradas pendientes y procesadas en el dashboard oficial del NVD.

Exploit-DB

Exploit Database es una base de datos que recopila códigos de explotación (métodos de ataque) específicos relacionados con CVE y pruebas de concepto (Proof of Concept). Mientras que el CVE indica la existencia de una vulnerabilidad, Exploit-DB muestra concretamente cómo aprovecharla para lanzar un ataque.

Esta base de datos es utilizada por investigadores de seguridad y pentesters para evaluar la viabilidad de las vulnerabilidades. Al vincular Exploit-DB con el CVE, se puede determinar el riesgo de que las vulnerabilidades detectadas se utilicen en ataques reales.

Es uno de los recursos que los atacantes consultan mediante métodos OSINT para identificar formas de comprometer sistemas objetivo. Para el defensor, esa misma información es esencial para priorizar la respuesta.

OpenVAS y escáneres de vulnerabilidades

Las herramientas de escaneo de vulnerabilidades como OpenVAS (Open Vulnerability Assessment System) integran y utilizan la información de CVE.

Estas herramientas escanean redes y sistemas e identifican vulnerabilidades conocidas basándose en el CVE-ID. OpenVAS genera el CVE-ID como resultado del escaneo y explica cómo corregir la vulnerabilidad y las consecuencias asociadas. Nessus, de Tenable, también es un escáner de vulnerabilidades comercial que se apoya en la información de CVE para sus detecciones.

CVE vs NVD: qué aporta cada uno

La información estandarizada de CVE tiene importancia para todo el sector de la seguridad porque distintas herramientas y plataformas pueden usarla de forma interoperable. Muchos productos de seguridad, como los sistemas de detección de intrusiones (IDS), la gestión de eventos e información de seguridad (SIEM) y las herramientas de gestión de parches, integran la información basándose en los ID de CVE. Esto permite priorizar los incidentes de seguridad y responder a ellos con rapidez.

Cómo buscar un CVE

Desde la web

Los recursos principales para consultar CVE son:

Para cada recurso se puede buscar por nombre de producto, versión o número de CVE directamente. Por ejemplo, si el servidor Apache que utilizas se ve afectado por CVE-2024-12345, puedes buscar ese identificador en la NVD para comprobar si hay una actualización que corrija esa vulnerabilidad y aplicarla.

NVD se actualiza, en principio, a diario. Cada proveedor publica un aviso entre unos días y unas semanas después de descubrir la vulnerabilidad. Para mantener una vigilancia activa, es posible suscribirse al feed RSS del sitio web oficial de CVE o al servicio de notificaciones de NVD.

Desde Kali Linux con searchsploit

También puedes realizar búsquedas en estas bases de datos desde la línea de comandos de Kali Linux. La herramienta searchsploit permite consultar Exploit-DB localmente:

searchsploit <nombre del software o componente>

Por ejemplo, para buscar vulnerabilidades en Cisco ASA:

searchsploit cisco asa

Cada entrada contiene el nombre de la vulnerabilidad y la ruta al script que puede utilizarse para explotarla. Para ver los detalles de un exploit específico se usa el flag -p seguido del número único que identifica el exploit. Por ejemplo, si el exploit tiene el número 41369.txt:

searchsploit -p 41369.txt

Tenemos una guía dedicada a searchsploit si quieres profundizar en su uso.

Desde la API (EPSS)

La API de FIRST permite consultar la puntuación EPSS de cualquier CVE de forma gratuita:

curl -s "https://api.first.org/data/v1/epss?cve=CVE-2024-3094" | jq

Respuesta típica:

{
  "data": [
    {
      "cve": "CVE-2024-3094",
      "epss": "0.859950000",
      "percentile": "0.993510000",
      "date": "2025-12-10"
    }
  ]
}

• epss: probabilidad de explotación (0,86 = 86%).
• percentile: rango en relación con otros CVE (0,99 = más explotada que el 99% de las vulnerabilidades).

CVSS: la puntuación de gravedad

Cuando se publica un CVE, los expertos le asignan una puntuación CVSS (Common Vulnerability Scoring System) para indicar su gravedad. Es una puntuación de 0 a 10:

Qué factores considera el CVSS

El CVSS se calcula a partir de varios criterios:

• ¿Cómo se lleva a cabo el ataque? ¿A través de Internet? ¿De forma local? ¿Se necesita acceso físico?
• ¿Es fácil? ¿Unos pocos clics o varios días de trabajo?
• ¿Se necesitan privilegios especiales? ¿Ser administrador? ¿Tener una cuenta?
• ¿Cuál es el impacto? ¿Robo de datos? ¿Toma de control total? ¿Simple ralentización?

El CVSS se compone, en su especificación actual (v4.0), de cuatro grupos métricos: Base (impacto intrínseco), Threat (actividad de explotación), Environmental (contexto del entorno) y Supplemental (contexto adicional no puntuado). Evalúa de forma integral el impacto y la probabilidad de explotación de la vulnerabilidad en escenarios operativos reales.

La trampa de una puntuación alta

Una puntuación de 9,8 da miedo, pero no indica si alguien realmente está explotando esa vulnerabilidad. Una CVE crítica en un servidor aislado sin acceso a Internet suele ser menos urgente que una CVE de gravedad media en tu sitio web público.

El contexto importa tanto como la puntuación.

Versiones de CVSS

Existen varias versiones de CVSS, cada una con sus propios criterios de evaluación. La versión más reciente es CVSS v4.0, que introduce métricas adicionales orientadas a reflejar mejor el contexto operativo y la actividad de explotación.

En la práctica, muchas herramientas siguen utilizando CVSS v3.1 por compatibilidad, mientras que la adopción de v4.0 es progresiva según el ecosistema de herramientas y bases de datos.

EPSS: probabilidad real de explotación

Diferencia con CVSS

El CVSS mide la gravedad teórica. Pero no todas las vulnerabilidades críticas se explotan. Algunas CVE con puntuación 9,8 permanecen inactivas durante años sin que ningún atacante se interese por ellas.

EPSS (Exploit Prediction Scoring System) responde a otra pregunta: «¿Cuál es la probabilidad de que esta vulnerabilidad se explote en los próximos 30 días?»

Es un porcentaje basado en datos reales: ataques observados en todo el mundo, herramientas de explotación disponibles e historial de explotación de vulnerabilidades similares.

En términos simples: CVSS = «¿Es grave si ocurre?». EPSS = «¿Va a ocurrir?». Ambos juntos ayudan a priorizar de forma inteligente.

Herramientas que integran EPSS

Algunos escáneres ya integran el EPSS de forma nativa:

• Grype: compatibilidad nativa (reforzada con datos KEV y EPSS en versiones posteriores a 2024), calcula un valor de RISK compuesto (CVSS × factores de EPSS y KEV) y permite ordenamiento por probabilidad de explotación.
• Dependency-Track: compatibilidad nativa en la interfaz y la API REST.
• Trivy: no integra EPSS de forma nativa en todas sus salidas, pero puede enriquecerse mediante integraciones externas o pipelines que correlacionan resultados con fuentes EPSS.

Ejemplo de escaneo de una imagen con Grype ordenado por probabilidad de explotación:

grype node:14 --sort-by epss

Resultado (extracto):

NAME             INSTALLED           FIXED IN         VULNERABILITY   SEVERITY  EPSS           RISK
libnghttp2-14    1.36.0-2+deb10u1    1.36.0-2+deb10u2 CVE-2023-44487  Alta      94,4% (99.º)   78,8  (kev)
libwebp6         0.6.1-2+deb10u1     0.6.1-2+deb10u3  CVE-2023-4863   Alta      94,1% (99.º)   85,6  (kev)
libc6            2.28-10+deb10u2     2.28-10+deb10u3  CVE-2024-2961   Alta      92,9% (99.º)   68,8
libssl1.1        1.1.1n-0+deb10u4    1.1.1n-0+deb10u5 CVE-2023-2650   Media    91,9% (99.º)   52,8
git              1:2.20.1-2+deb10u8                   CVE-2024-32002  Crítico  80,1% (99.º)   72,1

• EPSS: probabilidad de explotación en los próximos 30 días (94,4% = muy alta).
• (99.º): percentil (este CVE se explota más que el 99% de los demás).
• (kev): presente en la base de datos KEV de la CISA (explotación confirmada en entornos reales).
• RISK: puntuación compuesta calculada por Grype a partir de CVSS, EPSS y presencia en KEV.

CVE-2023-44487 (HTTP/2 Rapid Reset) y CVE-2023-4863 (WebP) fueron explotadas masivamente en 2023. Con un EPSS superior al 90%, son urgencias absolutas.

Cómo priorizar vulnerabilidades

Tabla CVSS + EPSS

El contexto importa más que la puntuación

Para priorizar correctamente hay que considerar tres factores:

¿Dónde se encuentra el problema?

¿Cuál es la puntuación CVSS y la probabilidad de explotación EPSS?

¿Qué acción tomar? Para cada CVE hay tres opciones: corregir (actualizar el componente vulnerable), evitar (añadir protecciones: cortafuegos, restricciones de acceso), o aceptar (documentar por qué no se corrige temporalmente).

Es posible crear un archivo .trivyignore para enumerar los CVE que se aceptan temporalmente, con una fecha de revisión:

# Aceptado hasta el 01-06-2025 - no hay parche disponible
CVE-2024-12345

# Falso positivo - este componente no se utiliza
CVE-2024-67890

0 CVE ≠ 0 riesgo

A veces aparecen mensajes de marketing como «nuestra imagen Docker: ¡0 CVE!» o «sistema ultraseguro: ¡sin vulnerabilidades!». Cuando un escáner muestra «0 CVE», significa: «entre las vulnerabilidades conocidas y registradas en mi base de datos, ninguna se corresponde con los componentes que he podido detectar».

Esto no cubre: vulnerabilidades aún no descubiertas (zero-days), componentes que el escáner no ha visto (binarios ocultos, plugins), vulnerabilidades aún no puntuadas (puede haber meses de retraso), y configuraciones incorrectas (contraseña débil, puertos abiertos).

Los CVE son solo una pieza del rompecabezas. La seguridad también implica buenas configuraciones, copias de seguridad, supervisión y sentido común.

Qué tipos de vulnerabilidades cubre el CVE

Software

El CVE se centra principalmente en vulnerabilidades relacionadas con el software. Entre ellas se incluyen el desbordamiento de búfer, la inyección SQL, el cross-site scripting (XSS) y los fallos de autenticación.

Estas son técnicas comunes que los atacantes utilizan para acceder de forma no autorizada a los sistemas. Puedes ver una visión general de las principales en nuestro post sobre vulnerabilidades web.

Hardware

En los últimos años, las vulnerabilidades relacionadas con el hardware también se han incluido en el CVE. Por ejemplo, las vulnerabilidades de CPU Spectre y Meltdown se difundieron ampliamente a través del CVE-ID. Esto permitió a los desarrolladores y usuarios de productos de hardware tomar medidas rápidamente.

Día cero

Las vulnerabilidades de día cero son uno de los ámbitos que reciben especial atención en el marco de CVE. Una vulnerabilidad de día cero es aquella en la que el ataque comienza antes de que el proveedor haya tomado medidas. Dado que el riesgo de que los atacantes aprovechen este tipo de vulnerabilidades es muy alto, se asigna rápidamente un CVE-ID y se comparte la información.

Cuando se produce un ataque de día cero, se asigna inmediatamente un CVE-ID y se publica una lista de los sistemas y programas afectados.

Qué queda fuera

Para que CVE reconozca una vulnerabilidad, esta debe cumplir varios criterios. Si la vulnerabilidad no se limita a un producto o software específico y tiene un impacto generalizado, es muy probable que se le asigne un CVE-ID.

Por otro lado, las vulnerabilidades que solo afectan al entorno local o los problemas ajenos a la seguridad pueden quedar excluidos de CVE. Los errores de configuración no siempre reciben un CVE.

CVE en la práctica: cómo lo usa un atacante y cómo te defiendes

Escenario real: NVD → Shodan → explotación

Las bases de datos de vulnerabilidades no son herramientas exclusivas para los defensores. Un atacante puede obtener una actualización del NVD sobre una nueva vulnerabilidad CVE y, a continuación, realizar una búsqueda en Shodan para localizar dispositivos expuestos a dicha vulnerabilidad.

Tan pronto como un hacker obtiene información sobre los sistemas del objetivo mediante métodos OSINT, puede buscar en las bases de datos de vulnerabilidades una forma de acceder a dichos sistemas.

Este escenario no es hipotético: los investigadores siguen descubriendo nuevas vulnerabilidades que son explotadas, y ese ciclo continúa. Por eso es tan importante organizar una gestión de parches constante y exhaustiva.

Herramientas defensivas

Cuando ejecutas un escáner como Trivy o Grype, esto es lo que ocurre internamente:

1. INVENTARIO          2. COMPARACIÓN                3. INFORME
   ¿Qué                   ¿Hay vulnerabilidades          Mostrar resultados
   está instalado?         conocidas?

   Python 3.9      →    CVE-2024-XXXX ?    →    ⚠️ 3 CVE encontradas
   OpenSSL 1.1     →    CVE-2023-YYYY ?    →    de las cuales 1 crítica
   nginx 1.20      →    (sin CVE)          →    sin coincidencias

El escáner enumera todos los componentes, compara esta lista con bases de datos CVE conocidas y muestra las coincidencias con sus puntuaciones.

Cada escáner utiliza bases de datos diferentes. Al combinar varias herramientas, aumentas las posibilidades de detectarlo todo:

• Trivy: versátil, rápido, muy popular.
• Grype: ligero, bien integrado con los SBOM.
• Dependency-Track: seguimiento centralizado a lo largo del tiempo.

Para encontrar herramientas de escaneo de vulnerabilidades, consulta nuestro post sobre herramientas para escanear vulnerabilidades web.

Gestión de parches

La información CVE está vinculada a las actualizaciones de seguridad (parches) que proporcionan los proveedores de software. Al consultar el CVE durante la gestión de parches, se puede saber qué vulnerabilidades se corrigen. Por ejemplo, si se lanza el parche más reciente para un software afectado por CVE-2024-45678, se comprueba que dicho CVE ha sido corregido y se aplica el parche.

Buenas prácticas esenciales:

• Escanea regularmente: no solo una vez, sino en cada implementación.
• Prioriza por contexto: exposición + puntuación + explotación.
• Centraliza el seguimiento: una herramienta o una tabla para tener visibilidad completa.
• Documenta tus decisiones: por qué corriges o no.

Qué evitar:

• Aspirar a «0 CVE» a toda costa: vas a distorsionar los informes en lugar de reducir el riesgo real.
• Creer que la puntuación lo dice todo: un 9,8 aislado es menos urgente que un 6,0 expuesto a Internet.
• Ignorar los CVE sin puntuación: sin puntuación no significa que no sea grave.

KEV: la lista de vulnerabilidades explotadas activamente (CISA)

La CISA mantiene la base de datos KEV (Known Exploited Vulnerabilities): catálogo autoritativo de vulnerabilidades con evidencia confirmada de explotación activa en la wild (más de 1 500 entradas a fecha actual). Su inclusión es uno de los indicadores de mayor prioridad operativa, independientemente del CVSS.

El indicador (kev) que aparece en los resultados de Grype indica precisamente que esa vulnerabilidad está en la lista KEV. Es el nivel más alto de prioridad: no hay que esperar análisis CVSS ni EPSS, hay que corregirla de inmediato.

El uso de KEV permite priorizar vulnerabilidades con explotación confirmada en entornos reales, lo que mejora significativamente los tiempos de remediación frente a enfoques basados únicamente en CVSS o listados generales de CVE.

Las organizaciones que incorporan KEV a sus procesos remedian estas vulnerabilidades de forma considerablemente más rápida que las que dependen solo del CVSS, según este análisis de The Record.

Casos de uso prácticos de KEV:

• Priorización absoluta: las CVE de la lista KEV deben corregirse antes que cualquier otra, independientemente de la puntuación CVSS.
• Justificación para los departamentos de TI: basándose en KEV, se pueden establecer plazos claros para la corrección de vulnerabilidades y justificar su criticidad para el negocio.
• Supervisión activa: monitorizando KEV se puede detectar en tiempo real si alguna vulnerabilidad presente en los sistemas ya está siendo explotada en la naturaleza.

La crisis del CVE en 2025 y la CVE Foundation

Durante muchos años, el contrato para la gestión de CVE entre el Gobierno de EE. UU. y MITRE se renovaba con regularidad. Sin embargo, en abril de 2025 llegó a su fin el periodo contractual y surgió la amenaza real de que el Estado dejara de financiar CVE.

El 15 de abril de 2025, la Junta de CVE recibió una carta de MITRE informando de que el Gobierno de EE. UU. no tenía previsto renovar el contrato. El 16 de abril podría haber sido el último día en que MITRE prestara apoyo al CVE.

Para la industria mundial de la seguridad de la información, esto supuso una sorpresa: a pesar de todos los problemas, el CVE se percibe como una «ciberinfraestructura», parte del trabajo diario de miles de equipos de seguridad. La pérdida repentina de este sistema amenazaba con provocar el caos en los procesos de gestión de vulnerabilidades de las empresas y con la proliferación de desinformación.

La CISA ejerció la opción contractual en el último momento y prorrogó el acuerdo por 11 meses hasta marzo de 2026. Posteriormente, se informó a la Junta en enero de 2026 que no existía un “funding cliff” inmediato en marzo de 2026 y que las operaciones continuaban bajo CISA/MITRE con financiación incremental asegurada a corto-medio plazo. No obstante, la dependencia de ciclos presupuestarios federales estadounidenses sigue siendo un riesgo estructural.

Ante esta situación, varios miembros influyentes de la Junta del CVE anunciaron en abril de 2025 la creación formal de la CVE Foundation: una organización sin ánimo de lucro independiente para contribuir a la viabilidad a largo plazo, estabilidad e independencia del programa CVE mediante financiación diversificada.

La idea es que, en lugar de depender por completo de la financiación de un solo gobierno, CVE se convierta en un proyecto global abierto con financiación y gestión distribuidas.

La Fundación CVE captaría fondos de diversas fuentes: organizaciones internacionales, empresas privadas y asociaciones sectoriales. Se espera que gigantes como Microsoft, Google, Amazon y organizaciones internacionales como FIRST actúen como patrocinadores, en un modelo similar al de Linux Foundation o Apache Foundation. Puedes conocer más sobre su misión en el sitio oficial de la CVE Foundation.

Esta no fue la primera crisis del CVE. En 2015-2016 surgió el problema de los retrasos en la asignación de CVE: debido a la escasez de recursos, MITRE no daba abasto para procesar todas las solicitudes.

Según estimaciones de expertos, en 2015 más de 6 000 vulnerabilidades conocidas no recibieron a tiempo sus identificadores CVE. Bajo la presión de la comunidad e incluso del Congreso de los Estados Unidos, se adoptaron medidas: se aumentó la financiación, se amplió el número de CNA y se simplificaron algunos procesos.

Futuro del sistema CVE

El programa CVE sigue evolucionando para adaptarse a los cambios en el ámbito de la seguridad. Entre las direcciones de evolución más relevantes se encuentran las siguientes:

Automatización e IA. Se avanza en el uso de aprendizaje automático para cotejar descripciones, detectar duplicados y enriquecer registros CVE.

Almacenamiento más distribuido. Para que la Lista CVE no dependa de una sola organización, se está considerando ubicar réplicas de la base de datos en diferentes participantes de confianza, con servidores espejo en diferentes países.

Refuerzo del papel de los socios internacionales y mitigación de riesgos de fragmentación. Tras la crisis de 2025, han surgido iniciativas como la EUVD de ENISA y coaliciones internacionales (GCVE) como respaldo a posibles limitaciones en la asignación centralizada. Esto reduce la dependencia exclusiva de MITRE/CISA pero introduce el riesgo operativo de divergencia en identificadores o procesos entre ecosistemas.

Integración con ecosistemas de código abierto. Google está desarrollando la base de datos OSV.dev (Open Source Vulnerabilities), donde los identificadores se generan bajo el esquema GHSA (GitHub Security Advisory) u OSV. Muchas de estas vulnerabilidades también reciben un CVE a través de la CNA. Es probable que el Programa CVE y OSV colaboren más estrechamente. Un posible futuro: un ecosistema interconectado en el que CVE cubra todas las vulnerabilidades públicas, y las diferentes plataformas (NVD, OSV, bases de datos CERT) se sincronicen bajo formatos estructurados estándar.

Diferencia entre CVE y CWE. El CVE es el número que identifica la vulnerabilidad en sí; el CWE (Common Weakness Enumeration) clasifica el tipo y la causa de las vulnerabilidades. Por ejemplo, CWE-79 corresponde a cross-site scripting. Ambos son complementarios: el CWE explica «por qué existe» la vulnerabilidad, mientras que el CVE dice «dónde ocurre concretamente».

Recursos oficiales para consultar CVE