GhostApproval: IA de código escapa del sandbox

Un archivo llamado project_settings.json que en realidad apunta a tu ~/.ssh/authorized_keys. Un asistente de IA que "sabe" que el archivo es sospechoso, lo dice en su razonamiento interno, y aun así te pregunta si querés editarlo como si fuera inofensivo. Eso es GhostApproval: un patrón de vulnerabilidad que los investigadores de Wiz divulgaron el 8 de julio de 2026 y que afecta a seis de los asistentes de código con IA más usados. No es un bug exótico de un solo producto: es el mismo error de diseño repetido en toda la industria, montado sobre una función de Unix que tiene décadas.

GhostApproval es una técnica de bypass de sandbox que abusa de los enlaces simbólicos (symlinks) para que un asistente de IA de código escriba en archivos fuera de su carpeta de trabajo. Según la investigación de Wiz (julio de 2026), afecta a Amazon Q Developer, Anthropic Claude Code, Augment, Cursor, Google Antigravity y Windsurf. Un repositorio malicioso incluye un symlink disfrazado de archivo de config; cuando el agente lo edita, escribe en el destino real —por ejemplo, tus claves SSH— fuera del workspace.

¿Cómo un repositorio malicioso escribe en tu ~/.ssh/authorized_keys?

GhostApproval: la IA de código escapa del sandbox por un symlink

El ataque encadena un symlink con una instrucción disfrazada de tarea rutinaria. El atacante publica un repo que parece normal, pero adentro un archivo con nombre inocente —project_settings.json, .env.example— no es un archivo real: es un enlace simbólico que apunta a un archivo sensible de tu sistema, fuera del proyecto. El README pide "configurar el workspace". Vos clonás y le decís al agente que lo haga.

A partir de ahí, la cadena es mecánica:

El agente sigue el symlink sin resolverlo del todo. Cuando escribe en el archivo "del proyecto", en realidad escribe en el destino real: ~/.ssh/authorized_keys, ~/.zshrc, ~/.bashrc u otro archivo de arranque.
El payload es una clave pública SSH del atacante. Al agregarse a authorized_keys, le da acceso SSH persistente y sin contraseña a tu máquina. Si ese archivo de arranque se ejecuta, es ejecución de código directa.
Vos creíste que autorizabas una edición trivial. El diálogo de confirmación mostró la ruta inocente, no el destino real del symlink. Aprobaste "editar un JSON", no "darle SSH a un desconocido".

Wiz clasificó el problema con dos debilidades combinadas: CWE-61 (seguir symlinks) y CWE-451 (tergiversación de información crítica en la interfaz). La segunda es la que convierte un bug técnico en una trampa: el "human in the loop" existe, pero le muestra al humano la información equivocada.

¿Qué asistentes de IA están afectados y cuáles ya tienen parche?

Son seis los afectados, y el estado de parche es dispar: tres corregidos, uno discutido y dos todavía sin fix al momento de la divulgación. Cursor recibió la calificación más alta: CVE-2026-50549 con CVSS 9.8 (crítico), corregido en Cursor v3.0. Amazon Q Developer obtuvo CVE-2026-12958 (severidad alta). Este es el cuadro según los reportes de Wiz y The Hacker News:

Herramienta	Estado	Identificador / versión
Amazon Q Developer	Corregido	CVE-2026-12958 · Language Server 1.69.0
Cursor	Corregido	CVE-2026-50549 (CVSS 9.8) · v3.0
Google Antigravity	Corregido	v1.19.6 · CVE pendiente
Anthropic Claude Code	Discutido / mitigado	Versiones 2.1.x en adelante avisan ante symlinks
Augment	Sin parche al divulgarse	Reconocido como crítico
Windsurf	Sin parche al divulgarse	Reconocido como crítico

Un matiz importante: no todos fallaron igual. Según Wiz, Windsurf y Amazon Q escribían en disco antes de mostrar el diálogo de confirmación, con lo cual la aprobación no autorizaba nada: solo servía como un "deshacer" tardío. Y Augment leía archivos sensibles a través del symlink sin consentimiento, exponiendo credenciales dentro del propio chat. Es decir, en algunos casos el daño ya estaba hecho cuando el usuario veía la pregunta.

¿Por qué el "human in the loop" no salvó a nadie?

Porque el asistente detectaba el peligro y aun así no se lo mostraba al humano. Esa es la parte más incómoda de GhostApproval: no es que la IA no entendiera. En la demostración de Wiz con Claude Code, el razonamiento interno del agente decía textualmente "puedo ver que project_settings.json es en realidad un archivo de configuración de zsh", mientras que el diálogo que veía el usuario solo preguntaba: "¿Hacer esta edición a project_settings.json?". El modelo sabía. La interfaz mintió por omisión.

Ese es el corazón del CWE-451: la aprobación del usuario se vuelve inútil si lo que se aprueba no es lo que se muestra. El pedido de permiso, que debería ser la última red de seguridad, se transforma en teatro. Como resumió The Register, es un recordatorio de que los dolores de cabeza de seguridad de la era Unix —los symlinks existen desde hace décadas— nunca mueren del todo; solo cambian de contexto.

Anthropic, por su parte, inicialmente respondió que el escenario caía fuera de su modelo de amenaza: "Cuando el usuario inicia Claude Code en un directorio, debe confirmar que confía en ese directorio antes de arrancar la sesión", argumentó la empresa. Más tarde igual sumó resolución de symlinks y advertencias explícitas en las versiones recientes de la herramienta.

¿Qué significa esto para tu cloud server?

El riesgo real no está tanto en el servidor como en la máquina de desarrollo que tiene la llave del servidor. Si usás un asistente de IA de código en tu laptop o en un entorno de desarrollo, y esa máquina guarda las claves SSH con las que entrás a tu Cloud Server, un solo authorized_keys envenenado en tu equipo puede terminar dándole a un tercero un pie adentro de tu infraestructura. La superficie de ataque se corrió: ya no alcanza con endurecer el servidor si el agente que corre en tu escritorio puede reescribir tus credenciales.

Los vectores concretos a tener en cuenta:

Repos de terceros que clonás y "dejás configurar" al agente. Dependencias, plantillas, proyectos de ejemplo, código de un cliente: cualquier repo que no auditaste es un vector.
Agentes corriendo en CI o en un servidor de build. Si un pipeline invoca un asistente de código sobre código no confiable, el symlink puede apuntar a secretos o a claves de deploy dentro del runner.
Archivos de arranque de shell. Escribir en ~/.zshrc o ~/.bashrc es tan grave como tocar las claves SSH: se ejecutan en la próxima sesión.

¿Qué podés hacer HOY para protegerte?

Actualizá las herramientas que tengan parche y tratá a los agentes de IA como código no confiable. Estas son las medidas concretas que recomienda Wiz, más lo que aplica a un entorno de servidor:

Actualizá ya lo que ya está parcheado. Cursor a v3.0, Amazon Q a Language Server 1.69.0, Google Antigravity a v1.19.6 y Claude Code a la última versión. Si usás Augment o Windsurf, extremá el resto de las precauciones porque al momento de la divulgación no tenían fix.
Revisá el README y los archivos de config ocultos antes de dejar que el agente configure un repo. Buscá symlinks sospechosos con find . -type l -ls antes de darle permiso de escritura a la IA.
Corré el agente con acceso limitado o dentro de un contenedor. Un sandbox real (Docker, un usuario sin privilegios, un devcontainer) evita que un write fuera del workspace toque tu $HOME real.
Auditá después. Chequeá timestamps de los archivos críticos: ls -la ~/.zshrc ~/.bashrc ~/.ssh/authorized_keys. Si alguno cambió sin que vos lo tocaras, revisalo línea por línea.
Aplicá el mismo hardening de siempre en el servidor. Deshabilitar login por password, restringir authorized_keys, Fail2Ban y UFW siguen siendo tu red de contención si una clave se filtra.

Si querés profundizar en ese último punto, en este blog ya cubrimos el hardening inicial de un Cloud Server Ubuntu (SSH, UFW y Fail2Ban) y cómo proteger SSH y Nginx con CrowdSec, dos lecturas que se complementan bien con lo de hoy.

Preguntas frecuentes

¿Qué es exactamente GhostApproval?

Es un patrón de vulnerabilidad divulgado por Wiz el 8 de julio de 2026 que permite que un repositorio malicioso, usando un symlink, haga que un asistente de IA de código escriba en archivos fuera de su sandbox. Combina el seguimiento de symlinks (CWE-61) con una interfaz que oculta el destino real de la escritura (CWE-451).

¿Claude Code sigue siendo vulnerable?

Anthropic discutió que fuera un bug dentro de su modelo de amenaza, pero las versiones recientes de Claude Code (2.1.x en adelante) resuelven los symlinks y advierten antes de escribir en archivos sensibles. Actualizar a la última versión es la recomendación.

¿Cuál fue el caso más grave?

Cursor, con CVE-2026-50549 y un CVSS de 9.8 (crítico), ya corregido en la v3.0. En paralelo, Wiz señaló que Windsurf y Amazon Q escribían en disco antes de pedir confirmación, lo que hacía inútil la aprobación del usuario.

¿Cómo detecto si me afectó?

Revisá los timestamps de tus archivos sensibles con ls -la ~/.ssh/authorized_keys ~/.zshrc ~/.bashrc y abrí authorized_keys para verificar que no haya claves públicas que no reconozcas. Si encontrás una, quitala y rotá tus claves SSH.

¿Alcanza con actualizar el asistente?

Ayuda, pero no reemplaza la higiene básica: seguí auditando repos de terceros antes de dejar que un agente los configure y, para código no confiable, corré la IA dentro de un contenedor o con acceso a disco restringido. El parche cierra el vector conocido; el principio de tratar al agente como no confiable te cubre ante los próximos.

Fuentes: Wiz — GhostApproval: A Trust Boundary Gap in AI Coding Assistants, The Hacker News, The Register y SC Media.