Tendencias de publicación de CVE

En 2025 se publicaron 47.802 registros CVE, un 20 % más que el año anterior. 2026 ya ha alcanzado los 88.746, y aún le quedan meses por delante.

El volumen ha crecido cada año desde que comenzó el CVE Program, pero el ritmo de crecimiento cambió bruscamente en 2026. Utilice el gráfico anterior para ver la tendencia por mes, trimestre o año.

En esta página. El gráfico y las cifras anteriores son estadísticas de CVE que se regeneran a diario a partir del repositorio cvelistV5 del CVE Program, la misma fuente desde la que publica el CVE Program.

Cubren el volumen de publicación por gravedad CVSS, por organización asignadora y por semana, mes, trimestre o año, junto con los registros críticos más recientes. Para ver el detalle de una vulnerabilidad concreta, siga cualquier identificador hasta cve.org.

Están ocurriendo tres cosas a la vez, y los registros publicados no permiten separarlas.

Ahora hay más organizaciones que pueden asignar ID de CVE, así que se registran vulnerabilidades que antes nunca se registraban. El descubrimiento de vulnerabilidades automatizado y asistido por IA ha aumentado lo que puede encontrar cada investigador. Y el programa de enriquecimiento de CISA ha completado con datos los registros antiguos, lo que cambia las cifras históricas a posteriori.

Por tanto, el aumento del número de CVE no demuestra por sí solo que el software sea cada vez menos seguro.

Una CNA es una organización autorizada para asignar ID de CVE y publicar registros dentro de su propio ámbito, normalmente sus propios productos. En este conjunto de datos aparecen 497 CNA.

Proveedores, proyectos de código abierto, plataformas de bug bounty y CERT nacionales actúan como CNA. La mayor aquí es mitre, con 39.586 registros. Como el cambio de proceso de una sola CNA puede mover notablemente los totales, el gráfico le permite filtrar por una organización cada vez.

CVSS puntúa una vulnerabilidad de 0,0 a 10,0 y la agrupa en franjas: Baja (0,1-3,9), Media (4,0-6,9), Alta (7,0-8,9) y Crítica (9,0-10,0).

La puntuación describe características técnicas intrínsecas, como la forma de llegar a la vulnerabilidad y lo que compromete. No es una medida del riesgo que corre una organización concreta.

El 18.0% de los registros publicados desde 2020 no tiene puntuación CVSS ni en los datos de la propia CNA ni en el enriquecimiento de CISA.

La puntuación no fue obligatoria durante la mayor parte de la historia del CVE Program. La cobertura mejora notablemente a partir de 2023 y hoy es casi universal, de modo que la reducción de la franja Desconocida en el gráfico refleja un cambio en la práctica de notificación, no un cambio en las propias vulnerabilidades. Cualquier análisis que ignore los registros sin puntuación subestimará los años más antiguos.

Una vulnerabilidad es un fallo en el software. Un CVE es un identificador público asignado a un caso concreto y divulgado de ese fallo.

La mayoría de las vulnerabilidades nunca reciben un CVE: se encuentran y se corrigen internamente, o quedan fuera del ámbito de cualquier CNA. Por tanto, el número de CVE mide la actividad de divulgación, no la cantidad real de fallos que existen.

Todas las cifras se elaboran a partir del repositorio oficial cvelistV5 del CVE Program, con la instantánea tomada el 31 oct 2026 UTC.

Los registros se cuentan por fecha de publicación y no por el año del ID de CVE, ya que aproximadamente una quinta parte de los registros se publica en un año distinto del que indica su identificador. Se excluyen los registros rechazados y retirados.

Por sí sola, no. Una vulnerabilidad Crítica en un componente que usted distribuye pero nunca invoca puede ser menos urgente que una Media en su API pública.

Una priorización real necesita saber si el componente afectado está presente en su software, si se puede alcanzar el código vulnerable y si la vulnerabilidad se está explotando. CVSS no responde a ninguna de esas preguntas.

El CRA exige a los fabricantes gestionar las vulnerabilidades durante toda la vida útil con soporte de un producto, notificar a ENISA las vulnerabilidades explotadas activamente en un plazo de 24 horas desde que tienen conocimiento de ellas y mantener actualizada la documentación técnica.

Esas obligaciones crecen con el volumen que muestra este gráfico. Hacer el triaje manual de decenas de miles de registros nuevos al año frente a su propio software no es realista, y por eso el CRA presupone en la práctica una SBOM y un proceso de cotejo automatizado.

Necesita un inventario preciso de lo que contiene su software y, después, un cotejo continuo de ese inventario con el feed de CVE.

CRACI genera una SBOM a partir de su build, la coteja con los nuevos registros CVE a medida que se publican y muestra solo los avisos que llegan al código que usted distribuye realmente, junto con la documentación que el CRA espera que conserve.

Vea cómo funciona en la práctica el seguimiento de vulnerabilidades.