Por qué hay tantas vulnerabilidades: lo que dicen los datos
El 21 de octubre de 2026 se abrió en Hacker News el hilo del LiteLLM 1.107.0 comprometido en PyPI. El primer comentario no hablaba de LiteLLM. Era una lista: "So in just 1 week:".
Una caída de Google Cloud, la clave privada filtrada de una autoridad de certificación, una fuga de 10,6 TB, CVEs críticos en PHP encontrados con IA. Y, para cerrar, la segunda vez que LiteLLM caía en el mismo año.
Ocho minutos después, otro usuario lo resumía: "This… isn't acceptable. Once is forgivable, twice is malpractice."
Esa sensación la tienes tú también. ¿Por qué hay tantas vulnerabilidades ahora, o solo estamos mirando de otra manera?
En corto: se publican más vulnerabilidades que nunca (48.185 CVEs en 2025 y un +49,5 % en el primer semestre de 2026), pero no porque el software haya empeorado de golpe. Encontrar, explotar y publicar fallos se ha abaratado a la vez, sobre todo por la IA y por organismos que asignan CVEs en masa. Y la cadena de suministro y los agentes de IA han ampliado lo que un solo fallo puede tocar.
¿Qué es un CVE y por qué contarlos engaña?
Un CVE es un identificador público que se asigna a una vulnerabilidad concreta de un software concreto: cuenta fallos registrados, no ataques ni fallos explotados.
Esa diferencia lo explica casi todo. El número de registros depende de cuánta gente busca, cuánta asigna identificadores y cuánto software nuevo hay. No solo de lo mal que programamos.
Las cifras del aumento de vulnerabilidades son reales. Según la revisión de 2025 de Jerry Gamblin, en 2025 se publicaron 48.185 CVEs, un 20,6 % más que los 39.962 de 2024. En su revisión de mitad de 2026, el primer semestre cerró con 35.364, un 49,5 % más que un año antes. Uno cada 7,4 minutos.
El sistema no da abasto. El NIST anunció que desde el 15 de abril de 2026 deja de enriquecer todos los CVEs de la NVD y prioriza los del catálogo KEV de CISA y el software crítico, porque las solicitudes crecieron un 263 % entre 2020 y 2025.
Por qué hay tantas vulnerabilidades: seis causas con datos
Son seis causas que se suman: más organismos asignando CVEs, una IA que encuentra fallos reales, una IA que también genera informes basura, gusanos en la cadena de suministro, agentes con permisos en tu máquina y atacantes que explotan antes del parche. Solo algunas significan más riesgo para ti.
| Causa | Evidencia (fuente) | Qué cambia para ti | Límite de la evidencia |
|---|---|---|---|
| Más organismos asignando CVEs | GitHub Security Advisories, +449 % interanual; VulnCheck, +3.119 % (FIRST, jun. 2026) | Más alertas en tu escáner | Cuenta registros, incluido trabajo atrasado |
| La IA encuentra fallos reales | Mozilla, +164 % de avisos en el T1 de 2026 (FIRST); Project Glasswing, "miles" de fallos graves | Parches más frecuentes en dependencias maduras | Las cifras las publica quien vende el modelo |
| La IA también genera ruido | curl: menos del 5 % de informes reales en 2025, frente a más del 15 % antes (Stenberg) | Mantenedores saturados que tardan más | Un solo proyecto |
| Supply chain con gusanos | Shai-Hulud, más de 500 paquetes npm (CISA, sep. 2025); LiteLLM, dos veces en 2026 | Un install puede robarte credenciales |
Incidentes contados, no una tasa |
| Agentes con permisos en tu máquina | El malware de Nx usó Claude, Gemini y Q para buscar secretos (Wiz); OpenClaw, 537 CVEs en un semestre, 500 de VulnCheck (Gamblin) | Tu agente es superficie de ataque | Fenómeno reciente, pocos datos |
| Atacantes más rápidos | Tiempo medio hasta el exploit: −7 días estimados (M-Trends 2026) | Parchear "el lunes" llega tarde | Mandiant no lo atribuye a la IA |
Más gente asigna CVEs
Parte del salto son fallos viejos que ahora se registran. FIRST atribuye el crecimiento de GitHub a un equipo de curación más grande y a una campaña para asignar CVE a avisos antiguos.
La IA encuentra fallos que llevaban años ahí
Esto sí es nuevo. Anthropic lanzó Project Glasswing el 7 de abril de 2026 con un modelo no público, Mythos Preview, que encontró un fallo de 27 años en OpenBSD y otro de 16 en FFmpeg. Mozilla publicó Firefox 150 con 271 fallos encontrados con Mythos, frente a los 22 de Opus 4.6 en Firefox 148.
Los bugs ya estaban. Lo que cambió es el coste de encontrarlos. Lo conté en el post sobre la IA de Anthropic que escanea open source.
La otra cara son los informes basura. Daniel Stenberg cerró el bug bounty de curl en enero de 2026 con este dato en su blog: "Not even one in twenty was real." No infla el número de CVEs, pero satura a los mantenedores, y un mantenedor saturado parchea más tarde lo que sí es real.
La cadena de suministro multiplica el alcance
Este es el cambio que más te afecta. En septiembre de 2025, CISA alertó de que el gusano Shai-Hulud había comprometido más de 500 paquetes npm. Robaba tokens de GitHub y claves de nube, y se propagaba solo publicando versiones infectadas en nombre del developer.
LiteLLM cayó en marzo de 2026 con las versiones 1.82.7 y 1.82.8 (hilo en HN) y en octubre con la 1.107.0, que estuvo en PyPI unas dos horas.
El origen, según su análisis: una clave de administración subida por error a un repo público el 27 de mayo que nadie revocó.
Un fallo ya no se queda en el paquete: viaja con tus credenciales. Qué actualizar lo tienes en los parches de seguridad de octubre de 2026.
Los agentes de IA abren una superficie nueva
En agosto de 2025, las versiones comprometidas de Nx incluían un script que, según Wiz, lanzaba las CLIs de Claude, Gemini y Q instaladas en la máquina con flags como --dangerously-skip-permissions y --yolo para buscar secretos. Tu agente, usado contra ti.
Y los agentes también acumulan CVEs: OpenClaw, un agente local que según Gamblin "barely existed a year ago", sumó 537 en el primer semestre de 2026, 500 de ellos asignados por VulnCheck. Por eso insisto en que el portátil del developer es producción.
Los atacantes llegan antes que el parche
M-Trends 2026 de Mandiant estima el tiempo medio hasta el exploit en −7 días: de media, la explotación empieza antes de que exista el parche. Los exploits siguen siendo la primera vía de entrada, con el 32 % de las intrusiones.
¿Es por la IA? Esos datos no lo dicen. Lo que sí está documentado es que Anthropic detectó en 2025 una campaña en la que la IA ejecutó entre el 80 y el 90 % del trabajo contra unos treinta objetivos.
Tantas vulnerabilidades: ¿más riesgo o más ruido?
Las dos cosas. De los 35.364 CVEs del primer semestre de 2026, solo 85 (un 0,24 %) estaban en el catálogo KEV de fallos explotados, según Gamblin. FIRST lo dice sin rodeos: la carga de parcheo accionable "remains completely flat".
Mi opinión: el volumen de CVEs es ruido para tu día a día. Lo que ha cambiado es el alcance de cada fallo, y ahí tienes que mover el esfuerzo.
Lo que los datos no dicen
No sabemos cuánto código vulnerable mete la IA en producción. Veracode midió en 2025 que el 45 % de las muestras generadas por más de 100 modelos introducía vulnerabilidades del OWASP Top 10. Es un test de laboratorio, y nada lo une con el aumento de CVEs. Por eso no lo cuento como causa.
No se puede separar del todo "más fallos" de "más búsqueda". FIRST reconoce que aún está aprendiendo a distinguir el efecto de la IA del crecimiento del software.
Las cifras de IA vienen de partes interesadas. Glasswing es de Anthropic. Y aunque Mozilla habla de 271 fallos corregidos en Firefox 150, su aviso MFSA 2026-30 lista 41 CVEs, solo 3 acreditados a Anthropic, y no ha publicado el desglose del resto.
Las cifras de 2026 son provisionales. Los recuentos de octubre no coinciden entre trackers; por eso uso el corte de junio.
Qué hacer como developer esta semana
- Retrasa las versiones nuevas. En el hilo de LiteLLM, el mismo usuario del "twice is malpractice" proponía "a cooldown for 24 – 48 hours by default". Ya existe: pnpm lo aplica con
minimumReleaseAge(en minutos; las versiones actuales traen 1440, un día, por defecto) y en uv lo activas tú conexclude-newer. Según pnpm, la mayoría de versiones maliciosas se retiran del registro en menos de una hora. El coste: también retrasa los parches legítimos, así que para un fix urgente tendrás que exceptuar ese paquete conminimumReleaseAgeExclude. El resto, en cómo auditar dependencias en npm y pip. - Prioriza por KEV, no por CVSS. Parchea primero lo que se está explotando. Su límite: el KEV solo recoge lo que ya se sabe explotado, así que no dejes un crítico expuesto a internet esperando a que entre en el catálogo. El flujo con un agente, en cómo parchear vulnerabilidades con IA.
- Saca los secretos del alcance del agente. Lo explico en API keys y agentes de IA y en inyección indirecta de prompts.
- Revisa el código generado antes de mergear. Un primer filtro es la revisión de seguridad de Claude Code; el método completo lo trabajamos en el workshop SDD + Agentic Engineering.
La configuración del paso 1, en pnpm y en uv:
# pnpm-workspace.yaml: 24 h en minutos. Es el default en pnpm actual; fíjalo si usas una versión anterior o quieres más margen
minimumReleaseAge: 1440
# pyproject.toml: uv ignora lo publicado en la última semana
[tool.uv]
exclude-newer = "1 week"
Conclusión: por qué hay tantas vulnerabilidades y qué controlas tú
Nada en los datos dice que programes peor que hace dos años. Encontrar fallos se ha vuelto barato, publicarlos también, y el exploit llega antes que el parche. Lo único que controlas es cuánto puede tocar un fallo cuando llegue: tus dependencias, tus tokens, tu agente.
Si estás montando agentes y quieres diseñar esos límites desde el principio, el ebook gratuito El Developer Agéntico tiene un capítulo sobre su seguridad. Y si quieres llevarlo a un producto real, en Construye con IA lo hacemos con Claude Code de principio a fin.
Preguntas frecuentes
¿Cuántas vulnerabilidades (CVEs) se publicaron en 2025 y 2026?
48.185 CVEs en 2025, un récord según Jerry Gamblin. En el primer semestre de 2026 ya iban 35.364, un 49,5 % más que un año antes.
¿La IA está creando más vulnerabilidades o encontrándolas?
Con los datos públicos, sobre todo encontrándolas. Glasswing y el trabajo de Mozilla sacan fallos que llevaban años en el código. Hay estudios de laboratorio sobre fallos en código generado por IA, pero nada que los vincule con el aumento de CVEs.
¿Más CVEs significa que estoy más expuesto?
No directamente. Solo el 0,24 % de los CVEs del primer semestre de 2026 estaba en el catálogo KEV. Tu exposición depende más de tus dependencias, tus credenciales y los permisos de tus herramientas que del total de CVEs.
¿Por qué hay tantos ataques a paquetes de npm y PyPI?
Porque comprometer un paquete popular da acceso a miles de máquinas a la vez. Retrasar la instalación de versiones nuevas reduce mucho ese riesgo.
¿Qué es el tiempo hasta el exploit?
Es el tiempo medio que tarda una vulnerabilidad en explotarse. Mandiant lo estima en −7 días en M-Trends 2026: la explotación suele empezar antes de que salga el parche, así que la ventana de mantenimiento mensual ya no sirve para fallos críticos.
Por Bezael Pérez — Developer senior con más de 15 años de experiencia y fundador de Dominicode.
¿Te resultó útil este artículo?
Compártelo con tu comunidad y ayuda a otros desarrolladores.
