Cómo un repositorio limpio induce a un agente de código a abrir un reverse shell

¿Qué es esto?

El 29 de junio de 2026, SecurityWeek difundió una prueba de concepto del equipo 0DIN de Mozilla (los investigadores Andre Hall y Miller Engelbrecht) que responde a una pregunta incómoda: ¿puede alguien que no controla más que un repositorio público de GitHub lograr ejecución de código en cualquiera que abra ese repositorio con un agente de código, sin subir una sola línea de código malicioso? Su demostración dice que sí. Un desarrollador le pidió a Claude Code algo corriente, «pon en marcha este proyecto recién clonado», y se abrió un shell interactivo en su máquina, conectado al servidor de un atacante.

El resultado es una clase de inyección de prompt indirecta propia de los agentes de código. Estas herramientas reciben autoridad para leer archivos, ejecutar comandos de shell y hacer llamadas de red. Una vez delegada esa autoridad, el contenido no confiable de un repositorio —notas de instalación, archivos README, incluso el texto de un mensaje de error— se convierte en un canal de instrucciones que el agente sigue sin que una persona revise de verdad cada paso.

Cómo funciona

La prueba de concepto publicada divide el ataque en tres piezas que, por separado, parecen inofensivas. El repositorio incluye instrucciones de instalación de apariencia normal en un README o una incidencia. Un paquete local está escrito para «fallar en cierre»: si lo usas antes de un paso init, lanza un error claro y útil que te invita a ejecutar ese paso, un patrón de desarrollo por completo ordinario. Y el paso init llama a un script de instalación que obtiene un valor de configuración desde una fuente externa y lo ejecuta.

El punto crítico está en el origen de ese valor. En lugar de figurar en el repositorio, se sirve desde un registro DNS TXT controlado por el atacante. En términos conceptuales, el script de instalación hace el equivalente de «resuelve este registro DNS y ejecuta lo que devuelva» —el conocido antipatrón de canalizar un valor obtenido directamente hacia un shell—. El repositorio nunca dice qué contiene el valor, y este está codificado, de modo que ninguna firma de reverse shell aparece en texto plano ni en el disco ni en la red. La carga real —un reverse shell clásico de una línea— se omite aquí deliberadamente: no es necesaria para comprender el hallazgo.

La cadena se ejecuta entonces sola. El agente lee los archivos e instala las dependencias, intenta usar la aplicación, se topa con el error esperado, lee el mensaje de error y ejecuta la corrección documentada como una simple recuperación de error. Esa corrección dispara el script, el script resuelve el registro DNS y el comando decodificado se ejecuta con la propia identidad del desarrollador. Como resumen los investigadores, el agente «nunca decidió abrir un shell: decidió arreglar un error». El reverse shell queda a tres niveles de indirección de todo lo que el agente evaluó realmente: un mensaje de error en el que confió, un script que obtuvo un valor y un registro DNS que nunca vio. En el terminal del desarrollador, la única salida visible son dos líneas inocuas de «entorno listo».

Por qué importa

El impacto demostrado es un shell interactivo completo que se ejecuta con los privilegios del desarrollador. Eso expone todos los secretos del entorno —claves de nube, claves de API, tokens de control de código fuente— y le da al atacante una ventana para establecer persistencia (dejar una clave SSH, añadir una tarea programada) antes de que el shell se cierre. Como la carga reside en un registro DNS y no en el código, puede sustituirse en cualquier momento sin ningún commit y sin nada que el instrumental pueda comparar, y un simple enlace al repositorio compartido en una oferta de empleo, un tutorial o un mensaje de chat alcanza a todo el que lo abra con un agente de código.

Lo que lo hace difícil es que ningún defensor ve el conjunto. El análisis estático del repositorio ve una consulta DNS. La supervisión de red ve una resolución de nombre corriente. El agente ve un paso de instalación preautorizado. La malicia solo existe en la composición —entre el repositorio, la infraestructura DNS y la confianza del desarrollador en el agente— y ninguno de los tres sistemas se examina en conjunto. Se trata de una demostración de investigadores, no de una brecha reportada: no hay víctimas confirmadas en la práctica, y debe leerse como una advertencia sobre una debilidad estructural más que como un incidente activo.

Defensas

La corrección más directa es la visibilidad sobre lo que un paso de instalación va a hacer en realidad. Un agente debería exponer no solo el comando que se dispone a ejecutar, sino también el contenido de cualquier script que ese comando invoque y todo lo que ese script obtenga en tiempo de ejecución, de modo que una acción de «ejecuta la corrección documentada» no pueda expandirse en silencio hacia la ejecución de un valor externo. Trate la generación de un comando y su ejecución como dos decisiones de confianza distintas.

Para los equipos y para los desarrolladores individuales, las recomendaciones convergen en el mínimo privilegio y el aislamiento. Ejecute los agentes de código sobre repositorios desconocidos dentro de un entorno aislado (sandbox) o un contenedor desechable que no contenga credenciales reales, para que un paso de instalación secuestrado no alcance nada valioso. No exporte secretos de producción al entorno de shell donde opera el agente. Restrinja el tráfico de red saliente a una lista de permitidos para que un shell recién abierto no pueda «llamar a casa», y desconfíe de los flujos de instalación que resuelven registros DNS TXT o canalizan contenido obtenido hacia un intérprete. Sobre todo, trate las instrucciones y los scripts de instalación de repositorios que usted no escribió como código no confiable, por más que lo recomiende una herramienta de IA —la misma disciplina que ya prescriben el «lethal trifecta» y la «Regla de dos para agentes»: nunca dejar que un agente sin supervisión combine el acceso a datos privados, la exposición a contenido no confiable y la capacidad de comunicarse hacia el exterior.

Estado

Se trata de una prueba de concepto divulgada por un equipo de investigación reconocido, no de una vulnerabilidad de producto con un identificador asignado. La tabla resume los hechos clave.

Elemento	Detalle
Fuente	0DIN (Mozilla), «Clone This Repo and I Own Your Machine»
Investigadores	Andre Hall, Miller Engelbrecht
Divulgación	Junio de 2026 (ampliamente difundida el 29 de junio de 2026 vía SecurityWeek)
Técnica	Inyección de prompt indirecta → recuperación de error del agente → carga alojada en DNS → reverse shell
Demostrado en	Claude Code; aplica a agentes de código con acceso autónomo a shell
Impacto	RCE con la identidad del desarrollador, exfiltración de secretos, persistencia
Estado	PoC de investigadores; sin explotación confirmada en la práctica

Ambas fuentes citadas son de los últimos 30 días. La lección es arquitectónica: mientras un agente de código ejecute una «corrección» sin exponer lo que esa corrección acaba lanzando, los repositorios no confiables siguen siendo un canal de ejecución —y la defensa se juega en el aislamiento, el control del tráfico saliente y el tratar los pasos de instalación de terceros como código no confiable, no en buscar dentro del repositorio cadenas maliciosas que nunca estuvieron ahí.