Cuando comandos CLI inofensivos se componen en un exploit en los agentes de código

¿Qué es esto?

El 3 de julio de 2026, investigadores de la Universidad Sun Yat-sen y colaboradores de las universidades de Shandong, Pekín y HKUST publicaron un artículo en arXiv que describe una superficie de riesgo pasada por alto en los agentes de código basados en LLM. Los agentes de código modernos — Claude Code, Codex CLI, Gemini CLI y herramientas similares — trabajan cada vez más emitiendo comandos ordinarios de línea de comandos: clonan repositorios, leen archivos, instalan dependencias, ejecutan pruebas, editan configuración y confirman cambios. Fieles a la filosofía Unix, esos comandos cooperan a través de un estado compartido del sistema operativo, de modo que un comando puede escribir un estado que otro comando posterior leerá. La contribución del artículo es nombrar y medir lo que ocurre cuando se abusa de esa cooperación: una secuencia de comandos individualmente inofensivos puede componerse en una capacidad muy por encima de la tarea solicitada. Los autores lo llaman riesgo de composición de comandos CLI (CCR) y muestran que los agentes actuales están ampliamente expuestos a él.

Cómo funciona

Casi todo el trabajo previo sobre seguridad de agentes de código estudia la capa de instrucción: un texto adverso colocado en un archivo, una página web, un ticket o la salida de una herramienta, que intenta orientar al modelo hacia una acción dañina. Las defensas viven en la misma capa — filtrado de prompts, entrada estructurada, aislamiento o comprobaciones en tiempo de ejecución que verifican si la llamada de herramienta propuesta coincide con la intención del usuario. Todas comparten una suposición implícita: la señal de ataque es visible en una entrada, una respuesta o una acción aislada.

El CCR rompe esa suposición. El artículo modela la ejecución de un agente como una traza de comandos con estado — cada comando es una transición sobre un estado local que incluye variables de entorno, archivos del espacio de trabajo, configuración del repositorio, scripts del ciclo de vida de los paquetes y hooks. La señal maliciosa no aparece en ningún comando aislado. Reside en una relación productor–consumidor entre pasos inofensivos: un comando escribe legítimamente un estado, un comando posterior lo consume legítimamente y el efecto combinado alcanza algo sensible. Una barrera de aprobación local que inspecciona la cadena del comando actual no puede ver el estado oculto que un comando produce o consume; la traza compuesta pasa desapercibida.

El caso ilustrativo del artículo es el patrón de la ruta de hooks de git, ya documentado públicamente en avisos sobre agentes de código: un repositorio controlado por el atacante pide al agente, a través de su README, ejecutar un paso de instalación de una línea que reapunta el directorio de hooks de git al repositorio; el commit posterior y rutinario del agente lee entonces esa configuración y ejecuta el hook plantado en el contexto del agente, resultando en ejecución de código. Ninguno de los dos comandos es malicioso por sí solo. Para hacer emerger tales casos a escala, los investigadores construyeron un marco guiado por conocimiento que destila comportamientos comando–estado validados a partir de CVE públicos, avisos de mantenedores y pruebas de concepto de investigadores, los compone en flujos de trabajo plausibles y prueba a los agentes en caja negra. Este artículo mide una clase de riesgo existente construida sobre conocimiento ya público; no es un exploit nuevo.

Por qué importa

En cinco agentes de código CLI reales y cinco modelos de base, a lo largo de 2 525 pruebas, los ataques por composición alcanzan una tasa de éxito de extremo a extremo del 96,59 % bajo tareas de desarrollo de apariencia inofensiva, mientras que las líneas base en la capa de instrucción no superan el 2,18 %. La base de conocimiento estructurada importa: produce más de un 50 % de casos efectivos adicionales frente a un generador de modelo autónomo. Como el sustrato CLI alcanza directamente la máquina del desarrollador y el entorno de producción, el impacto no es teórico — la misma clase de composición puede borrar datos, exfiltrar código fuente y credenciales, envenenar una cadena de suministro aguas abajo, plantar puertas traseras persistentes o pivotar hacia sistemas internos.

El hallazgo más agudo es defensivo. Los autores evaluaron cinco defensas desplegadas representativas y encontraron que ninguna observaba el riesgo de composición, porque cada una razona sobre un comando o acción aislada en lugar de sobre las relaciones de estado a lo largo de la traza. Esa es la brecha estructural: la unidad de riesgo relevante es la traza de comandos completa, pero los controles en producción todavía juzgan los comandos de uno en uno.

Defensas

El cambio práctico consiste en dejar de tratar cada cadena de comando como la unidad de seguridad y empezar a rastrear la procedencia del estado a lo largo de la traza. Instrumente el agente para que registre el estado que cada comando produce y consume — variables de entorno, configuración de git y de herramientas, hooks, scripts del ciclo de vida de los paquetes — y añada fricción cuando un comando posterior sensible a la seguridad consuma un estado escrito a partir de contenido no confiable, como un repositorio clonado o una página descargada. Controle a los consumidores, no solo a los productores: un commit, una instalación o una prueba que dependa de una configuración escrita por un paso anterior a partir de entradas no confiables merece revisión, aunque cada comando parezca rutinario.

Reduzca la autoridad permanente de la que depende la capacidad compuesta. Ejecute los agentes de código en un entorno aislado sin acceso a credenciales reales ni a sistemas de producción, y desactive por defecto las superficies de ejecución automáticas — fije o ignore las rutas de hooks de git, omita los scripts del ciclo de vida de los paquetes (por ejemplo, con la supresión de scripts durante la instalación) y aísle la configuración que el agente puede modificar. Añada aprobación humana en las fronteras de la traza donde el estado producido cambia la semántica de ejecución posterior. Por último, someta a los agentes de código a ejercicios de red team con casos de composición multicomando, y no solo con inyección en la capa de instrucción, alineando los controles con la dirección propuesta por el artículo: una defensa consciente de la procedencia que razone sobre las relaciones de estado a lo largo de la traza en lugar de inspeccionar acciones aisladas.

Estado

Elemento	Detalle
Contribución	Nombra y mide el riesgo de composición de comandos CLI (CCR) en agentes de código
Método	Marco guiado por conocimiento que destila comportamiento comando–estado desde CVE, avisos y PoC públicos
Evaluación	5 agentes de código CLI · 5 LLM de base · 2 525 pruebas
Éxito de ataque	96,59 % de extremo a extremo bajo tareas inofensivas · líneas base capa de instrucción ≤ 2,18 %
Defensas desplegadas	5 defensas representativas probadas — ninguna observa el riesgo de composición
Dirección propuesta	Defensa consciente de la procedencia sobre la traza de comandos
Caso real	Composición RCE vía ruta de hooks de git en un IDE-agente de código — CVE-2026-26268

Fecha clave: artículo publicado en arXiv el 3 de julio de 2026.