Durante años aprendimos a desconfiar de los archivos adjuntos.
Después de los paquetes npm.
Más tarde de las imágenes Docker.
Ahora apareció una nueva categoría de riesgo:
los repositorios que abrís con un coding agent.
Esta semana, investigadores de Wiz Research publicaron GhostApproval, una vulnerabilidad que afecta a varios de los coding agents más populares del mercado.
Entre ellos:
-
Cursor
-
Amazon Q Developer
-
Google Antigravity
-
Windsurf
-
Augment
-
Claude Code (con una evaluación distinta por parte de Anthropic)
Lo interesante no es únicamente el bug.
Es lo que revela sobre la próxima generación de problemas de seguridad para agentes.
¿Qué ocurrió?
GhostApproval no explota una vulnerabilidad del modelo.
Tampoco rompe el sandbox mediante prompt injection.
El ataque reutiliza una técnica conocida desde hace décadas en Unix:
los enlaces simbólicos (symlinks).
Un symlink parece un archivo normal.
Pero en realidad apunta a otro archivo completamente distinto.
Por ejemplo:
project_settings.json
│
▼
~/.ssh/authorized_keys
El usuario cree que el agente está modificando un archivo del proyecto.
En realidad está escribiendo sobre un archivo sensible del sistema.
¿Cómo funciona el ataque?
Imaginemos un repositorio aparentemente legítimo.
Contiene un archivo llamado:
project_settings.json
Pero ese archivo es realmente un symlink hacia:
~/.ssh/authorized_keys
El README dice algo completamente razonable:
“Ejecutá el setup del proyecto.”
o
“Pedile a tu agente que configure el workspace.”
El agente sigue las instrucciones.
Encuentra el archivo.
Solicita aprobación.
Pero el diálogo muestra únicamente:
Editar project_settings.json
No muestra el destino real del symlink.
Cuando el usuario aprueba…
…el agente escribe sobre authorized_keys, permitiendo que un atacante obtenga acceso persistente a la máquina mediante una clave SSH.
El verdadero problema
Lo más llamativo del informe de Wiz es que varios agentes detectaban internamente que el archivo era un symlink.
Pero la interfaz presentada al usuario no mostraba esa información.
En otras palabras:
el agente sabía que estaba escribiendo en un archivo sensible…
…pero el desarrollador no.
Eso convierte la aprobación humana en algo casi simbólico.
El usuario acepta una operación sin conocer realmente qué está autorizando.
¿Qué herramientas fueron afectadas?
Según Wiz, la investigación alcanzó a:
-
Amazon Q Developer
-
Cursor
-
Google Antigravity
-
Claude Code
-
Windsurf
-
Augment
La respuesta de cada proveedor fue distinta.
¿Qué se corrigió?
Cursor
Cursor clasificó el problema como una vulnerabilidad de alta severidad y publicó la corrección en la versión 3.0, asignándole el identificador CVE-2026-50549.
Amazon Q Developer
AWS solucionó el problema en el Language Server 1.69.0, registrado como CVE-2026-12958.
En la mayoría de los casos la actualización llega automáticamente al reiniciar el IDE.
Google Antigravity
Google modificó la forma en que presenta y resuelve los symlinks durante las operaciones de escritura.
Claude Code
Anthropic tomó una postura diferente.
La empresa argumentó que el usuario ya había confiado explícitamente en el directorio y aprobado la operación, por lo que el escenario quedaba fuera de su modelo de amenazas.
Sin embargo, las versiones actuales (2.1.173 o posteriores) muestran el destino real del symlink durante la aprobación, reduciendo significativamente el riesgo.
¿Qué significa esto para nosotros?
Más que un bug puntual, GhostApproval pone en evidencia un cambio importante.
Los coding agents ya no solo leen archivos.
También:
-
escriben código,
-
modifican configuraciones,
-
ejecutan comandos,
-
crean archivos,
-
administran proyectos completos.
Eso significa que errores clásicos del sistema operativo adquieren una dimensión completamente nueva cuando un agente puede actuar de forma autónoma.
Cómo protegerte
La buena noticia es que las recomendaciones son bastante sencillas.
1. Actualizá tu agente
Si utilizás:
-
Cursor
-
Amazon Q Developer
-
Google Antigravity
-
Claude Code
asegurate de estar ejecutando una versión que incluya las correcciones correspondientes.
2. No ejecutes “setup” automáticamente sobre repositorios desconocidos
Especialmente si acabás de clonar un proyecto de Internet.
Antes de pedirle al agente:
“Configurá el proyecto.”
vale la pena revisar qué archivos contiene.
3. Prestá atención a las aprobaciones
Si el agente solicita modificar un archivo aparentemente inocente…
…preguntate si ese archivo realmente debería existir.
4. Utilizá sandboxes cuando sea posible
Ejecutar agentes dentro de entornos aislados reduce muchísimo el impacto de este tipo de ataques.
5. Incorporá herramientas de gobernanza
Durante las últimas semanas vimos aparecer:
-
SkillSpector
-
CodeGate
-
MCP Gateways
Todos responden a la misma necesidad:
controlar mejor qué pueden hacer nuestros agentes.
GhostApproval demuestra por qué esa capa de seguridad empieza a ser indispensable.
Lo interesante no es GhostApproval
Lo interesante es que reutiliza un problema que existe desde hace décadas.
Los symlinks no son nuevos.
Lo nuevo es que ahora existe un agente dispuesto a seguir instrucciones automáticamente sobre ellos.
Eso cambia completamente el modelo de riesgo.
Durante años la pregunta era:
“¿Puedo confiar en este repositorio?”
Ahora también tenemos que preguntar:
“¿Puedo confiar en lo que mi agente va a hacer dentro de ese repositorio?”
Son dos preguntas distintas.
Y GhostApproval probablemente sea el primer gran recordatorio de que la seguridad de los agentes no depende únicamente del modelo.
Depende del runtime.
De la interfaz.
Y, sobre todo, de cómo se diseña la relación entre el agente y la persona que finalmente aprueba sus acciones.
Recursos
Investigación de Wiz
https://www.wiz.io/blog/ghostapproval-ai-coding-agent-vulnerability
Más información