Un viernes por la tarde, un compañero comprime un proyecto en un zip y te escribe: «échale un ojo a este bug». Lo descomprimes, arrastras la carpeta a Hermes y empiezas a teclear tu primera instrucción — pero en esos pocos segundos, código que no es tuyo ya ha terminado de ejecutarse en tu máquina, con tus permisos. Sin ventanas emergentes, sin prompt de aprobación, nada en pantalla. No es el guion de una película: es una clase de vulnerabilidad real que la firma de seguridad Manifold Security reveló el 1 de septiembre bajo el nombre GitSpawn, y afecta a casi todas las herramientas de codificación con IA del mercado — Claude Code, Codex, Cursor, Goose, Qwen Code, Grok Build y Hermes Agent. La buena noticia: Hermes fusionó su arreglo el 2 de septiembre (PR #101483, actualmente en main).

Cómo funciona: el repo que has abierto «ejecuta» un comando por ti

Las herramientas de codificación con IA — Hermes incluido — ejecutan un par de comandos git al arrancar para saber dónde están: en qué branch estás, qué archivos han cambiado. Esta recopilación de contexto ocurre automáticamente, antes de cualquier prompt, antes de cualquier llamada a una herramienta, antes de cualquier confirmación de confianza del workspace. El agente tiene que saber dónde está antes de poder hacer nada.

El problema vive en una función de rendimiento de git: core.fsmonitor. En repos grandes, git no quiere escanear archivo por archivo para decidir qué ha cambiado, así que te permite configurar un programa auxiliar que responda a esa pregunta por él. Git ejecuta ese programa en cada index refresh — y comandos como git status y git diff disparan un index refresh.

El truco: git lee esta configuración del .git/config del propio repo. Así que un repo hostil puede incluir esto:

[core]
    fsmonitor = /tmp/pwn.sh

Y solo tienes que abrir el repo — sin decir una palabra — para que el git status que Hermes ejecuta automáticamente haga que git ejecute /tmp/pwn.sh. Como tú, con tus privilegios, fuera del sandbox, sin ninguna UI de aprobación. Un atacante obtiene mucho más que «poder ejecutar código»: tus claves SSH, tus credenciales en la nube, tus tokens de shell y un punto de apoyo en toda la máquina.

core.fsmonitor es solo un punto de ejecución más de esta clase. El informe de Manifold también cubre core.hooksPath (hooks al hacer checkout), los ajustes de pager/editor/credential y los más escurridizos diff drivers acotados por .gitattributes ([diff "x"] command= / textconv=, que se ejecutan cuando se renderiza un diff). Los últimos son los más perversos: el atacante elige el nombre del driver, así que ninguna sobrescritura mediante variables de entorno puede enumerarlos — solo los flags de línea de comandos pueden neutralizarlos.

Cómo se propaga: por qué git clone es seguro y los zip no

Esta vulnerabilidad tiene una propiedad contraintuitiva: clonar un repo hostil por red es seguro. El clone/fetch/pull de git nunca transfiere .git/config — es un archivo privado de tu repo local, y la versión del remoto no te afecta en absoluto.

Lo peligroso es un repo que llega como archivos de directorio: con su carpeta .git intacta. Un zip compartido, una carpeta en la nube sincronizada, un USB, un directorio de proyecto que un compañero copió directamente — todos conservan el .git/config de quien lo envió. Las pruebas de concepto de Manifold usaban un zip.

Así que la regla general es sencilla: desconfía de las «carpetas de proyecto empaquetadas» que otra persona te entregue antes de abrirlas con una herramienta de IA; cualquier cosa que hagas con git clone es segura por naturaleza.

Respuesta del sector: ocho hallazgos, cuatro aún sin parchear en la revelación

Manifold Security publicó el informe completo el 1 de septiembre, con ocho hallazgos repartidos entre siete herramientas de codificación con IA. Estado en el momento de la publicación:

Herramienta	Estado
Claude Code (vía fsmonitor)	Corregido (2.1.196)
Claude Code (vía ultrareview)	Sin parchear en la revelación (sigue vulnerable en 2.1.252)
Goose	Corregido (1.44.0, CVE-2026-72718)
Codex / Cursor	Corregido
Hermes Agent	Sin parchear en la revelación — arreglo fusionado el 2 de septiembre
Qwen Code / Grok Build	Sin parchear en la revelación

La cobertura de The Hacker News del 2 de septiembre aún listaba a Hermes como «arreglo pendiente» — pero Nous Research fusionó el arreglo en main ese mismo día, un día más fresca que la propia noticia.

El arreglo de Hermes: del «git al desnudo» al «git saneado»

El arreglo (PR #101483, commit f6234d00c5) es sencillo en concepto: cada sonda de git que Hermes inicia por su cuenta corre ahora en un entorno saneado que ignora por completo la configuración del propio repo.

Dos capas de defensa:

Capa 1 — saneado del entorno (noninteractive_git_env()). Todas las sondas automáticas usan ahora por defecto un «entorno git no interactivo» que fija core.fsmonitor, core.hooksPath, pager, editor y credential helpers a valores inertes mediante GIT_CONFIG_*, e ignora la configuración global y de sistema. Cuando git status refresca el índice, ya no existe ningún «programa auxiliar especificado por el repo» que ejecutar. Los puntos de llamada cubiertos incluyen la instantánea de contexto del workspace (coding_context), la construcción del árbol del proyecto en la gateway, las referencias de contexto @diff/@staged, el fingerprint del goal gate y el worktree add de arranque con -w.

Capa 2 — flags de línea de comandos (harden_git_argv()). Las variables de entorno no alcanzan a los drivers acotados por .gitattributes (el atacante nombra el driver, así que no puedes enumerarlo), así que para los subcomandos que renderizan diffs — diff, show, log, blame — Hermes inyecta ahora --no-ext-diff --no-textconv, cortando de raíz los puntos de ejecución de [diff "x"] command= y textconv= a nivel de línea de comandos.

El arreglo incluye una suite de regresión end-to-end con git real: arma un repo con configuración maliciosa y verifica que ninguna ruta automática llegue a ejecutar fsmonitor, hooks, external-diff ni textconv.

Qué deberías hacer ahora

1. Conoce tu versión: el arreglo llegó el 2 de septiembre y todavía no está en ningún release oficial (el último release, v0.21.0, salió el 31 de agosto — antes del arreglo). Si quieres protección desde el primer día, sigue main o espera al próximo release de parcheo; en cualquier caso, empieza a practicar los hábitos de abajo.
2. Desconfía de los repos «en forma de archivo»: revisa los zip, las carpetas sincronizadas y los directorios de proyecto copiados por USB antes de abrirlos. Los repos que clonas con git clone no requieren esa preocupación.
3. Autochequea un proyecto recibido antes de entregárselo a Hermes:

cd path/to/suspicious-project
git config --get core.fsmonitor      # output here = be alert
git config --get core.hooksPath
grep -nE "command *=|textconv *=" .git/config

4. No abras una sesión directamente en un directorio sospechoso: si tienes que revisar el código, haz git clone de una copia limpia primero y apunta Hermes a esa copia.

Este incidente se une a la SSH config approval gate que cubrimos antes como la misma clase de lección: los comandos de bajo nivel que una herramienta de IA ejecuta automáticamente deben asumir que su entrada no es de fiar. El arreglo de Hermes mete incluso el paso más temprano e invisible — la recopilación de contexto — dentro del perímetro de confianza. Donde no puedes verlo, ahora asume que el repo podría ser el enemigo.