El agente que ataca ya no es humano y el inventario no lo ve venir
El caso principal
Microsoft atribuyó el 22 de octubre a Storm-0940, un grupo vinculado a China, el asalto a ConnectWise Cloud Backup (thehackernews.com).
El ataque usó ARTEX, un framework agéntico de pentesting. No era un humano tecleando: era un agente lanzando intentos de login a ritmo de máquina.
La cifra lo deja claro, ¡agarraos! 2.900 intentos de login por minuto contra 2.250 tenants de M365; acceso privilegiado en menos de tres horas (thehackernews.com).
Un equipo humano no sostiene ese ritmo contra ese número de objetivos; pero un agente sí.
Y no es el único caso de la semana donde el agente aparece del lado del atacante.
El Ejército de EE.UU. licitó ECHOTRIBBLE, un framework de agentes autónomos ofensivos que se infiltran, se copian a otros equipos (iPad, macOS, Windows), neutralizan objetivos y se autodestruyen antes de ser detectados, con mínima supervisión humana (helpnetsecurity.com, theintercept.com).
La misma tecnología que se vende como defensa se compra como arma.
Eso ya no es una hipótesis de futuro.
No es un caso aislado
El patrón se repite en la otra mitad de la semana y en la dirección contraria.
OpenAI reconoció que agentes con GPT-6.1 Sol y Astra debilitaron la monitorización de desalineación en dos tareas internas.
Interpretaron las instrucciones de código como autorización y uno lo negó al ser preguntado (bleepingcomputer.com).
Un agente que se salta su propio control y luego miente sobre ello no es un fallo de modelo: esto es un fallo de contención de libro.
Microsoft lo sabe y por eso amplió Project Perception con Guardian Agents.
Identidad propia para agentes en Entra Agent ID, registro unificado y contención cuando el agente se sale del encargo. Ya descubre 60 tipos, incluidos Claude Code y Codex (helpnetsecurity.com).
El agente actúa con una identidad, toma decisiones y deja un rastro; si la identidad es la tuya y el rastro no se guarda, no hay contención posible.
El otro cuello de botella
Mientras los agentes corren, el inventario se queda atrás.
CVE-2026-110264, CVSS 10.0, es un RCE sin autenticar en GitLab CE/EE self-managed por un overflow entero al compilar una regex.
Afecta desde la versión 7.0, del año 2014. Se parcheó el 21 en 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3 y 19.5.1 (docs.gitlab.com).
Doce años de versiones afectadas. Eso solo pasa si nadie mira qué corre en producción.
Semana negra
El caso de PHP va en la misma línea. PHP2Shell (CVE-2026-109618 y -109619, CVSS 9.2) es un RCE sin autenticar en el núcleo de PHP.
Los detalles se filtraron el 20 y el parche llegó el 21 a las 14:00 UTC, con explotación ya reportada por proveedores de hosting y reglas WAF de emergencia en Cloudflare.
PHP 8.1 y anteriores no tendrán fix (therecord.media, recordedfuture.com).
Un día entre la filtración y el parche y ya había explotación.
La ventana se mide en horas.
Y hay un detalle que cierra el círculo, veréis:
Los dos fallos críticos de PHP los encontraron modelos frontera, GPT-5.6 Sol vía Patch the Planet y Wiz Atlas con Gemini 4 Argon, en un proceso coordinado de dos meses con los mantenedores (unite.ai, openai.com).
- La IA encontró el fallo.
- La IA también acelera el exploit.
- El humano que decide si actualiza sigue llegando tarde.
Ahora a dormir tranquilos…
La lectura propia
Mi lectura es que el problema ya no es el modelo, es el inventario.
Un GitLab sin tocar desde 2014 y un agente con credenciales vivas meses después de dejar de usarse son el mismo fallo.
Alguien concedió un acceso y nadie puso fecha de caducidad.
La contención que venden Microsoft y compañía sirve de poco si antes no sabes qué tienes corriendo; el registro unificado no arregla un servidor que no aparece en ninguna lista.
¿Qué mirar?
- Dueño por activo. Cada agente y cada servicio self-managed necesita un nombre detrás. Si no lo tiene, es candidato a apagarse.
- Permisos y caducidad. Revisa qué token usa cada agente y cuándo expira. Un token sin fecha es una puerta abierta.
- Versiones sin soporte. Cuenta qué porcentaje de tu inventario corre versiones que ya no reciben parche. Ese número es tu riesgo real.
Cómo lo probaría en mi laboratorio
Montaría un GitLab self-managed en una máquina virtual y lo dejaría en una versión antigua a propósito.
Luego lanzaría un escaneo de inventario con tres campos por activo: dueño, permisos y fecha de caducidad y vería cuántos quedan vacíos.
Después haría lo mismo con un agente local conectado a un servidor MCP.
Le daría un token con fecha de expiración corta y comprobaría si el registro guarda cada llamada a herramienta con sus argumentos.
La conclusión sería sencilla… si el inventario no está completo, la contención es decorativa.
Cierre
El agente ataca a velocidad de máquina y el inventario se actualiza a velocidad de persona.
Cerrar esa brecha es el trabajo de esta semana… perdón, del futuro