El harness de tus agentes ya tiene RCE (CVE-2026)

Hace un par de semanas conté por qué trabajar con agentes quema, y la tesis era que montas un sistema para descargar tu cabeza: reglas de validación, hooks, subagentes que revisan, un SDK que orquesta. El andamio carga con la atención que no te cabe.

El 16 de octubre salió una CVE en el andamio mismo, no en el código que escribo yo.

Es CVE-2026-96620, en el Claude Agent SDK. 9.2 sobre 10, crítica. Y no es un caso suelto. En las tres primeras semanas de octubre salieron tres ejecuciones remotas de código en las herramientas con las que corres agentes, y un paper que demuestra que el mecanismo de fondo está roto en todos los harness que probó.

Qué es el harness y por qué importa aquí

El harness es todo lo que rodea al modelo para que haga trabajo: el SDK que lanza las sesiones, los hooks que disparan comandos en ciertos eventos, el fichero de configuración que define qué servidores MCP se cargan, la pasarela que conecta tu agente con el repo.

Ese código corre con tus privilegios. Se distingue de un bug normal en una cosa: buena parte se ejecuta en momentos que el modelo no ve. Un hook que salta al arrancar la sesión, un flag que se parsea antes de que el LLM lea nada, una plantilla que se resuelve en la pasarela. No hay un modelo al que puedas pedirle que vigile, porque el daño pasa por debajo de él.

Llevas meses tratando ese andamio como infraestructura de confianza. Lo instalaste para no tener que mirar. Es exactamente el sitio donde un fallo pasa callado.

Las tres CVE de octubre

CVE	Dónde	Qué permite	CVSS	Parche
CVE-2026-96620	Claude Agent SDK (Python)	Inyección de flag → servidor MCP → RCE al arrancar	9.2	0.2.121
CVE-2026-90970	GitLab AI Gateway (Duo)	Escape del sandbox de la plantilla → RCE	9.9	19.2.4 / 19.3.2 / 19.4.1
CVE-2026-103572	VS Tools for Apps / SSMS	Inyección de código por red	8.8	Boletín de octubre

La del SDK es la que mejor enseña el patrón. La opción resume se pasaba al CLI de Claude como un token aparte, sin validar. Si el valor empieza por guion, el CLI lo lee como un flag independiente. Un atacante que controle ese valor inyecta --mcp-config, define un servidor MCP de tipo stdio y consigue ejecución de comandos al arrancar el CLI, fuera de los controles de permisos del propio SDK. Arreglado en 0.2.121.

Léelo otra vez: los permisos del SDK son justo la capa en la que confías para que el agente no haga lo que no debe. El fallo entra por debajo de esa capa.

La de GitLab es peor en número, 9.9. Un usuario autenticado con acceso a la Duo Agent Platform se escapaba del sandbox de la plantilla de prompt con una configuración de flow manipulada y acababa en ejecución arbitraria de comandos. Afecta a todas las versiones del AI Gateway desde la 18.1.6 hasta los parches de las ramas 19.2, 19.3 y 19.4.

La tercera, en Visual Studio Tools for Applications y SQL Server Management Studio, es inyección de código por red con interacción del usuario. La ficha de NVD se queda ahí; la cobertura de Adversa la conecta con un bypass de la comprobación de edición de configuración de Copilot y demuestra la ejecución vía prompt injection indirecta. Esa parte es del análisis de Adversa, no de la ficha oficial, y la cito como tal.

Lo que el paper demuestra sobre los hooks

Las CVE son casos concretos que se parchean. El paper 2609.03884, de Li et al. (3 de septiembre de 2026), ataca el mecanismo.

Los harness modernos dejan enganchar comandos de shell a eventos del ciclo de vida: arranque de sesión, llamada a herramienta, edición de fichero. Esos comandos corren con los privilegios del host y viajan en ficheros de configuración de hooks. El trabajo señala que el camino por el que se actualizan esos hooks se confía sin verificar.

El modelo de amenaza es de cadena de suministro: el atacante solo controla los metadatos de un plugin y su configuración de hooks. Un plugin benigno y versionado se vuelve malicioso con una actualización que engancha comandos suyos a eventos corrientes. El usuario no aprueba nada nuevo; actualiza una dependencia que ya tenía.

Montaron HookPry, un framework de ataque automático, y lo tiraron en 1.000 ejecuciones sobre 25 combinaciones de harness y backend. Comprometió los 7 harness que probó, con tasas de éxito de hasta el 92,5 %. Y lo que más pesa para quien cree que ya tiene esto cubierto: Microsoft Defender detectó cero de los artefactos maliciosos, y combinar tres defensas estáticas seguía dejando pasar el 47,5 %.

No hablo de un riesgo teórico. Siete de siete.

Por qué esto enlaza con lo de la fatiga

Hace unas semanas conté que PHP y Node se parchearon el mismo día, y que esas dos las encontró un programa de IA rastreando código abierto. La rueda de CVE críticas va a girar más rápido según mejoren los modelos que las buscan.

Esto es la misma rueda, apuntando a otro sitio. Antes eran los runtime que corres. Ahora son las herramientas con las que corres los agentes: SDKs jóvenes, pasarelas nuevas, formatos de hooks que nadie ha auditado con calma. Código reciente, poco mirado, con privilegios de host. Justo lo que un modelo entrenado para buscar fallos encuentra a escala.

Y choca de frente con la tesis del artículo de la fatiga: montas el harness para no tener que prestar atención. Pues el harness acaba de pedirte atención, de la cara. El andamio en el que descargaste tu cabeza es ahora una superficie de ataque con tres RCE en tres semanas.

Qué hacer: el harness es código de producción

El error de base es tratar las herramientas de agentes como algo personal y no como lo que son: software con privilegios en tu máquina y en tu repo. Lo que hago desde octubre:

1. Fija las versiones del harness como fijas las del runtime. SDK, CLI, pasarela, plugins. Si corres el Claude Agent SDK por debajo de 0.2.121 o el GitLab AI Gateway por debajo de los parches de octubre, ya vas tarde. php -v miente y pip show también si solo miras una máquina: haz inventario de contenedores, CI y entornos de cada dev.

2. La configuración de hooks y de MCP es código, y se revisa como código. Entra en control de versiones, pasa por PR y se mira en el diff. Una actualización de un plugin que cambia los hooks es un cambio de código que ejecuta comandos con tus permisos. Nadie debería poder tocar eso sin que aparezca en una revisión.

3. Menos privilegios por defecto. El agente corre con lo mínimo. Servidores MCP, solo los que necesitas y desde fuentes que controlas. Las CVE del SDK y de GitLab son las dos escapes de una capa de permisos: cuanto menos haya al otro lado de esa capa, menos daño cuando se rompa. Porque se va a romper.

4. El agente no puede modificar lo que lo controla. La regla es de Rafael Casuso y aquí es literal: si el agente puede reescribir sus propios hooks, su CI o su configuración de permisos, no tienes una barrera, tienes una sugerencia. Ese fichero va fuera de su alcance.

5. Vigila los avisos de seguridad de las herramientas como vigilas los del runtime. Suscríbete a los del SDK, de la pasarela y de los plugins que uses. Aquí es donde van a aparecer los próximos.

Ninguna de estas cinco cosas es exótica. Son las mismas prácticas que aplicas a cualquier dependencia con privilegios. El problema es que al harness no lo tratabas como una dependencia con privilegios. Lo tratabas como tu mesa de trabajo.

Lo que queda

Cuando salió la CVE del SDK yo ya corría una versión parcheada, y no por listo: por tener las herramientas fijadas y un pipeline que las sube, igual que el runtime. El día que trasladé al andamio las reglas que ya aplicaba a producción fue el día que dejó de ser un punto ciego.

La pregunta para tu equipo no es si parcheas PHP. Es si sabes qué versión del SDK, de la pasarela y de los plugins corre cada agente que tenéis en marcha, y quién puede cambiar sus hooks sin que lo veas.

P.D. Si esta semana has tenido que actualizar las herramientas de agentes con prisa, cuéntamelo por X (@lm_martinbar). Quiero saber por dónde os ha entrado. Y si llevas la seguridad de un equipo que ya trabaja así, me interesa el doble.