Explicación de CVE: el sistema mundial de seguimiento de vulnerabilidades de seguridad

Cada día, los equipos de seguridad se enfrentan a una avalancha de nuevas vulnerabilidades de software: solo en 2025 se revelarán más de 130 cada 24 horas. Sin un sistema común para nombrar y rastrear esas vulnerabilidades, los responsables de la seguridad perderían horas cruciales simplemente tratando de averiguar si dos avisos describen el mismo fallo. Ese sistema compartido es el CVE, y comprender cómo funciona es fundamental para cualquier programa moderno de gestión de vulnerabilidades. Esta guía explica qué significa CVE, cómo se asignan los identificadores, el ecosistema de estándares relacionados y la crisis de financiación de 2025 que estuvo a punto de cerrar todo el programa. Tanto si estás clasificando alertas en un SOC como si estás mapeando controles para una auditoría, la información aquí contenida te ayudará a mejorar el uso diario de los datos del CVE.

¿Qué es CVE?

CVE (Common Vulnerabilities and Exposures) es un sistema de identificación estandarizado que asigna identificadores únicos a las vulnerabilidades de ciberseguridad que se han hecho públicas, lo que proporciona a los equipos de seguridad, los proveedores y los investigadores un lenguaje común para rastrear, analizar y corregir fallos específicos en todas las herramientas y organizaciones de todo el mundo.

La corporación MITRE creó el sistema CVE en 1999 con financiación del Departamento de Seguridad Nacional de los Estados Unidos (DHS) y de la Agencia de Ciberseguridad y Seguridad de las Infraestructuras (CISA). Antes de que existiera el CVE, una misma vulnerabilidad podía tener diferentes nombres en distintos escáneres, avisos y boletines de parches. Esa inconsistencia ralentizaba la coordinación entre equipos y la hacía propensa a errores. El CVE resolvió el problema proporcionando un identificador canónico por cada fallo: un número de referencia al que todas las herramientas, todos los proveedores y todos los analistas pueden remitirse sin ambigüedades.

La magnitud del programa refleja la magnitud del problema. Según el informe «2025 CVE Data Review» de Jerry Gamblin, en 2025 se publicaron 48 185 CVE, una cifra récord que supone un aumento del 20,6 % con respecto a las 39 962 entradas de 2024. El catálogo acumulado supera ahora las 308 000 entradas. Ese crecimiento pone de relieve tanto la ampliación de la superficie de ataque como el papel fundamental que desempeña el CVE a la hora de mantener organizados los datos sobre vulnerabilidades.

La descripción general del programa CVE.org resume su misión de forma concisa: identificar, definir y catalogar las vulnerabilidades de ciberseguridad que se han hecho públicas. El sistema es de uso gratuito, de libre acceso y está integrado en prácticamente todas las principales herramientas de seguridad del mercado.

Por qué el CVE es importante para los equipos de seguridad

Sin el CVE, las organizaciones carecerían de un vocabulario común para hablar de vulnerabilidades específicas. Cuando un escáner detecta una falla y un boletín de parches aborda esa misma falla, el identificador CVE es lo que confirma que se trata del mismo problema. Esa referencia común permite varios flujos de trabajo fundamentales:

• Correlación entre herramientas. Las plataformas SIEM, los escáneres de vulnerabilidades y los sistemas de gestión de parches utilizan el identificador CVE como índice, lo que permite a los analistas correlacionar los resultados sin necesidad de realizar una asignación manual.
• Una comunicación más ágil. En lugar de describir un fallo con palabras, un equipo puede compartir un identificador CVE y todos —desde el analista del SOC hasta el CISO— conocen de inmediato el alcance del mismo.
• Informes de cumplimiento. Marcos normativos como PCI DSS, NIST CSF y NIS2 consideran el seguimiento basado en CVE como un control fundamental para la gestión de vulnerabilidades.
• Información sobre amenazas. Las fuentes de datos de la CISA, los avisos de los proveedores y la información de fuentes abiertas utilizan los identificadores CVE como clave principal para los datos sobre vulnerabilidades.

Cómo se estructuran los identificadores CVE

Un identificador CVE sigue el formato CVE-AÑO-NÚMERO e incluye una descripción, los productos afectados, la puntuación de gravedad y enlaces de referencia. Comprender la estructura de un identificador CVE ayuda a los analistas a analizar rápidamente los avisos y a priorizar las medidas a tomar.

Cada identificador consta de tres componentes:

1. Prefijo CVE. La cadena literal «CVE» que identifica la entrada como parte del programa.
2. Año. El año, expresado en cuatro dígitos, en el que se asignó el identificador CVE (no tiene por qué coincidir con el año en que se descubrió o se dio a conocer la vulnerabilidad).
3. Número secuencial. Una secuencia numérica única. Desde 2014, el programa admite cinco o más dígitos para adaptarse al aumento del volumen, un cambio impulsado por el constante incremento de las declaraciones anuales.

Además del propio identificador, cada registro CVE contiene varios campos de datos:

• Descripción. Una explicación concisa de la vulnerabilidad, incluyendo el software o componente afectado.
• Productos afectados. Versiones y configuraciones afectadas.
• Referencias. Enlaces a avisos de los proveedores, parches y documentos técnicos.
• Fuente de la CNA. La autoridad de numeración CVE que asignó el identificador.

Cómo leer una entrada del CVE

Tomemos como ejemplo CVE-2021-44228, conocido comúnmente como Log4Shell. El identificador indica de inmediato que se asignó en 2021 y que lleva el número de secuencia 44228. El registro CVE describe un fallo de ejecución remota de código en la biblioteca de registro Apache Log4j 2. Su puntuación CVSS —asignada por separado a través del Sistema Común de Puntuación de Vulnerabilidades— es de 10,0, el nivel máximo de gravedad. La sección de referencias incluye enlaces al aviso de Apache, a la página de ampliación de información del NVD y a múltiples análisis de terceros.

Es importante distinguir entre el identificador CVE propiamente dicho y la puntuación CVSS que lo acompaña. El CVE identifica en qué consiste la vulnerabilidad. El CVSS —gestionado por el Foro de Equipos de Respuesta a Incidentes y Seguridad (FIRST)— cuantifica la gravedad de dicha vulnerabilidad en una escala del 0 al 10. Ambos sistemas son complementarios, pero no intercambiables.

Cómo funciona el sistema CVE

Las autoridades de numeración de CVE validan y asignan identificadores a lo largo de un ciclo de vida estructurado, desde el descubrimiento hasta la publicación y el enriquecimiento en el NVD. El proceso se desarrolla en seis etapas:

1. Un investigador descubre una vulnerabilidad en el software, el hardware o el firmware.
2. Informe enviado a un CNA o directamente a MITRE a través del formulario de solicitud de CVE.org.
3. La CNA valida el informe y confirma que la vulnerabilidad cumple los criterios de inclusión en la base de datos CVE.
4. La CNA asigna un identificador CVE dentro de su ámbito de competencia.
5. Entrada de CVE publicada en CVE.org con descripción y referencias.
6. NVD completa el registro con la puntuación CVSS, datos de la Enumeración Común de Plataformas (CPE) y metadatos adicionales.

La jerarquía de las CNA se estructura en tres niveles. MITRE actúa como raíz de primer nivel y supervisa todo el programa. Por debajo de MITRE se encuentran las raíces —organizaciones como la CISA, Google y Microsoft que gestionan grupos de CNA—. En la base se encuentran las propias autoridades de numeración CVE: 365 CNA activas que operan en todo el ecosistema en 2025.

¿Qué es una autoridad de numeración CVE?

Una autoridad de numeración CVE (CNA) es una organización autorizada por el programa CVE para asignar identificadores CVE dentro de un ámbito definido, normalmente sus propios productos o un ámbito tecnológico específico. Las principales CNA por volumen en 2025 ilustran la amplitud del programa:

• Patchstack: 7.007 CVE (ecosistema de WordPress)
• VulDB: 5.902 CVE
• Linux: 5.686 CVE
• MITRE: 5.208 CVE
• Wordfence: 3.451 CVE

Estas cifras, extraídas del análisis de Jerry Gamblin de 2025, muestran que los ecosistemas de código abierto y de aplicaciones web representan actualmente la mayor parte de las nuevas asignaciones de CVE. Cualquier organización puede solicitar convertirse en CNA a través del programa CVE.org.

Cómo notificar una vulnerabilidad a CVE

Los investigadores que descubran una vulnerabilidad pueden notificarla por dos vías. Si el proveedor afectado opera como CNA, el investigador envía la notificación directamente a dicho proveedor. De lo contrario, el investigador puede utilizar el formulario de solicitud de CVE.org, que remite la notificación al CNA correspondiente o, en última instancia, a MITRE.

No todas las notificaciones dan lugar a la publicación de un CVE. En 2025 se rechazaron 1 787 CVE —lo que supone una tasa de rechazo del 3,58 %—, normalmente porque el problema notificado no cumplía los criterios de inclusión del programa o era una duplicación de una entrada ya existente.

El ecosistema CVE: CVE frente a CVSS, CWE y NVD

CVE identifica vulnerabilidades específicas, mientras que CVSS evalúa su gravedad, CWE clasifica los tipos de debilidades y NVD proporciona metadatos enriquecidos. Estos cuatro sistemas suelen confundirse, por lo que una comparación clara ayuda a los profesionales a comprender cómo se complementan entre sí.

Cómo se relacionan CVE, CWE, CVSS y NVD en el proceso de gestión de vulnerabilidades:

El proceso funciona así: un CWE describe la clase general de vulnerabilidad (por ejemplo, CWE-79 para Cross-Site Scripting). Un CVE identifica un caso concreto de esa vulnerabilidad en un producto específico. A continuación, el CVSS asigna una puntuación que indica la gravedad de ese caso concreto. Por último, la Base de Datos Nacional de Vulnerabilidades (NVD) completa el registro CVE con datos estructurados: puntuaciones CVSS, listas de productos afectados y referencias a parches.

En 2025, CWE-79 (Cross-Site Scripting) encabezó todas las categorías de vulnerabilidades con 8.207 casos, y la puntuación CVSS media de todas las CVE publicadas fue de 6,60, lo que la sitúa claramente en el rango de gravedad «media».

Es importante comprender estas diferencias porque responden a preguntas distintas. «¿Cuál es la vulnerabilidad?»: eso es CVE. «¿De qué tipo de vulnerabilidad se trata?»: eso es CWE. «¿Cuál es su gravedad?»: eso es CVSS. «¿Dónde puedo encontrar el registro completo y detallado?»: eso es NVD.

Situación actual del programa CVE (2025-2026)

El programa CVE superó la crisis de financiación de 2025, pero los retrasos en el NVD y los sistemas competidores, como el EUVD y el GCVE, están transformando el seguimiento de vulnerabilidades. En esta sección se analizan los tres avances que los competidores en la SERP pasan por alto sistemáticamente.

La crisis de financiación de 2025 y su resolución

En abril de 2025, el programa CVE estuvo a pocos días de cerrarse. El contrato de MITRE con el DHS para gestionar el programa estaba a punto de expirar y no se había acordado ninguna renovación. SecurityWeek informó de que los responsables de MITRE habían señalado un «posible deterioro» del programa a medida que se acercaba la fecha límite.

El 16 de abril de 2025 ocurrieron dos cosas al mismo tiempo. La CISA consiguió una prórroga provisional de 11 meses para mantener el programa en funcionamiento. Y la recién creada Fundación CVE —una organización sin ánimo de lucro fundada por los miembros del consejo de administración de CVE— se puso en marcha para promover una gobernanza diversificada y a largo plazo.

En enero de 2026, la situación se estabilizó. CSO Online informó de que se había comunicado a la Junta de CVE que «no habría un recorte brusco de la financiación en marzo», y que CVE había pasado a ser un programa fundamental de la CISA. Sin embargo, los detalles de la financiación siguen sin estar claros, lo que los observadores han calificado como un «contrato misterioso con una cifra misteriosa».

EUVD y GCVE: alternativas emergentes

La crisis de financiación impulsó dos enfoques alternativos para el seguimiento de la vulnerabilidad:

• EUVD (Base de datos de vulnerabilidades de la Unión Europea). Lanzada por la ENISA en mayo de 2025 en el marco de la Directiva NIS2, la EUVD ofrece un catálogo de vulnerabilidades gestionado por la UE. No sustituye al CVE, sino que lo complementa, pero proporciona a las organizaciones europeas una fuente de información fiable a escala regional. La Ley de Ciberresiliencia de la UE (CRA) exigirá a los proveedores que notifiquen las vulnerabilidades que estén siendo explotadas activamente en un plazo de 24 horas a partir de septiembre de 2026.
• GCVE (Global CVE). Lanzado por CIRCL en enero de 2026, GCVE adopta un enfoque descentralizado en el que múltiples organizaciones pueden asignar de forma independiente identificadores de vulnerabilidades utilizando el marco GCVE.eu. Aunque sus defensores ven ventajas en términos de resiliencia, Dark Reading señaló las preocupaciones sobre la fragmentación expresadas por los profesionales, a quienes les inquieta el mantenimiento de una única fuente de información fiable.

El retraso en el procesamiento de los datos del NVD

La Base de Datos Nacional de Vulnerabilidades —el sistema gestionado por el NIST que completa los registros CVE con puntuaciones CVSS y datos de CPE— ha tenido dificultades para mantenerse al día. Según un análisis de inventivehq, aproximadamente el 44 % de los CVE añadidos durante el último año carecen de puntuaciones CVSS y de datos sobre los productos afectados (2025).

El NIST agravó el problema al clasificar todas las CVE anteriores a 2018 como «aplazadas»: casi 100 000 registros que ya no recibirán actualizaciones de enriquecimiento (2026). La Oficina del Inspector General del Departamento de Comercio inició una auditoría federal sobre las prácticas de gestión del NVD.

Para los profesionales, la conclusión es clara: los equipos que se basan únicamente en NVD se enfrentan a datos incompletos. El proyecto Vulnrichment de la CISA ofrece una fuente complementaria de enriquecimiento de datos, y el EUVD proporciona un flujo de datos adicional para las organizaciones sujetas a la normativa de la UE.

CVE en la práctica: patrones de explotación en el mundo real

Con más de 130 nuevas vulnerabilidades (CVE) publicadas a diario y un 28 % de los ataques lanzados en las 24 horas siguientes a su divulgación (2025), las organizaciones necesitan un sistema de clasificación automatizado que vaya más allá del seguimiento manual.

Las cifras de 2025 ofrecen un panorama desolador. De las 48 185 vulnerabilidades CVE publicadas, cifra récord, el desglose por gravedad fue el siguiente:

Distribución de la gravedad de los CVE en 2025, basada en las puntuaciones CVSS. Fuente: Análisis de datos CVE de 2025 de Jerry Gamblin.

A pesar del volumen, los actores maliciosos siguen siendo muy selectivos. Solo alrededor del 1 % de las más de 48 000 CVE publicadas en 2025 se confirmó que habían sido explotadas en el mundo real. Sin embargo, cuando se produce la explotación, esta es rápida: el 54 % de las CVE críticas fueron explotadas durante la primera semana tras su divulgación (2025). Los investigadores de seguridad identificaron 884 vulnerabilidades explotadas conocidas con evidencia por primera vez en 2025, y el catálogo KEV de la CISA creció en 244 entradas (un aumento del 28 %), lo que elevó su total a 1.483.

FIRST prevé una media de 59 427 nuevas vulnerabilidades CVE para 2026, una tendencia que hace que el seguimiento manual resulte cada vez más insostenible.

Casos prácticos destacados sobre CVE

Tres ejemplos reales ilustran diferentes patrones de explotación:

• Log4Shell (CVE-2021-44228). Una vulnerabilidad crítica que permite la ejecución remota de código en la biblioteca Apache Log4j 2, con una puntuación CVSS de 10,0. Los atacantes comenzaron a aprovecharla pocas horas después de su divulgación en diciembre de 2021. Dado que Log4j está integrado en millones de aplicaciones, el alcance del impacto fue enorme, y las organizaciones siguen encontrando instancias sin parchear años después.
• MOVEit Transfer (CVE-2023-34362). Una zero-day de inyección SQL zero-day en la herramienta de transferencia de archivos de Progress Software. La operación de ransomware CL0P la aprovechó antes de que estuviera disponible un parche, lo que afectó a unas 130 organizaciones de los sectores gubernamental, financiero y sanitario.
• GoAnywhere MFT (CVE-2025-10035). Otra herramienta de transferencia de archivos afectada por un patrón de ataque a la cadena de suministro. Los autores Medusa aprovecharon la vulnerabilidad antes de que se hiciera pública, ejecutando una cadena de ataque completa que abarcó desde el acceso inicial hasta el movimiento lateral, la exfiltración de datos y la instalación de ransomware.

Uso de datos de CVE para detectar y prevenir ataques

Una defensa eficaz basada en CVE requiere establecer prioridades en función del riesgo, combinando puntuaciones CVSS, el estado KEV de la CISA, información sobre vulnerabilidades y capacidades de detección de comportamientos. El siguiente flujo de trabajo ayuda a los equipos de seguridad a poner en práctica los datos de CVE:

1. Supervisa las fuentes de CVE. Realiza un seguimiento de las nuevas divulgaciones de CVE.org, NVD, el catálogo de vulnerabilidades explotadas de la CISA, EUVD y los avisos específicos de los proveedores.
2. Correlacione esta información con su inventario de activos. Relacione las vulnerabilidades CVE publicadas con su entorno utilizando datos de gestión de activos y de la lista de componentes de software (SBOM) para obtener visibilidad de los componentes de terceros.
3. Priorice utilizando un enfoque basado en el riesgo. Combine la gravedad según el CVSS, el estado KEV de la CISA (¿se está explotando activamente el CVE?), la información disponible sobre exploits y la importancia de los activos para clasificar la urgencia de la corrección.
4. Corrija el problema. Aplique los parches disponibles. Cuando no sea posible aplicar los parches de inmediato, implemente controles compensatorios, como parches virtuales, segmentación de la red o restricciones de acceso.
5. Verifica y realiza un seguimiento. Confirma que la corrección ha sido eficaz volviendo a escanear y actualiza tus sistemas de seguimiento.

El catálogo KEV de la CISA merece una atención especial en la tercera fase. Con un tiempo medio de inclusión en el KEV de tan solo 5,0 días (frente a los 8,5 de años anteriores, 2025), el catálogo ofrece una señal rápida y contrastada de las CVE que los atacantes están utilizando realmente. En virtud de la Directiva Operativa Vinculante 22-01, las agencias federales de EE. UU. deben subsanar las entradas del KEV dentro de los plazos establecidos.

Más allá de los parches basados en CVE: detección basada en el comportamiento

La aplicación de parches basada únicamente en CVE deja lagunas. Zero-day se explotan antes de que exista ningún identificador CVE. La implementación de los parches lleva tiempo. Y algunos entornos —sistemas heredados, tecnología operativa, SaaS de terceros— no pueden actualizarse rápidamente.

La detección de amenazas basada en el comportamiento cubre esa laguna al centrarse en lo que hacen los atacantes tras explotar una vulnerabilidad, en lugar de en el CVE específico que han utilizado. Las soluciones de detección y respuesta en red supervisan los comportamientos posteriores a la explotación —reconocimiento, movimiento lateral, escalada de privilegios, comunicaciones de mando y control y exfiltración de datos— independientemente del vector de entrada.

Un enfoque de defensa en profundidad combina la gestión de vulnerabilidades basada en CVE con capacidades de detección de comportamiento y respuesta ante incidentes. Cuando una zero-day deja temporalmente desprotegidas las defensas basadas en CVE, la detección de comportamiento actúa como red de seguridad.

CVE y cumplimiento normativo

El seguimiento de CVE cumple directamente con los requisitos de cumplimiento de los principales marcos normativos. La siguiente tabla de correspondencias relaciona los procesos de CVE con los controles que buscan los auditores.

Cómo se correlaciona el seguimiento de CVE con los principales marcos de cumplimiento:

Más allá de la correspondencia de marcos, los datos del CVE se vinculan directamente con el Marco MITRE ATT&CK. El Centro para la Defensa Basada en la Información sobre Amenazas (CTID) de MITRE lleva a cabo un proyecto asignación de las técnicas de ATT&CK a los CVE, relacionando vulnerabilidades específicas con los comportamientos de los atacantes. Por ejemplo, la técnica T1190 (Vulnerabilidad en aplicaciones expuestas al público) se corresponde con CVE en servidores web y API, mientras que T1068 («Explotación para la escalada de privilegios») se refiere a vulnerabilidades locales relacionadas con la escalada de privilegios.

Enfoques modernos sobre la inteligencia de vulnerabilidades

La inteligencia moderna sobre vulnerabilidades combina los datos del CVE con la detección de comportamientos y la priorización basada en el riesgo para salvar la brecha entre la divulgación y la explotación. Dado que FIRST prevé una media de 59 427 nuevos CVE para 2026, el antiguo enfoque de aplicar parches a todo en función de la puntuación CVSS se está derrumbando bajo su propio peso.

Varios cambios definen el panorama actual:

• Priorización basada en el riesgo frente a la clasificación basada únicamente en el CVSS. Solo el 1 % de las CVE se confirma que se han explotado en la red (2025). El catálogo KEV de la CISA, las fuentes de información sobre exploits y los datos sobre la criticidad de los activos proporcionan una indicación mucho más fiable que las puntuaciones de gravedad sin procesar por sí solas.
• Enriquecimiento complementario más allá de NVD. Dado que el retraso de NVD afecta al 44 % de las entradas recientes, los equipos están recurriendo a CISA Vulnrichment, EUVD, los avisos de los proveedores y la inteligencia de código abierto para cubrir esa laguna.
• Lista de componentes de software (SBOM) para el seguimiento de dependencias. Las listas de componentes de software permiten a las organizaciones conocer las dependencias transitivas —las bibliotecas de terceros ocultas en lo más profundo de sus aplicaciones— para que puedan evaluar rápidamente la exposición a vulnerabilidades CVE en toda su cadena de suministro de software.
• Automatización y clasificación asistida por IA. Con más de 130 nuevas vulnerabilidades (CVE) al día, la revisión manual resulta inviable. Las organizaciones están adoptando motores de correlación automatizados que comparan las nuevas vulnerabilidades con los inventarios de activos y señalan únicamente aquellas entradas que suponen un riesgo real.
• La detección basada en el comportamiento como complemento. Los programas de gestión continua de la exposición a amenazas y de evaluación de vulnerabilidades combinan cada vez más el análisis basado en CVE con la supervisión del comportamiento para detectar el aprovechamiento de fallos desconocidos o sin parchear.

Cómo Vectra AI el aprovechamiento de vulnerabilidades

Vectra AI la explotación de vulnerabilidades partiendo del supuesto de que el sistema ya ha sido comprometido. En lugar de basarse únicamente en la aplicación de parches según los CVE, Attack Signal Intelligence Vectra AI Attack Signal Intelligence en detectar los comportamientos que muestran los atacantes tras explotar las vulnerabilidades, independientemente de si esos CVE son conocidos, desconocidos o zero-day. Esta metodología garantiza que los defensores puedan identificar patrones de explotación como el movimiento lateral, la escalada de privilegios y la exfiltración de datos, independientemente del CVE específico implicado, lo que reduce la brecha entre la divulgación de la vulnerabilidad y la respuesta de la organización.

Tendencias futuras y consideraciones emergentes

El ecosistema de divulgación de vulnerabilidades está entrando en un periodo de rápidos cambios estructurales. En los próximos 12 a 24 meses, varios avances transformarán la forma en que las organizaciones detectan, priorizan y responden a los CVE.

El volumen seguirá aumentando. La previsión media de FIRST, de 59 427 nuevas CVE para 2026, supone un nuevo incremento del 23 % con respecto al récord de 2025. Los marcos de IA (Langflow, Semantic Kernel) y los planos de control empresarial (dispositivos SD-WAN, infraestructura de identidad, herramientas de migración) están dando lugar a nuevas categorías de vulnerabilidades que apenas existían hace dos años. Los equipos de seguridad deben planificar su personal y sus herramientas partiendo de la hipótesis de que el volumen diario de CVE superará las 160 entradas a finales de 2026.

Los requisitos normativos se endurecerán. La Ley de Ciberresiliencia de la UE (CRA) entrará en vigor en septiembre de 2026 y exigirá a los proveedores que notifiquen las vulnerabilidades que estén siendo explotadas activamente en un plazo de 24 horas. La Directiva NIS2 ya exige una gestión de vulnerabilidades basada en el riesgo para las entidades esenciales e importantes de toda la UE. En EE. UU., la auditoría de la OIG del Departamento de Comercio sobre el NVD podría dar lugar a cambios estructurales en la forma en que el NIST enriquece los datos sobre vulnerabilidades. Las organizaciones que operan en múltiples jurisdicciones deben prepararse para la superposición de las obligaciones de notificación de CVE, EUVD y GCVE.

La descentralización traerá consigo tanto resiliencia como fricciones. La aparición de EUVD y GCVE introduce redundancia, una valiosa garantía frente a puntos únicos de fallo, como la crisis de financiación de 2025. Pero también plantea retos de coordinación. ¿Llevará una vulnerabilidad registrada en GCVE el mismo identificador en CVE? ¿Cómo gestionará NVD el enriquecimiento de las entradas que se originen fuera de la jerarquía tradicional de CNA? Estas preguntas siguen sin respuesta y exigirán la atención tanto de los responsables políticos como de los profesionales del sector.

La clasificación de CVE asistida por IA se convertirá en algo imprescindible. Dada la persistencia del retraso en el NVD y el aumento del volumen, las organizaciones que sigan dependiendo de la revisión manual de CVE se quedarán aún más rezagadas. Cabe esperar una adopción más generalizada de motores de correlación automatizados, modelos de predicción de explotabilidad basados en IA y la integración de datos SBOM en los flujos de trabajo de gestión de vulnerabilidades.

Prioridad de inversión: Las organizaciones deben destinar recursos presupuestarios a la correlación automatizada de CVE, las herramientas SBOM y las capacidades de detección de comportamientos que funcionen independientemente de las asignaciones específicas de CVE, ya que el próximo exploit crítico podría aparecer antes de que se asigne cualquier identificador CVE.

Conclusión

El CVE sigue siendo la base sobre la que se sustenta la forma en que la comunidad de ciberseguridad identifica y comunica las vulnerabilidades. Desde sus orígenes en 1999 hasta el récord de 48 185 entradas publicadas en 2025, el sistema ha crecido al ritmo de una superficie de ataque en constante expansión. Pero esta expansión conlleva retos: la crisis de financiación de 2025, el retraso en el enriquecimiento de la NVD y la aparición de la EUVD y la GCVE son señales de que el ecosistema de vulnerabilidades se está diversificando.

Para los equipos de seguridad, la conclusión práctica es crear flujos de trabajo que vayan más allá de los CVE. Combina el seguimiento de los CVE con una priorización basada en el riesgo utilizando el catálogo KEV de la CISA, complementa los datos del NVD con múltiples fuentes de enriquecimiento e invierte en la detección basada en el comportamiento, que detecta los ataques independientemente de si se ha asignado un CVE. Los atacantes más peligrosos —los que tienen como objetivo a tu organización— no esperarán a que se les asigne un identificador CVE antes de atacar.

Para descubrir cómo Vectra AI las organizaciones Vectra AI detectar comportamientos posteriores a la explotación en cloud de red, de identidad y cloud , explore la Vectra AI .