24 de octubre de 2026 # El 3,2% de todas las de vulnerabilidades de software se han publicado en solo 22 días  **El 3,2% del catálogo histórico de vulnerabilidades se ha publicado en solo 22 días.** Cifras alocadas en la era de la IA. [Alberto Pinedo](https://www.linkedin.com/in/msapinedo/) ha compartido el gráfico original (más abajo) en un chat de Teams de la oficina. La captura es del 22 de octubre de 2026. Os lo explico y reflexionamos un poco. ## Qué es un CVE  Un programa puede tener un fallo que permita acceder a datos sin permiso, ejecutar instrucciones ajenas o impedir que funcione. Eso es una vulnerabilidad de seguridad. Su existencia no significa que se haya producido un ataque. **CVE es el sistema que permite identificar públicamente esas vulnerabilidades.** Las siglas vienen de *Common Vulnerabilities and Exposures*. A cada vulnerabilidad registrada se le asigna un identificador y una descripción con referencias. Así, el fabricante del software, los investigadores y las empresas pueden referirse al mismo problema. [El programa CVE explica su funcionamiento](https://www.cve.org/). En el lenguaje habitual llamamos "un CVE" a ese registro. Por eso, cuando decimos que se han publicado 12.688 CVEs, hablamos de registros de vulnerabilidades. Con esa cifra no puedes saber cuántos ataques se han producido ni cuántas empresas están afectadas, pero sí te haces una idea de "los problemas de seguridad potenciales" del software. Las fechas también tienen su importancia. Un fallo puede llevar años en un programa y publicarse hoy. Encontrarlo, reservar su identificador, publicar el registro y corregirlo son hechos distintos. El año del identificador tampoco indica necesariamente cuándo apareció el defecto. [La FAQ oficial detalla estas diferencias](https://www.cve.org/Resources/Media/Archives/OldWebsite/about/faqs.html). Y hay otra precisión que después nos va a servir: un registro puede agrupar varios fallos, y una actualización puede corregir varios CVE. **Contar registros, fallos y actualizaciones da resultados diferentes.** ## Cómo leer las cifras de octubre   La captura corresponde a [CVE Tracker](https://cve.0xosprey.com/) y está actualizada al **22 de octubre de 2026**. El panel utiliza el registro público del programa CVE. Está seleccionada la fecha de publicación y la vista mensual: cada punto indica cuántos registros se han publicado ese mes. Las cifras de abajo dicen esto: | Cifra de la captura | Qué significa | | --- | --- | | 394.368 | Registros acumulados incluidos en el panel hasta esa fecha. | | 12.688 | Registros publicados durante octubre hasta la actualización del día 22. | | Aproximadamente 17.350 | Proyección de registros para octubre completo. | | Aproximadamente 103.854 | Proyección para todo 2026. | La cuenta que llama la atención es sencilla: **12.688 dividido entre 394.368, multiplicado por 100, da un 3,2%.** Ese porcentaje del catálogo acumulado se ha publicado en menos de un mes. No es un 3,5%, ni significa que en octubre haya ocurrido el 3,2% de todos los ciberataques. Las dos últimas cifras son estimaciones. El panel calcula la proyección mensual comparando el ritmo actual con la parte del mes que normalmente se ha publicado en ese momento, según los doce meses anteriores. Octubre aún puede terminar por encima o por debajo. La proyección anual se calcula aparte: no sale de multiplicar 17.350 por doce. Si octubre cerrase con esos 17.350 registros, habría que sumar al total los 4.662 que faltan para alcanzar la proyección. El catálogo llegaría a 399.030, y octubre representaría alrededor del 4,35%. Ese porcentaje depende de que se cumpla la estimación; el 3,2% anterior sí describe lo que aparece ya contado en la captura. La curva muestra un aumento tremendo de publicaciones. Pero ese dato, por sí solo, no permite calcular cuánto ha aumentado el riesgo. ## Por qué se están publicando tantos  La IA ayuda a encontrar vulnerabilidades que antes costaba muchísimo localizar. Tenemos casos concretos, confirmados por quienes mantienen el software. El 21 de abril, Mozilla anunció que Firefox 150 corregía **271 vulnerabilidades** encontradas en su evaluación inicial de Claude Mythos Preview. Pero 271 vulnerabilidades no significa 271 CVE. En esa versión, Mozilla agrupó en tres CVE un total de 316 fallos detectados por sus propios equipos, con varias técnicas. La forma de registrar los defectos también afecta al recuento. [Mozilla: anuncio de abril](https://blog.mozilla.org/en/firefox/ai-security-zero-day-vulnerabilities/) y [explicación de mayo](https://hacks.mozilla.org/2026/05/behind-the-scenes-hardening-firefox/). También estamos registrando problemas que ya se conocían. FIRST (asociación internacional de equipos de respuesta a incidentes) explicó en junio que el aumento combinaba búsquedas con IA, más publicaciones desde GitHub y el registro por VulnCheck de vulnerabilidades acumuladas sin identificador. > [!info]- Qué es FIRST > FIRST reúne a equipos que responden a incidentes de seguridad y desarrolla recursos que utilizan para decidir sus prioridades. Publica previsiones de CVE y mantiene EPSS, que estima la probabilidad de que se utilice un fallo en un ataque. Su análisis permite distinguir el volumen de registros del trabajo que requiere atención urgente. FIRST elevó entonces su previsión anual a unos 66.000 CVE. Esa previsión de junio y los casi 104.000 que proyecta el panel en octubre tienen fechas y métodos diferentes. Son previsiones, y no dos recuentos definitivos entre los que haya que elegir. [Comunicado de FIRST del 15 de junio](https://www.first.org/newsroom/releases/20260615). La IA permite encontrar más fallos y se están registrando vulnerabilidades que ya se conocían. Los dos cambios aumentan el total de registros. No tenemos un desglose que permita atribuir a la IA un porcentaje concreto de todo el aumento. ## Encontrar un fallo no termina el trabajo  Hay un testimonio bastante reciente que me parece revelador. El 22 de octubre, Daniel Stenberg, creador de curl, explicó que los informes inventados con IA prácticamente habían desaparecido de su proyecto desde primavera. Su problema actual es recibir muchos informes de buena calidad. Aun así, los modelos siguen confundiendo un fallo normal con una vulnerabilidad y equivocándose al valorar su gravedad. [Stenberg cuenta su experiencia en curl](https://daniel.haxx.se/blog/2026/10/22/ignore-the-slop/). Es la experiencia de ese proyecto, y no una medida de toda la industria. Pero cambia bastante la discusión: un informe verdadero también requiere trabajo. Hay que reproducir el fallo, comprobar a qué versiones afecta, corregirlo y probar que el cambio funciona. Después hay que publicar la actualización e instalarla donde corresponde. La IA también puede ayudar en esos pasos; su capacidad para encontrarlos no garantiza que el resto se haga igual de rápido. Google ofrece un ejemplo. Chrome 149 y 150 corrigieron **1.072 fallos de seguridad**, más que las 23 versiones anteriores juntas. Entre los hallazgos de su agente había un fallo presente desde hacía más de trece años que permitía evitar una restricción de seguridad y leer archivos locales. Son fallos corregidos, no necesariamente 1.072 registros CVE. [El equipo de Chrome describe el proceso](https://blog.google/security/chrome-stronger-with-every-update/). Para los usuarios, la protección depende también de aplicar la actualización. Google explica que, cuando una corrección ya es pública, un atacante puede estudiarla antes de que llegue a los equipos. En Chrome, esperar al reinicio puede retrasar su aplicación. Por eso creo que sería un error convertir el total mundial de CVE en una previsión automática del trabajo de cada empresa. Primero tiene que usar el producto afectado. Después hay que saber si ese fallo permite atacar sus sistemas y con qué consecuencias. FIRST explicó en su análisis de junio que, al seleccionar fallos que ya se habían utilizado en ataques o con una probabilidad estimada de uso en ataques superior al 10%, **no observaba un aumento importante del trabajo prioritario de aplicar correcciones**. Ese resultado corresponde a junio; no permite asegurar que octubre siga igual. Sí impide dar por hecho que todos los nuevos registros requieren la misma urgencia. ## Cómo afecta a una empresa  La IA también está ayudando a los atacantes. Para hablar de eso necesitamos pruebas distintas de esta gráfica. El 21 de octubre, Microsoft publicó una investigación sobre Storm-0940 y su uso de ARTEX, un sistema de agentes para automatizar tareas de pruebas de seguridad. En varias intrusiones observó acceso privilegiado a infraestructura cloud en menos de tres horas desde la elección del objetivo. La mayoría de los intentos no tuvo éxito. [Investigación de Microsoft](https://www.microsoft.com/en-us/security/blog/2026/10/21/storm-0940-uses-artex-agentic-ai-connectwise-supply-chain-compromise/). En parte de la actividad, los atacantes utilizaron credenciales y permisos de aplicaciones comprometidas. No hacía falta descubrir un CVE nuevo. Y Microsoft distingue entre autenticarse, acceder a datos y extraerlos: comprobar lo primero no demuestra lo demás. Este caso me preocupa por la velocidad, pero también por las autorizaciones. Una empresa puede tener sus programas actualizados y haber concedido a una aplicación acceso excesivo. Si además empieza a dar autonomía a agentes de IA, tiene que decidir qué pueden hacer, con qué identidad y cuándo deben parar. Creo que el cambio obliga a revisar cómo trabajamos. Podemos dedicar menos tiempo a buscar determinados fallos y necesitar más capacidad para comprobarlos, decidir su prioridad e instalar las correcciones. O automatizar también esas tareas y reducir el tiempo de exposición. Las dos cosas son posibles; comprar un modelo mejor no decide por sí solo cuál ocurre. En una empresa, pediría conocer cuánto tiempo pasa entre saber que una vulnerabilidad afecta a un sistema importante y comprobar que está corregida. Y preguntaría qué personas y agentes tienen permiso para actuar durante ese tiempo, y qué pueden hacer. Es bastante más concreto que preguntar cuántos CVE nuevos hay. No sé si dentro de dos años publicaremos más registros o menos. Me parece una buena noticia que encontremos fallos antiguos y podamos corregirlos. Pero la métrica para la empresa es *cuánto tardamos en estar protegidos*. ## Bonus  > [!tip]+ Otros recursos sobre ciberseguridad > - [Buscar un CVE o un producto en la base de datos NVD](https://nvd.nist.gov/vuln/search#/nvd/home?resultType=records) · NIST - Para consultar qué versiones aparecen afectadas y revisar los avisos y las correcciones del fabricante. > - [Catálogo de vulnerabilidades utilizadas en ataques](https://github.com/cisagov/kev-data) · CISA, repositorio oficial de KEV - Para comprobar si un fallo ya se ha utilizado en ataques y consultar las medidas recomendadas; que no aparezca no garantiza seguridad. > - [Cómo utilizar EPSS para priorizar correcciones](https://www.first.org/epss/using-epss.html) · FIRST - Explica cómo combinar la probabilidad de ataques con los sistemas que utilizáis, su exposición y las posibles consecuencias. > - [SSVC: decidir qué correcciones son urgentes](https://certcc.github.io/SSVC/howto/deployer_tree/) · CERT/Carnegie Mellon - Un procedimiento para decidir cuándo corregir un fallo según los ataques conocidos, la exposición del sistema y sus consecuencias. > - [Cómo organizar las actualizaciones de seguridad](https://www.ncsc.gov.uk/collection/vulnerability-management/guidance/policy-update-by-default) · NCSC británico, revisado en mayo de 2026 - Cómo instalar actualizaciones por fases, comprobar que funcionan y volver a la versión anterior si dan problemas. > - [Cómo controlar los riesgos de los agentes de IA](https://www.ncsc.gov.uk/blogs/managing-the-cyber-risk-of-agentic-ai) · NCSC británico, agosto de 2026 - Recomendaciones provisionales para decidir cuánta autonomía dar a un agente, qué permisos necesita y cómo detenerlo. > - [Controles de seguridad para construir agentes de IA](https://cheatsheetseries.owasp.org/cheatsheets/AI_Agent_Security_Cheat_Sheet.html) · OWASP - Para quienes construyen agentes: controles concretos para limitar herramientas, permisos, memoria y acciones que requieren aprobación. > - [El estudio sobre cómo priorizar vulnerabilidades con EPSS](https://arxiv.org/abs/2302.14172) · Jacobs y colaboradores, 2023 - Explica por qué la gravedad técnica no predice por sí sola qué fallos se utilizarán en ataques. --- Publicado el 24 de octubre de 2026, [LinkedIn](https://www.linkedin.com/pulse/el-32-de-todas-las-vulnerabilidades-software-se-han-en-hurtado-tor%25C3%25A1n-vxqie), [Substack](https://davidhurtado.substack.com/p/el-32-de-todas-las-de-vulnerabilidades?r=4uyjfg&utm_campaign=post&utm_medium=web&showWelcomeOnShare=true), [X](https://x.com/dhtoran/status/2113895447618310194?s=20)