Los asistentes de codificación con IA como Claude Code, Cursor y Grok Build pueden ejecutar comandos arbitrarios en el instante en que un desarrollador abre un repositorio no confiable, sin necesidad de ningún clic o aviso. El fallo surge de la forma en que estas herramientas invocan la función core.fsmonitor de Git para escanear los archivos de un proyecto.

Por qué este problema es importante ahora

Los desarrolladores dependen cada vez más de los agentes de IA para sugerir código, refactorizar funciones o incluso escribir módulos completos. Esos agentes necesitan una instantánea rápida del espacio de trabajo, por lo que ejecutan git status en segundo plano. Cuando Git lee el archivo .git/config de un repositorio, cualquier valor asignado a core.fsmonitor se trata como un comando de shell que Git ejecutará. Un actor malintencionado puede colocar un comando diseñado en esa entrada de configuración, y la llamada de Git en segundo plano de la IA lo activará antes de que el usuario escriba una sola línea de código.

El código se ejecuta con los propios privilegios del desarrollador, eludiendo el sandbox en el que normalmente opera el agente de IA. En la práctica, un repositorio comprometido puede instalar malware, exfiltrar credenciales o alterar archivos fuente, todo mientras el desarrollador cree que el asistente simplemente está ofreciendo sugerencias.

Cómo se desarrolla el ataque

  1. Preparación – Un atacante crea un repositorio cuyo .git/config contiene una línea como core.fsmonitor = /path/to/malicious/script.
  2. Entrega – El repositorio se entrega como un archivo zip, se copia desde una memoria USB, se sincroniza a través de una unidad compartida o se coloca de otro modo en la máquina de la víctima con la carpeta .git ya presente.
  3. Activación – El desarrollador abre la carpeta en un IDE habilitado para IA. El asistente ejecuta git status para reunir contexto. Git lee la configuración local, ejecuta el comando core.fsmonitor y el script malicioso se ejecuta inmediatamente.

Un simple git clone no expone este riesgo porque el clon crea un directorio .git nuevo que carece de la configuración manipulada. El ataque solo funciona cuando el atacante puede suministrar una carpeta .git preexistente.

Qué está en juego

  • Desarrolladores individuales pueden ver sus máquinas comprometidas sin darse cuenta, perdiendo cualquier dato al que el agente de IA pueda acceder.
  • Equipos que comparten código a través de unidades internas o archivos zip de contratistas pueden propagar la carga útil a muchas estaciones de trabajo.
  • Proveedores de herramientas corren el riesgo de sufrir daños reputacionales si los usuarios atribuyen la brecha al asistente de IA en lugar de a la interacción subyacente con Git.

Debido a que el comando malicioso hereda los derechos del usuario, puede modificar cualquier archivo que el desarrollador pueda, incluyendo claves SSH, scripts de construcción o credenciales de despliegue.

Pasos de mitigación que los desarrolladores pueden tomar hoy mismo

  • No confíe en la configuración local de Git. La configuración de un repositorio anula los valores globales cada vez que un asistente de IA consulta el proyecto.

  • Inspeccione la entrada core.fsmonitor antes de abrir una carpeta con un asistente: 

    git config --get core.fsmonitor

    Si aparece cualquier valor, trátelo como sospechoso.

  • Elimine la entrada con: 

    git config --local --unset core.fsmonitor

  • Verifique otras claves de riesgo que Git puede ejecutar: hooksPath, sshCommand, pager, editor, filter. Utilice el mismo patrón git config --get para verificar que estén vacías.

  • Prefiera clones limpios para cualquier código que pretenda alimentar a una herramienta de IA. Si debe trabajar con un zip o una carpeta transferida, elimine su directorio .git y reinicialice el repositorio, o realice las comprobaciones anteriores primero.

Dónde reside la responsabilidad

La vulnerabilidad no es un fallo en los modelos de lenguaje que impulsan Claude Code, Cursor o Grok Build; es una consecuencia de cómo esas herramientas recopilan información de archivos. Algunos proveedores han comenzado a aislar las llamadas de Git de forma más estricta, pero el comportamiento predeterminado sigue confiando en la configuración local del repositorio. Hasta que la industria adopte un estándar que elimine o ignore las entradas de configuración potencialmente peligrosas cuando un agente de IA escanea un espacio de trabajo, los desarrolladores deben seguir siendo la última línea de defensa.

Qué observar a continuación

  • Actualizaciones de herramientas que saniticen explícitamente la configuración de Git antes de invocar git status.
  • Guías impulsadas por la comunidad para un desarrollo seguro asistido por IA, que probablemente incluirán comprobaciones previas recomendadas.
  • Investigación de seguridad que pueda descubrir claves de configuración de Git adicionales capaces de ejecutar código, ampliando la lista de verificación más allá de las cinco resaltadas anteriormente.

En resumen: un asistente de IA puede ser un compañero de programación conveniente, pero ejecutará con gusto cualquier comando oculto en la configuración de Git de un repositorio. Verifique el espacio de trabajo antes de permitir que el asistente lo toque.