Amazon Q ejecutaba la config MCP de un repo y exponía las claves cloud del desarrollador
Wiz reveló (26 de junio de 2026) que Amazon Q Developer lanzaba automáticamente servidores MCP desde un archivo de config del repo, sin consentimiento: abrir un proyecto malicioso podía ejecutar código y robar credenciales cloud.
¿Qué es esto?
El 26 de junio de 2026, Wiz Research publicó un análisis de una falla de gravedad alta en Amazon Q Developer, el asistente de código con IA de Amazon. La extensión cargaba y lanzaba automáticamente servidores Model Context Protocol (MCP) definidos en un archivo dentro del proyecto abierto — .amazonq/mcp.json — en cuanto el desarrollador abría la carpeta y activaba Amazon Q. Sin aviso, sin consentimiento, sin verificación de confianza del espacio de trabajo. Como los servidores MCP son procesos locales que el asistente inicia, y esos procesos heredaban el entorno completo del desarrollador, abrir un repositorio manipulado podía ejecutar código arbitrario con la sesión cloud activa del desarrollador. La cobertura llegó a través de The Hacker News, y Amazon publicó el Boletín de seguridad 2026-047-AWS.
La falla fue reportada de forma responsable por Maor Dokhanian, de Wiz: descubierta el 17 de abril, reportada a Amazon el 20 de abril, corregida el 12 de mayo y divulgada públicamente el 26 de junio — muy por encima del plazo de divulgación coordinada, con el parche ya desplegado. AWS indica que no se conoce explotación pública.
Cómo funciona
El problema es una confusión de la frontera de confianza, no un payload ingenioso. Al abrir una carpeta de proyecto en un IDE, se confía implícitamente en decenas de archivos de configuración declarativos — describen un comportamiento, no ejecutan código. La configuración MCP rompe esa suposición: una entrada MCP nombra un comando que se debe ejecutar.
Una config MCP benigna parece corriente — un command, sus args y un bloque env que usaría una herramienta legítima de base de datos o de build. Amazon Q leía ese archivo directamente en la raíz del espacio de trabajo e iniciaba los servidores listados, antes de que el desarrollador revisara una sola línea. Dos decisiones de diseño combinadas lo volvieron peligroso:
- Ejecución automática sin consentimiento. La config se cargaba al abrir la carpeta, sin diálogo ni control de confianza: un texto controlado por el atacante en el repo se convertía automáticamente en un proceso en ejecución.
- Herencia completa del entorno. El proceso lanzado recibía el entorno completo del desarrollador — claves de acceso cloud, tokens de sesión de CLI, secretos de API, sockets del agente SSH — así que lo que se ejecutaba tenía en mano las credenciales activas del desarrollador.
Aquí no se reproduce ningún payload funcional; el mecanismo es estructural. En su prueba de concepto, Wiz simplemente hizo que el comando lanzado leyera la identidad cloud activa y enviara el resultado a un servidor externo, demostrando que un archivo en un repo clonado podía pasar de «git clone» al compromiso del cloud. El mismo parche también corrigió un segundo problema relacionado: una verificación de enlace simbólico ausente que permitía escribir archivos fuera de la frontera del espacio de trabajo — la misma clase que el RCE por aprobación de symlink en agentes de código.
Por qué importa
El runtime que impulsa Amazon Q se distribuye en VS Code, JetBrains, Eclipse y Visual Studio, por lo que todo plugin que incluyera una copia antigua quedaba expuesto. La condición previa es un hábito diario del desarrollador: clonar un proyecto desconocido — una pull request tentadora, un paquete con typosquatting o una «prueba de código» enviada en una entrevista de trabajo falsa — y abrirlo. Eso lo convierte en una vía de cadena de suministro creíble, de la misma familia que Agentjacking y la brecha de identidad y credenciales de los agentes de código, donde contenido de repo no confiable se convierte en un comando ejecutado con los derechos del propietario.
Sobre todo, no es el error de un solo proveedor. Wiz y otros documentaron la misma forma en todo el ecosistema — Claude Code, Cursor y Windsurf vieron cada uno cómo una config MCP a nivel de proyecto se transformaba en ejecución de comandos, por una vía ligeramente distinta. La configuración transportada en el repo que configura en silencio a un agente de IA es un antipatrón sistémico, no un fallo aislado.
Defensas
La corrección duradera consiste en tratar cualquier archivo que pueda estar en un repositorio como entrada no confiable, y exigir un sí explícito antes de que pueda ejecutar código.
- Actualizar primero. Amazon corrigió la falla en Language Servers for AWS 1.65.0; el boletín de AWS aconseja pasar a 1.69.0, que también incorpora la corrección del symlink. El servidor de lenguaje se actualiza automáticamente salvo bloqueo de red — recargar el IDE trae la última versión. Versiones mínimas de plugin corregidas: VS Code 2.20, JetBrains 4.3, Eclipse 2.7.4, kit de herramientas de Visual Studio 1.94.0.0.
- Someter los servidores MCP a consentimiento. Cargar un servidor MCP desde la config del espacio de trabajo siempre debería solicitar confirmación. Cuando tu asistente marque un servidor MCP no confiable, lee el comando antes de permitirlo y rechaza todo lo que no hayas añadido.
- Reducir el entorno. Los procesos hijos deberían recibir el mínimo entorno necesario, nunca el conjunto completo. Mantén las claves cloud y
~/.ssh/~/.awsfuera del alcance de todo lo que lance un agente. - Desconfiar de repos desconocidos. Comprueba si hay carpetas
.amazonq/(o config de agente equivalente) inesperadas antes de abrir un proyecto, y nunca apuntes un agente a la pull request de un fork sin supervisión. - Adoptar la confianza del espacio de trabajo. Usa la función de confianza del espacio de trabajo del IDE para que las carpetas no confiables no puedan ejecutar automáticamente el comportamiento de una extensión.
Estado
| Elemento | Referencia | Fecha | Notas |
|---|---|---|---|
| Falla de ejecución auto | CVE-2026-12957 (CVSS 8.5) | Divulgado el 2026-06-26 | Amazon Q cargaba la config MCP del espacio de trabajo sin consentimiento |
| Falla de escritura symlink | CVE-2026-12958 | Divulgado el 2026-06-26 | Verificación de symlink ausente; corregida en la misma versión |
| Corregido en | Language Servers for AWS 1.65.0 (AWS aconseja 1.69.0) | Parche desplegado el 2026-05-12 | Actualización auto salvo bloqueo de red |
| Descubridor | Maor Dokhanian, Wiz Research | 2026-04-17 → 2026-06-26 | Divulgación coordinada; sin explotación pública conocida |
| Misma clase | Claude Code, Cursor, Windsurf | 2025–2026 | Config MCP a nivel de proyecto → ejecución de comandos |
El encuadre honesto no es «una herramienta de IA tuvo un bug» — es que una config transportada en un repo que configura a un agente de IA es entrada ejecutable, y convertirla en un proceso debe exigir un sí humano explícito. Hasta que los agentes bloqueen ese paso por defecto, la defensa es tuya: parchear, exigir consentimiento para los servidores MCP, reducir el entorno y tratar cualquier repositorio desconocido como código no confiable.