sistema: OPERATIVO
← volver a todos los hacks
AGENTS CRITICAL NEW

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.

2026-07-02 // 6 min affects: amazon-q-developer, claude-code, cursor, windsurf

¿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.

  1. 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.
  2. 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.
  3. 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 / ~/.aws fuera del alcance de todo lo que lance un agente.
  4. 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.
  5. 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

ElementoReferenciaFechaNotas
Falla de ejecución autoCVE-2026-12957 (CVSS 8.5)Divulgado el 2026-06-26Amazon Q cargaba la config MCP del espacio de trabajo sin consentimiento
Falla de escritura symlinkCVE-2026-12958Divulgado el 2026-06-26Verificación de symlink ausente; corregida en la misma versión
Corregido enLanguage Servers for AWS 1.65.0 (AWS aconseja 1.69.0)Parche desplegado el 2026-05-12Actualización auto salvo bloqueo de red
DescubridorMaor Dokhanian, Wiz Research2026-04-17 → 2026-06-26Divulgación coordinada; sin explotación pública conocida
Misma claseClaude Code, Cursor, Windsurf2025–2026Config 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.

Sources