En 2025, el umbral de entrada en ataques informáticos complejos se desplomó: adolescentes sin habilidades técnicas, mediante sistemas basados en grandes modelos de lenguaje, llevaron a cabo intrusiones que afectaron a millones de registros y campañas de extorsión por varios millones, y el tiempo medio desde la publicación de una vulnerabilidad hasta la aparición de un exploit operativo se redujo de más de 700 días en 2020 a 44 días en 2025; en este contexto, la estrategia tradicional de «aplicar el parche antes que los atacantes» dejó de funcionar, y las organizaciones que utilizan código abierto y repositorios públicos de paquetes deben pasar a eliminar de forma estructural clases enteras de vulnerabilidades y a ejercer un estricto control de la cadena de suministro de software.
Detalles técnicos y métricas clave de 2025–2026
Ejemplos de ataques con uso de IA
Agresores sin perfil técnico en 2025 comenzaron a llevar a cabo operaciones que antes exigían el trabajo coordinado de un equipo experimentado:
- En diciembre de 2025, un adolescente de 17 años en Osaka fue detenido en virtud de la ley japonesa sobre acceso no autorizado por ejecutar código malicioso que permitió exfiltrar datos personales de más de 7 millones de usuarios de la red de cibercafés Kaikatsu Club; el motivo: comprar cartas de Pokémon.
- En febrero de 2025, tres adolescentes (de 14, 15 y 16 años) sin experiencia en programación crearon con ayuda de ChatGPT una herramienta que atacó aproximadamente 220 000 veces los sistemas de Rakuten Mobile; los fondos obtenidos se gastaron en videoconsolas y juegos de azar en línea.
- En julio de 2025, un único atacante, utilizando la plataforma de programación basada en agentes Claude Code, llevó a cabo una campaña de extorsión contra 17 organizaciones en un mes: la IA desarrollaba el código malicioso, sistematizaba los archivos robados, analizaba los estados financieros para calibrar las exigencias y generaba los textos de los correos de chantaje.
- En diciembre de 2025, otro actor en solitario, con ayuda de Claude Code y ChatGPT, vulneró más de 10 organismos del gobierno de México y robó más de 195 millones de registros de contribuyentes.
Todos estos casos demuestran que el papel de la IA ya no es auxiliar, sino transversal: abarca desde el desarrollo de exploits hasta la automatización del análisis financiero y las comunicaciones.
Evolución de los ataques contra el código abierto y los repositorios de paquetes
Uno de los indicadores más reveladores fue el aumento de paquetes maliciosos en los repositorios públicos:
- en 2022 se registraban alrededor de 55 000 paquetes maliciosos;
- para 2025 la cifra aumentó hasta 454 600, con incrementos notorios en 2023 (lanzamiento de GPT‑4) y 2025 (difusión masiva de herramientas de programación basadas en agentes de IA).
En septiembre de 2025, el ataque Shai-Hulud contra el ecosistema de npm comprometió más de 500 paquetes. Se filtraron secretos de 487 organizaciones, y de la criptocartera Trust Wallet se robaron 8,5 millones de dólares después de que los atacantes, aprovechando credenciales comprometidas, sustituyeran su extensión para Chrome.
Es característico que los paquetes maliciosos se camuflaran como bibliotecas populares (por ejemplo, chalk, debug), incluyeran documentación, pruebas unitarias y código similar a módulos de telemetría. Los analizadores estáticos clásicos y los escáneres basados en firmas los dejaban pasar, ya que su estructura parecía la de un software «normal». Esto coincide con la tendencia general de describir los patrones de comportamiento de los ataques a nivel de tácticas y técnicas, por ejemplo, en la matriz MITRE ATT&CK, y no mediante firmas estáticas.
Reducción del tiempo hasta la explotación de vulnerabilidades
Otro indicador clave es el time to exploit, el tiempo desde la divulgación de una vulnerabilidad hasta la aparición de un exploit «en la naturaleza»:
- en 2020 superaba los 700 días;
- en 2025 se redujo a 44 días.
El informe M-Trends 2026 de Mandiant muestra un panorama aún más preocupante: la ventana se ha vuelto de hecho negativa, ya que los exploits aparecen cada vez con más frecuencia antes que los parches, y el 28,3% de las entradas CVE se explotan en las 24 horas posteriores a su divulgación. En este contexto, catálogos de vulnerabilidades como NVD se convierten para los delincuentes en una lista de tareas que pueden automatizar rápidamente con ayuda de la IA.
Desbalance entre la velocidad de ataque y la velocidad de defensa
Los datos de Edgescan para 2025 muestran que el tiempo medio de corrección de vulnerabilidades conocidas de alta y crítica gravedad es de 74 días, y que el 45% de las vulnerabilidades en la infraestructura de grandes empresas (a partir de 1000 empleados) no llega a corregirse. Frente a esto, el tiempo medio de desarrollo de un exploit (44 días) y la proporción de ataques en el primer día tras la divulgación crean una ventaja sostenida a favor de los atacantes.
Aumento de las capacidades de la IA para el desarrollo de código
A medida que los modelos de vanguardia (ChatGPT, Claude, Gemini) mejoraban sus resultados en benchmarks de desarrollo de software (por ejemplo, SWE-bench), su contribución a las operaciones ofensivas se volvió notablemente mayor:
- en agosto de 2024, los modelos de referencia resolvían automáticamente alrededor del 33% de las tareas reales de GitHub en SWE-bench;
- para diciembre de 2025, el indicador alcanzó casi el 81%.
Esto significa que gran parte del desarrollo rutinario y de complejidad media de exploits y utilidades está ahora disponible para los atacantes como servicio y no como una competencia propia.
Un intento de respuesta estructural: Chainguard Libraries
En medio del crecimiento explosivo de los ataques a la cadena de suministro surge un enfoque orientado no a acelerar la respuesta, sino a eliminar clases enteras de riesgos. Un ejemplo es Chainguard Libraries, donde cada biblioteca abierta se recompila a partir de código fuente verificado y atribuido. El objetivo arquitectónico es hacer imposibles:
- el compromiso de procesos de CI/CD mediante la sustitución de dependencias;
- ataques de tipo dependency confusion;
- el robo y abuso de tokens de larga duración durante la fase de build;
- ataques contra la infraestructura de distribución de paquetes.
En pruebas con 8 783 paquetes maliciosos para npm, Chainguard Libraries bloqueó el 99,7% de ellos; para aproximadamente 3 000 paquetes maliciosos de Python, alrededor del 98%. Esto ilustra hasta qué punto resultan más eficaces las medidas integradas en la propia arquitectura de la cadena de suministro frente a la simple adición de nuevas capas de detección.
Contexto de amenazas: quién sufre más y de qué manera
Por los ejemplos expuestos se aprecia que los ataques afectan a:
- el sector público: desde el sistema de seguridad japonés hasta los organismos gubernamentales de México, donde la filtración de 195 millones de registros fiscales crea riesgos a largo plazo de fraude y de manipulación política;
- operadores de telecomunicaciones e infraestructuras críticas: el incidente con Rakuten Mobile demuestra que incluso adolescentes pueden iniciar cargas de trabajo a gran escala u operaciones fraudulentas contra plataformas de telecomunicaciones;
- servicios financieros y criptoplataformas, como en el caso de Trust Wallet y el robo de 8,5 millones de dólares mediante el envenenamiento de la extensión del navegador;
- cualquier empresa que dependa de npm, PyPI y otros repositorios de código abierto, donde cientos de miles de paquetes maliciosos elevan el nivel básico de riesgo incluso para dependencias triviales.
El denominador común es una dependencia masiva de código y servicios externos, sobre la cual el modelo tradicional de «actualizar el antivirus y aplicar parches con regularidad» ya no ofrece un riesgo residual aceptable. Esto lo confirman también análisis de organizaciones como CISA, que desplazan de forma sistemática el foco hacia principios arquitectónicos «secure by design».
Evaluación del impacto en el negocio y las operaciones
- Riesgos operativos: las congelaciones forzadas del código tras ataques a repositorios (como después de Shai-Hulud) provocan retrasos en los lanzamientos, incumplimiento de hojas de ruta y aumento de la deuda técnica.
- Pérdidas financieras: robos directos (millones de dólares en el caso de Trust Wallet), pagos de rescate, interrupciones del servicio y posteriores inversiones en la mejora acelerada de la seguridad.
- Riesgos de confidencialidad y sanciones regulatorias: la filtración de 7 millones de registros de clientes de Kaikatsu Club y de 195 millones de registros de contribuyentes en México plantea no solo cuestiones de multas, sino también de la imposibilidad de «revocar» los datos ya filtrados.
- Reputación y confianza: el conocimiento por parte de los usuarios de que ahora «cualquiera con un asistente de IA» puede cometer ciberdelitos incrementa la sensibilidad ante las noticias de incidentes y reduce la tolerancia a las interrupciones.
El nuevo problema cualitativo es la ampliación del solapamiento entre quienes están dispuestos a realizar ataques y quienes son capaces de llevarlos a cabo. Antes era una capa muy reducida; ahora, gracias a la IA, crece rápidamente, y la escala de los ataques depende cada vez menos del tamaño y la madurez del grupo delictivo.
Recomendaciones prácticas para reducir el riesgo
1. Asumir como base que el exploit aparecerá antes de que pueda aplicarse el parche
- Planificar los procesos de gestión de vulnerabilidades partiendo del escenario de que la explotación es posible en las primeras 24 horas tras la divulgación (o incluso antes), aunque el parche aún no haya salido.
- Establecer un flujo separado para el tratamiento de vulnerabilidades críticas con SLO más agresivos (entre horas y pocos días), incluyendo medidas compensatorias temporales (desactivación de funciones, limitación de servicios expuestos, filtrado de tráfico).
2. Controlar estrictamente la cadena de suministro de software
- Crear un repositorio interno de dependencias (espejo de npm, PyPI, etc.) con aprobación y publicación solo de versiones verificadas de las bibliotecas.
- Incluir la obligación de que los paquetes pasen por un proceso de revisión (análisis estático, revisión manual, cotejo con fuentes legítimas conocidas) antes de entrar en el repositorio de producción.
- Considerar soluciones que recompilen las bibliotecas abiertas a partir de código fuente atribuido y proporcionen garantías de inmutabilidad de las builds, de forma análoga a Chainguard Libraries, para que clases enteras de ataques (dependency confusion, compromiso de CI/CD, sustitución de binarios) sean técnicamente imposibles.
3. Reforzar la detección de ataques a nivel de comportamiento y no solo de código
- No confiar en escáneres basados en firmas para detectar paquetes maliciosos: el código generado por IA se disfraza fácilmente de «normal», con documentación y pruebas.
- Implantar monitorización del comportamiento de las dependencias: solicitudes de red durante la instalación, intentos de acceso a archivos confidenciales, ejecución de procesos externos desde install-scripts.
- Utilizar entornos aislados (sandbox) para probar nuevos paquetes antes de usarlos en CI/CD y en producción.
4. Gestión del acceso a herramientas de desarrollo con IA
- Formalizar la política de uso de sistemas como ChatGPT y Claude Code: prohibición de cargar fragmentos de código sensibles y secretos, requisitos de registro de las sesiones.
- Formar a desarrolladores y analistas sobre los riesgos no solo de filtración, sino también de uso indebido de la IA, desde la generación inconsciente de código vulnerable hasta la ayuda para sortear controles internos.
5. Preparación para incidentes en la cadena de suministro
- Definir de antemano un procedimiento para «congelar» rápidamente las dependencias y revertir a versiones anteriores cuando se detecte la compromisión de un paquete.
- Llevar un inventario de las bibliotecas utilizadas y su origen (en esencia, un registro interno similar a una «lista de materiales» de software), para poder determinar rápidamente quién se ve afectado ante un nuevo ataque a npm u otro registro.
La conclusión clave es que, en un entorno en el que la explotación de vulnerabilidades se acelera más deprisa de lo que se acortan los ciclos de lanzamiento de parches, confiar únicamente en la velocidad de respuesta está condenado al fracaso; la primera prioridad debe ser crear un repositorio interno controlado de dependencias y trasladar a él todos los procesos de build y despliegue, para bloquear al máximo las clases de ataques contra la cadena de suministro antes de que lleguen a su perímetro.
