El equipo de Microsoft Defender Security Research divulgó el 18 de junio de 2026 una cadena de explotación bautizada AutoJack que convierte a un agente de IA con capacidad de navegar la web en un vehículo para ejecución remota de código (RCE) sobre la máquina que lo hospeda. En criollo: una página web maliciosa, con solo ser visitada por el agente, puede alcanzar un servicio local privilegiado y lanzar un proceso en tu host —sin credenciales, sin pantalla de login y sin que el usuario haga un solo clic más después de que el agente carga la página. El blanco concreto fue AutoGen Studio, la interfaz open source de Microsoft Research para armar aplicaciones multiagente.
Cómo funciona la cadena: del prompt injection al calc.exe
El flujo es más simple de lo que asusta. Un desarrollador corre AutoGen Studio en el puerto 8081 por defecto. Su agente de browsing (por ejemplo MultimodalWebSurfer) navega a una página controlada por el atacante. El JavaScript de esa página abre un WebSocket a ws://localhost:8081/api/mcp/ws/?server_params=<payload>. AutoGen Studio decodifica ese payload base64 —algo como {"command": "calc.exe", "args": []}— y spawnea el proceso bajo la cuenta del desarrollador. El gancho inicial es un indirect prompt injection: la página le mete instrucciones al agente para que la abra y dispare el resto.
Tres agujeros que solos no rompen nada, juntos sí
AutoJack encadena tres debilidades en el WebSocket de MCP (Model Context Protocol). Primero, el socket confiaba en localhost —pero un agente headless corriendo en la misma máquina es localhost, así que hereda esa identidad y pasa el control de origen (CWE-1385). Segundo, el middleware de autenticación se salteaba explícitamente las rutas /api/mcp/* con un comentario que decía que «harían sus propios chequeos»… que nunca se implementaron, así que el socket aceptaba conexiones sin token sea cual sea el modo de auth configurado (CWE-306). Tercero, el endpoint tomaba el comando directo de un parámetro de la request y lo ejecutaba, sin allowlist: calc.exe, powershell.exe -enc … o bash -c '…' entraban todos (CWE-78).
Quién está expuesto (y quién puede quedarse tranquilo)
La buena noticia para la mayoría: la superficie vulnerable vivió solo en builds de desarrollo de la rama main de GitHub y nunca llegó a una release de PyPI. Quien instaló AutoGen Studio desde el paquete publicado (la versión actual es 0.4.2.2) no está expuesto a esta cadena puntual. Microsoft aclara que esto es investigación, no una campaña activa: no hubo explotación in the wild. No se asignó CVE; el problema se identificó y corrigió durante el desarrollo, reportado vía MSRC, antes de cualquier release pública.
Qué recomienda Microsoft: localhost ya no es frontera de confianza
La frase que resume todo el reporte: «cuando un agente en tu servidor o tu laptop puede navegar la web abierta y comunicarse con servicios locales privilegiados, localhost deja de ser una frontera de confianza». Los mantenedores ya endurecieron AutoGen Studio: sacaron el server_params de la URL y lo movieron a un POST con binding del lado del servidor por UUID, y quitaron /api/mcp de la lista de excepciones de auth para que esas rutas exijan autenticación como cualquier otra.
Para quien construye agentes —que es buena parte de nuestra comunidad ahora mismo— las recomendaciones aplican mucho más allá de AutoGen: tratá todo parámetro de tool que pueda venir de la salida del modelo como controlado por el atacante; nunca bindees un control plane sensible a localhost sin autenticación; usá allowlists de qué ejecutables puede invocar un MCP server en lugar de aceptar comando y args de quien llame; y separá la identidad de browsing del agente de la del desarrollador —otro usuario de SO, un contenedor o una VM. Es decir, sandboxing de verdad, no localhost a pelo.
Lo que más me llama la atención de AutoJack es que ningún agujero por separado es novedad: origin trust, auth saltada, comando sin validar son clásicos. Lo nuevo es el agente como puente que une la web hostil con tu loopback privilegiado. Para los que estamos metiendo agentes en producción en la región, el mensaje es claro: el agente no es un cliente confiable, es una superficie de ataque más. ¿Estás aislando tus agentes de browsing del resto del host, o todavía los corrés en la misma máquina que tus servicios locales? Te leemos en los comentarios.


