Los asistentes de código con IA pueden ser secuestrados mediante una entrada maliciosa en .git/config que explota la función core.fsmonitor de Git, lo que permite que un repositorio no confiable ejecute comandos en la máquina de un desarrollador en el instante en que el asistente escanea los archivos.

La vulnerabilidad surgió en varios agentes populares: Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build y Hermes. En los agentes que ya han sido parcheados, el exploit ya no funciona; los demás siguen siendo vulnerables. No se requieren clics ni avisos adicionales, y el código malicioso se ejecuta con los propios privilegios del usuario, fuera de cualquier sandbox que el agente de IA pueda proporcionar.

Cómo llega el ataque a un desarrollador

  • Un contratista comprime un proyecto en un archivo zip y lo envía por correo electrónico.
  • Un compañero de equipo comparte una carpeta en una unidad de red.
  • Se entrega un pendrive con una base de código.

En cada caso, el repositorio llega como un directorio que ya contiene una carpeta .git. Cuando un asistente de IA abre la carpeta, normalmente ejecuta git status en segundo plano para construir una vista del código. Git acelera esa operación con el ajuste core.fsmonitor, que le indica a Git que llame a un programa externo para vigilar los cambios en el sistema de archivos. Si el archivo .git/config del repositorio define un comando malicioso para core.fsmonitor, Git lo ejecuta automáticamente, sin consultar al usuario.

Debido a que el comando es lanzado por el propio Git, este hereda los permisos del usuario y evade cualquier sandbox que la herramienta de IA haya configurado. El exploit no se activa durante un git clone, git fetch o git pull normal; solo se activa cuando el repositorio se descomprime con su metadato .git ya presente.

Por qué es importante este problema

Los desarrolladores dependen cada vez más de los asistentes de IA para sugerir completados, refactorizar código o generar módulos enteros. Esas herramientas necesitan una instantánea rápida del árbol de archivos del proyecto, por lo que invocan comandos de Git de forma silenciosa. Si un repositorio malicioso puede ejecutar código en ese momento, un atacante obtiene un punto de acceso en la estación de trabajo del desarrollador sin ninguna advertencia visible. La carga útil potencial varía desde el robo de credenciales hasta la instalación de puertas traseras persistentes, todo mientras el usuario cree que simplemente está "revisando" el código con un asistente de IA.

Cómo detectar un repositorio envenenado

Antes de entregar un repositorio a un asistente, ejecute:

git config --get core.fsmonitor

Una salida que no esté vacía significa que hay un programa configurado para ejecutarse automáticamente. Para un escaneo más amplio, enumere cualquier configuración de Git sospechosa:

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Si detecta entradas que usted no añadió, elimínelas con:

git config --local --unset core.fsmonitor

Tenga en cuenta que configurar git config --global core.fsmonitor false no le protege. La configuración local del repositorio siempre tiene prioridad sobre la global, por lo que un repositorio malicioso puede simplemente ignorar una regla global.

Estado actual de los parches

  • Claude Code – parcheado (fsmonitor)
  • Cursor – parcheado
  • OpenAI Codex – parcheado
  • Goose – parcheado
  • Qwen Code – sin parchear
  • Grok Build – sin parchear
  • Hermes – sin parchear

Los desarrolladores que utilicen los agentes sin parchear deben tratar cualquier repositorio entrante como potencialmente peligroso hasta que cambien de herramienta o apliquen políticas de Git locales más estrictas.

Contrapunto de la comunidad de Git

El core.fsmonitor de Git es una función de rendimiento legítima, no un error. Los mantenedores argumentan que la responsabilidad recae en quienes invocan los comandos de Git para validar el contenido del repositorio antes de hacerlo. Desactivar la función de forma global es una mitigación sencilla, pero como se ha señalado, las anulaciones locales pueden subvertir esa protección. El debate más amplio se centra ahora en si los asistentes de IA deberían ejecutar en un sandbox todas las invocaciones externas de Git o negarse a procesar repositorios que contengan hooks de fsmonitor personalizados.

Qué vigilar a continuación

  • Actualizaciones de los agentes de IA sin parchear, especialmente cualquier declaración sobre el uso de sandboxing en las llamadas a Git.
  • Posibles cambios en el manejo predeterminado de Git para core.fsmonitor en directorios no confiables.
  • Herramientas de terceros que puedan sanitizar el archivo .git/config de un repositorio antes de que llegue a un asistente.

Conclusión

Una sola línea en un archivo de configuración oculto puede convertir una comodidad impulsada por IA en un vector de ejecución remota de código. Hasta que se solucionen los agentes vulnerables, la práctica más segura es auditar cada repositorio que llegue fuera de un flujo de trabajo de clonación estándar y eliminar cualquier hook de core.fsmonitor o similar antes de permitir que un asistente de IA toque el código.