La empresa de capital riesgo a16z acaba de publicar un gráfico que se ha vuelto viral en X en los últimos días. El gráfico muestra cómo los CVE críticos y de alto riesgo han pasado de menos de 100 al mes a más de 600 al mes desde la primavera de 2026 en 21 importantes empresas de software. Los datos proceden de Epoch AI e incluyen las cifras de Apple, AWS, Microsoft, Google y Adobe.
Y como se trata de X, es lógico que la gente haya dado su opinión (sí, nosotros también lo estamos haciendo aquí).
Se dividieron en dos bandos. Unos lo interpretaron como un cambio real en el nivel de riesgo, mientras que otros señalaron que las vulnerabilidades conocidas y explotadas (KEV) no han variado desde 2024, por lo que el mero hecho de que haya más revelaciones no implica necesariamente un mayor peligro.
Incluso el propio informe de a16z se muestra cauteloso al respecto:
«Es difícil determinar, con solo mirar el gráfico, si realmente hay más vulnerabilidades o si se debe a algún cambio en la forma de notificarlas o en su definición, pero es probable que al menos parte (y quizá gran parte) de este crecimiento parabólico se deba a un cambio sustancial e importante, ya sea en la forma en que se descubren las vulnerabilidades o en lo que todavía se considera seguro».
Pero ambas partes están interpretando esto de forma totalmente errónea. Ni el recuento bruto de nuevas CVE ni una cifra fija de KEV determinan realmente el riesgo. El riesgo viene determinado por la rapidez con la que se pueden identificar las vulnerabilidades relevantes y por la rapidez con la que se corrigen una vez validadas.
Está claro que la inteligencia artificial ha facilitado enormemente la detección de vulnerabilidades (tanto para los atacantes como para los defensores). Los modelos de vanguardia detectan vulnerabilidades más rápido de lo que tardan los revisores en validarlas, incluidos errores que llevaban mucho tiempo sin detectarse y que habían pasado desapercibidos tras años de revisión manual.
Así pues, el repunte que se observa en el gráfico de a16z se explica, en efecto, por el hecho de que la IA permite detectar más rápidamente los errores que ya existían, y no porque el software se haya vuelto de repente menos seguro. Pero eso es solo una parte de la historia.
¿Qué ocurre cuando una institución intenta mantenerse al día con la detección sencilla?
El NIST, la institución que todo el mundo considera la referencia indiscutible en materia de datos sobre vulnerabilidades, se enfrenta exactamente al mismo problema, pero a mayor escala. Partiendo de la hipótesis de que un mayor número de CVE suponía un mayor peligro, había estado intentando asignar una puntuación a cada CVE que recibía. Sin embargo, el enorme volumen de CVE hacía que esto resultara prácticamente imposible. Y, finalmente, el sistema colapsó.
Una auditoría federal realizada este mes de mayo reveló que el número de casos pendientes había aumentado de 13 000 a más de 27 000 en dieciocho meses. ¿Cuál es la solución propuesta por el NIST? Dejar de puntuarlo todo. En su lugar, se está dando prioridad a las CVE relacionadas con el uso federal, el software crítico o aquellas que ya figuran en la lista de vulnerabilidades explotadas de la CISA. Todo lo demás se marca como «sin programar», por lo que es probable que no se vuelvan a examinar.
La dificultad a la que se enfrenta el NIST radica en conseguir que una vulnerabilidad se dé a conocer y se evalúe. Pero incluso en el caso de aquellas que superan por completo ese umbral —es decir, que están confirmadas, evaluadas y de las que se sabe que están siendo explotadas activamente—, parece que es a la hora de solucionarlas donde las cosas siguen fallando.
La reparación es el cuello de botella
El Informe sobre investigaciones de filtraciones de datos de Verizon de 2026, basado en más de mil millones de registros de vulnerabilidades, reveló que solo el 26 % de las vulnerabilidades confirmadas que se explotaban activamente (incluidas en la lista KEV de la CISA) se corrigieron por completo en 2025, lo que supone un descenso respecto al 38 % del año anterior. El tiempo medio necesario para aplicar el parche completo a una de ellas aumentó a 43 días, frente a los 32 anteriores.
Incluso las organizaciones con mayores recursos solo logran corregir por completo entre el 30 % y el 40 % de estas vulnerabilidades durante la primera semana. Verizon denomina a esto la «paradoja de la corrección», que no es más que una forma elegante de decir que las vulnerabilidades se multiplican mientras que su corrección se ralentiza.
Se sabe que estas vulnerabilidades están siendo explotadas activamente y que figuran en una lista pública. Y aún así no se están solucionando con la suficiente rapidez.
Cómo es realmente la reparación rápida
Este mes, una vulnerabilidad de ejecución de código (RCE) sin autenticación denominada «Stylesmuggler» comenzó a afectar a Adobe Commerce y Magento Open Source. No se le había asignado ningún CVE ni se había publicado ningún aviso por parte de Adobe.
Una vulnerabilidad no necesita un número CVE ni un aviso del fabricante para ser real o para que se aproveche. Esperar a que se produzca cualquiera de las dos cosas antes de actuar significa que los atacantes ya llevan ventaja. La única forma de evitarlo es confiar en algo que pueda detectar y confirmar las vulnerabilidades por sí mismo, y solucionarlas rápidamente en cuanto las detecte.
Aikido Intel la detectó de forma independiente, sin esperar a que Adobe o un número CVE confirmaran su autenticidad. Realizó un seguimiento de la vulnerabilidad en tres entidades distintas, y Aikido Libraries lanzó una corrección operativa para varias versiones afectadas. Se distribuyó como una solicitud de incorporación de cambios (pull request) de AutoFix directamente en el flujo de trabajo que ya utilizan los equipos, en lugar de mediante una migración manual separada y laboriosa. Todo ello antes de que Adobe publicara su propia corrección de emergencia más de 24 horas después.
Sin embargo, StyleSmuggle no es un caso aislado. Durante el primer año de funcionamiento de Intel, el 67 % de los paquetes en los que se detectaron vulnerabilidades nunca se dieron a conocer públicamente en ninguna base de datos (ni en NVD, ni en GitHub Advisory, ni en MITRE, ni en ningún otro sitio).
Así que la verdadera historia es…
El aumento del volumen de CVE es similar al número de paquetes npm que se publican cada año: se acumula, por lo que observar cómo crece es, en cierto modo… irrelevante. Lo que importa es la rapidez con la que se corrige una vulnerabilidad real y confirmada, y en estos momentos, en todo el sector, no es lo suficientemente rápida.
A medida que la inteligencia artificial convierte en algo habitual las capacidades de detección y explotación, la ciberseguridad tiene que reinventarse en torno a lo que ocurre una vez que se ha detectado algo. Esto empieza por saber cuáles de las vulnerabilidades detectadas son realmente accesibles y explotables. La herramienta « análisis de alcanzabilidad » de Aikido descarta todo aquello que no tenga una ruta de ejecución hacia el código vulnerable, y «CVE análisis de explotabilidad » va más allá, analizando cómo se utiliza realmente un paquete en tu entorno para decidir si merece la pena actuar ante una vulnerabilidad accesible.
Aikido aplica las correcciones de dos formas. En el caso de problemas conocidos y solucionables mediante parches, AutoFix puede generar la corrección directamente. En el caso de los paquetes de código abierto, aplica el parche a la versión exacta ya fijada en el archivo de bloqueo del equipo, sin necesidad de actualizar ni migrar. Funciona de la misma manera con las imágenes base de contenedores vulnerables y el código de las aplicaciones. Cuando una corrección requiere una decisión humana, la vulnerabilidad sigue marcándose con una recomendación específica y práctica, de modo que alguien pueda actuar de inmediato en lugar de tener que pensar primero qué hacer. El siguiente paso, llevar todo esto hasta la fase de producción sin tener que esperar a que alguien lo incorpore, no está lejos.
Detectar vulnerabilidades nunca ha sido tan fácil. Ahora, lo importante es saber cómo distinguir las vulnerabilidades del ruido de fondo y solucionarlas rápidamente.
