NoticiasNews

Clonar un repositorio ya es ejecutar código ajeno: un archivo de configuración de Git rompe el aislamiento de Claude Code, Codex, Cursor y compañíaCloning a Repo Now Means Running Someone Else’s Code: One Git Config File Breaks the Sandbox in Claude Code, Codex, Cursor and Friends

2026-09-14

Investigadores de seguridad publicaron este mes una familia de hallazgos que afecta a prácticamente todos los agentes de codificación con IA que hoy se usan en empresas: Codex, Claude Code, Cursor, Hermes Agent, Qwen Code y Grok Build, entre otros. La Cloud Security Alliance extendió los hallazgos para incluir también a GitHub Copilot Agent.

El mecanismo es tan simple que resulta incómodo. Git tiene un ajuste de rendimiento llamado core.fsmonitor cuyo valor es, literalmente, un comando que Git ejecuta para identificar archivos modificados. Y Git lee ese valor del propio .git/config del repositorio. Es decir: el repositorio le dice a Git qué comando correr.

Por qué el sandbox no lo detiene

Los investigadores fueron explícitos en que no se trata de un escape de sandbox clásico. El problema es de confianza: los archivos que el agente produce dentro de su entorno aislado son luego procesados por software del sistema anfitrión que sí confía en ellos. El aislamiento se respeta y el atacante igual gana, porque el código no sale del sandbox: sale un archivo, y otro programa de confianza lo ejecuta.

Lo más incómodo es cuándo se dispara:

En Claude Code y Hermes Agent, la carga útil se ejecuta antes de que el usuario acepte el aviso de confianza del espacio de trabajo.
En Qwen Code, antes de que el usuario se haya autenticado.
En Grok Build, con la primera pulsación de tecla.
En Cursor, una configuración de hooks .claude controlada por el espacio de trabajo se convirtió en ejecución de comandos sin aislamiento, registrada como CVE-2026-48124 y corregida en la versión 3.0.0.

Es decir: la pantalla de “¿confías en los autores de este repositorio?” —el control en el que todos aprendimos a apoyarnos— llega tarde en varios de estos productos. El código ya corrió con los privilegios del usuario: puede leer, modificar o borrar archivos y alcanzar cualquier recurso al que esa cuenta tenga acceso.

Un dato que conviene retener: hasta ahora ninguna fuente reporta explotación real de estos hallazgos. Es una ventana para actuar, no un incendio.

Qué hacer el lunes por la mañana

Actualizar. Cursor 3.0.0 y las versiones corregidas de cada agente. Es lo primero y lo más barato.
Tratar un repositorio clonado como entrada no confiable. Clonar el repositorio de un proveedor, de un candidato en un proceso de selección o de un ejemplo encontrado en Internet es abrir un archivo ejecutable de origen desconocido. Aislarlo en una máquina virtual o un contenedor desechable deja de ser paranoia.
Revisar con qué cuenta corren estos agentes. Si el desarrollador trabaja con una cuenta que tiene credenciales de producción en el llavero del sistema, el radio de daño es la producción entera.
Inventariar qué agentes se están usando. En la mayoría de las empresas estos asistentes entraron por decisión individual del desarrollador, no por una compra de TI. No se puede parchar lo que no está en ninguna lista.

La lección que trasciende al bug

Hay un patrón que se repite: el mercado premia el envío rápido de herramientas con IA, y el modelo de amenazas se escribe después. Cada vez que una herramienta gana la capacidad de escribir archivos y ejecutar comandos en nombre del usuario, hereda toda la superficie de ataque de los formatos que toca. No es un argumento contra usar agentes de codificación —son productivos y están para quedarse—, sino a favor de tratarlos como lo que son: software con privilegios, dentro de un inventario, con una versión conocida y una política de actualización.

En TEKFENIX construimos software empresarial a medida y productos SaaS, y esa disciplina es parte del trabajo: control de versiones de las herramientas que tocan el código, entornos aislados para material de terceros y separación estricta entre credenciales de desarrollo y de producción. Con Servigo365, un aviso como este deja de circular por chats sueltos y se convierte en un ticket con responsable y fecha de cierre verificable; con CumplimientoControl, las organizaciones reguladas conservan la evidencia de que la remediación ocurrió —quién actualizó qué, cuándo y bajo qué aprobación—, que es precisamente lo que se pide cuando llega la auditoría.

Security researchers published a family of findings this month affecting virtually every AI coding agent in enterprise use today: Codex, Claude Code, Cursor, Hermes Agent, Qwen Code and Grok Build, among others. The Cloud Security Alliance extended the findings to include GitHub Copilot Agent as well.

The mechanism is uncomfortably simple. Git has a performance setting called core.fsmonitor whose value is, literally, a command Git runs to identify changed files. And Git reads that value from the repository’s own .git/config. In other words: the repository tells Git what command to run.

Why the sandbox doesn’t stop it

Researchers were explicit that this isn’t a classic sandbox escape. It’s a trust problem: files the agent produces inside its isolated environment are later processed by host software that does trust them. Isolation is respected and the attacker still wins, because the code doesn’t leave the sandbox — a file does, and another trusted program executes it.

The most uncomfortable part is when it fires:

On Claude Code and Hermes Agent, the payload executes before the user accepts the workspace-trust prompt.
On Qwen Code, before the user has authenticated.
On Grok Build, on the first keystroke.
On Cursor, a workspace-controlled .claude hook config turned into unsandboxed command execution, tracked as CVE-2026-48124 and fixed in version 3.0.0.

Meaning: the “do you trust the authors of this repository?” screen — the control we all learned to lean on — arrives too late in several of these products. The code already ran with the user’s privileges: it can read, modify or delete files and reach any resource that account can reach.

One figure worth holding onto: so far no source reports real-world exploitation of these findings. This is a window to act, not a fire.

What to do Monday morning

Update. Cursor 3.0.0 and each agent’s fixed release. It’s the first and cheapest step.
Treat a cloned repository as untrusted input. Cloning a vendor’s repo, a job candidate’s take-home, or an example found online is opening an executable file of unknown origin. Isolating it in a VM or a disposable container stops being paranoia.
Check which account these agents run as. If the developer works from an account holding production credentials in the system keychain, the blast radius is all of production.
Inventory which agents are in use. At most companies these assistants arrived through individual developer choice, not an IT purchase. You can’t patch what isn’t on any list.

The lesson beyond the bug

A pattern keeps repeating: the market rewards shipping AI tooling fast, and the threat model gets written afterward. Every time a tool gains the ability to write files and run commands on the user’s behalf, it inherits the entire attack surface of the formats it touches. This isn’t an argument against using coding agents — they’re productive and here to stay — but for treating them as what they are: privileged software, inside an inventory, with a known version and an update policy.

At TEKFENIX we build custom enterprise software and SaaS products, and that discipline is part of the work: version control over the tools that touch the code, isolated environments for third-party material, and strict separation between development and production credentials. With Servigo365, an advisory like this stops circulating through scattered chats and becomes a ticket with an owner and a verifiable close date; with CumplimientoControl, regulated organizations retain the evidence that remediation happened — who updated what, when and under whose approval — which is precisely what gets asked for when the audit arrives.

← Volver al blog← Back to blog