GitSpawn: fallo que permite ejecutar comandos desde .git/config en herramientas de IA

Un equipo de investigación independiente, Manifold Security, ha publicado un informe que describe una clase de vulnerabilidad presente en varias herramientas de asistencia de programación basadas en inteligencia artificial: si un repositorio recibido incluye su directorio .git con una configuración maliciosa, la propia configuración puede indicar un comando que la herramienta ejecuta en el equipo del desarrollador fuera de la caja de seguridad y sin pedir confirmación. Manifold llamó al conjunto de hallazgos "GitSpawn" y documentó ocho rutas de explotación en siete agentes de línea de comandos; en el momento de su última verificación varias rutas seguían sin parchear. Al mismo tiempo, OpenAI publicó CVE(s) que describen un problema de la misma naturaleza en su producto Codex.

Técnicamente, la raíz es la interacción entre cómo Git almacena ciertas opciones en el archivo .git/config de un repositorio y cómo los agentes automatizados invocan operaciones de Git en segundo plano. Un ajuste en Git llamado core.fsmonitor puede contener un comando que Git ejecuta para acelerar la detección de archivos cambiados; Git lee ese valor desde el propio .git/config del repositorio. Cuando un agente necesita saber la rama actual o qué archivos han cambiado ejecuta operaciones como git status o git diff: esos comandos disparan la ejecución del binario configurado en core.fsmonitor. Si ese valor apunta a un ejecutable controlado por un atacante, el comando corre con los mismos privilegios del usuario y fuera del entorno restringido del agente.

El requisito operativo para la explotación es que el receptor obtenga el árbol de trabajo junto con su carpeta .git intacta —por ejemplo mediante un archivo comprimido compartido, una unidad de red sincronizada, una carpeta de sincronización o una memoria USB—; según los reportes, en esas situaciones la configuración maliciosa se conserva. Manifold indica que un "clone" estándar no preserva exactamente la misma condición en todos los casos señalados por el investigador, y por tanto no siempre expone al usuario, pero los escenarios de entrega mencionados sí lo hacen.

Qué productos y versiones están afectadas (confirmado por Manifold y/o por advisories públicos): goose (todas las versiones anteriores a 1.44.0, corregido en 1.44.0); Codex CLI y Codex Desktop (rango de versiones afectadas y correcciones publicadas hasta 0.131.0 / números de build concretos para macOS/Windows); Claude Code (ruta core.fsmonitor mitigada en 2.1.196, pero otra ruta llamada "claude ultrareview" se confirmó activa en 2.1.252); Cursor CLI (documentado por Manifold con ejecución previa al diálogo de confianza); Hermes Agent, Qwen Code y Grok Build también fueron confirmados por Manifold como ejecutando comandos suministrados por el repositorio en fechas recientes y estaban pendientes de parche en la última re-verificación. OpenAI publicó al menos un CVE (CVE-2026-19592) que describe el mismo patrón en Codex; GitHub asignó CVE-2026-72718 a la falla en goose con una calificación CVSS reportada.

Los efectos prácticos son claros y severos: la ejecución de comandos con los privilegios del usuario permite a un atacante leer, modificar o borrar archivos locales, robar credenciales, exfiltrar secretos (tokens, claves SSH) y en general tomar pasos no autorizados en el entorno local. Manifold documentó casos en los que la ejecución ocurre incluso antes de que el usuario vea o acepte el diálogo de "workspace trust", o incluso antes de que el usuario se autentique en el agente —condiciones que empeoran el riesgo porque eliminan fases de mitigación humana.

Hechos confirmados: Manifold ha publicado detalles técnicos y pruebas de concepto de varias rutas; algunos proveedores ya enviaron parches para rutas concretas (por ejemplo goose, partes de Claude Code y Cursor); OpenAI publicó CVE(s) aplicables a Codex. No hay registros públicos verificados de explotación en la naturaleza relacionados con estos hallazgos hasta la fecha de las verificaciones públicas citadas, y la lista de vulnerabilidades conocidas explotadas por CISA no incluía estos CVE en su última revisión consultada.

Estimaciones y elementos aún inciertos: Manifold señala que el patrón aparece en más agentes de los que ha nombrado; eso sugiere que el alcance real podría ser mayor, pero no se dispone de una enumeración pública completa. Hay imprecisión sobre qué versiones posteriores (en particular de Claude Code para la segunda ruta) ya solucionaron todas las rutas: Manifold confirmó la segunda ruta todavía activa en la 2.1.252, y no hubo confirmación pública universal de cierre en releases posteriores al momento del reporte. Asimismo, en algún caso los proveedores cerraron reportes como duplicados de investigaciones paralelas, lo que complica trazar una línea temporal única y pública de mitigaciones.

Por qué esto ocurre ahora: no es un fallo del modelo de IA, sino del "plumbing" —las llamadas al sistema que los agentes lanzan al iniciar una sesión para detectar contexto del repositorio—. Modernas herramientas automáticas llaman a Git en segundo plano para identificar rama y cambios; Git, por diseño, permite ejecutar hooks o procesos colaboradores configurables. Esa flexibilidad de Git, combinada con la automatización, convierte una característica legítima en un vector de ejecución remota local.

Qué debe hacer un desarrollador o equipo ahora mismo (acciones concretas y verificables): inspeccionar cualquier directorio recibido antes de abrirlo con un agente de IA; comprobar la configuración de fsmonitor y valores sospechosos; desactivar fsmonitor por defecto si no es necesario; y actualizar las herramientas afectadas a las versiones parcheadas. Comandos útiles (ejecutar en un entorno seguro): abrir y revisar .git/config en cualquier directorio recibido; ejecutar git config --get core.fsmonitor dentro del repo para ver un valor activo; auditar la configuración global con git config --global --list | grep fsmonitor; y, si procede, desactivar por defecto con git config --global core.fsmonitor false. Los vendedores mitigan en algunos casos invocando Git en background con un flag que anula la variable peligrosa, p. ej. git -c core.fsmonitor=false status, una práctica recomendada hasta que se confirmen parches.

Recomendaciones operativas adicionales: no abrir carpetas recibidas de origen no confiable en un IDE o agente con acceso irrestricto sin antes inspeccionarlas; usar entornos aislados (máquinas virtuales o contenedores) al explorar repositorios de terceros; mantener actualizadas las herramientas cliente (verificar y aplicar las versiones que los proveedores hayan publicado como parche); y, para equipos, auditar flujos de intercambio de código (compresión, sincronización de carpetas, uso de discos externos) para prevenir que .git maliciosos se propaguen accidentalmente.

Recursos de referencia y contexto técnico: la documentación oficial de la configuración de Git sobre opciones como core.fsmonitor explica el propósito y formato de esa clave —véase https://git-scm.com/docs/git-config—. Para situar este patrón en antecedentes, vulnerabilidades anteriores relacionadas con el bypass del diálogo de confianza en editores y entornos han sido catalogadas (por ejemplo, CVE-2021-43891), cuyo registro puede consultarse en https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-43891. CISA mantiene un catálogo de vulnerabilidades explotadas conocidas que conviene revisar periódicamente para ver si emergen explotaciones activas: https://www.cisa.gov/known-exploited-vulnerabilities-catalog.

Conclusión: la vulnerabilidad descrita por Manifold no requiere modelos manipulados ni fallos en la IA; explota la combinación de la flexibilidad de Git y la automatización de agentes. Aunque varios proveedores ya corrigieron rutas concretas, persisten vectores abiertos en herramientas claves y la exposición real depende de cómo reciban los desarrolladores repositorios (p. ej. archivos compartidos o unidades externas). Hasta que las herramientas queden todas parcheadas y la práctica de invocar Git en segundo plano sea consistemente segura, la defensa más efectiva es la inspección previa, la desactivación preventiva de core.fsmonitor y el uso de entornos aislados para analizar código desconocido.