Un issue público puede engañar a GitHub Agentic Workflows para que filtre el contenido de los repositorios privados de una organización, según demostraron investigadores de Noma Security. El atacante solo necesita abrir un issue de apariencia normal en un repositorio público, sin credenciales robadas ni acceso a la organización. Si la organización otorgó al agente acceso de lectura a todos sus repositorios, incluidos los privados, el issue puede dirigirlo para que extraiga contenido privado y lo publique en un comentario público.
Noma denomina a la técnica GitLost. El objetivo es GitHub Agentic Workflows, una función en vista previa pública lanzada por GitHub en febrero. En lugar de escribir scripts de automatización, se escriben instrucciones en lenguaje natural en un archivo Markdown. El agente lee issues y pull requests, ejecuta herramientas y responde de forma autónoma. Puede estar potenciado por GitHub Copilot, Anthropic Claude, Google Gemini u OpenAI Codex. Los workflows son de solo lectura por defecto, pero una organización puede otorgar un token con acceso de lectura a todos sus repositorios para darle contexto transversal, incluidos los privados.
Cómo funciona el truco
La debilidad es bien conocida: inyección indirecta de prompts. Un agente de IA no puede distinguir de forma fiable entre instrucciones de su propietario e instrucciones ocultas en el contenido que lee. Por lo tanto, si un atacante escribe esas instrucciones en un issue, el agente simplemente puede seguirlas.
En la prueba de concepto de Noma, el issue malicioso se presentó como una solicitud rutinaria de un vicepresidente de ventas tras una reunión con un cliente. El workflow objetivo estaba configurado para activarse cuando se asigna un issue, leerlo y responder con un comentario. También tenía acceso de lectura a otros repositorios de la organización. Una vez que una automatización rutinaria asignó el issue, el agente extrajo el README de un repositorio privado y lo pegó en un comentario público en el issue.
GitHub implementó salvaguardas para evitar esto. En su propia documentación, la empresa advierte que "los agentes de IA pueden ser manipulados mediante inyección de prompts, contenido malicioso de repositorios o herramientas comprometidas", y el producto incluye sandboxing, tokens de solo lectura por defecto, limpieza de entrada y un paso de detección de amenazas que escanea la salida propuesta del agente antes de publicarla. Noma informó que en su prueba, un cambio de una palabra fue suficiente para eludir la protección. Anteponer "Además" a la instrucción maliciosa llevó al modelo a tratarla como una tarea secundaria, no como algo que rechazar, y la barrera de seguridad la dejó pasar.
¿Por qué es diferente?
Lo que distingue a GitLost es lo que el atacante puede controlar. "Los ejemplos anteriores de inyección de prompts se centraban mayormente en manipular lo que decía un agente", explicó Sasi Levi, líder de investigación de seguridad en Noma Security, a The Hacker News. "GitLost trata de manipular lo que un agente hace con sus permisos". El agente aquí no es una ventana de chat, sino un actor con credenciales dentro de la infraestructura CI/CD de la organización, con acceso de lectura a repositorios que el atacante no puede ver. No toca ningún servidor, no necesita credenciales robadas y no requiere acceso de escritura a nada privado. El atacante solo tiene que abrir un issue público.
La configuración encaja con lo que el desarrollador Simon Willison denominó el "triplete letal", y Levi usa el mismo término: un agente que puede acceder a datos privados, que recibe contenido externo no confiable y que tiene una forma de enviar datos al exterior. Combinar los tres genera una ruta de filtración. Esto no es el tipo de error que se corrige con un parche; como lo plantea Levi, es una consecuencia estructural de otorgar credenciales permanentes a agentes de IA mientras estos leen texto alcanzable por atacantes.
¿Por qué sigue ocurriendo?
GitLost es el último de una serie de ataques del mismo tipo, y THN ha informado de varios en los últimos meses. Una falla en GitHub Action de Anthropic Claude Code permitió que un solo issue malicioso hiciera que el agente filtrara secretos y obtuviera acceso de escritura a un repositorio. RoguePilot de Orca Security utilizó un prompt oculto en un issue de GitHub para que Copilot filtrara el token privilegiado de un repositorio. La versión del problema con agentes de GitHub se remonta al menos a mayo de 2025, cuando Invariant Labs demostró que un issue público podía hacer que un agente conectado al servidor MCP de GitHub leyera un repositorio privado y lo filtrara a través de un pull request; los investigadores lo calificaron como arquitectónico, sin parche del lado del servidor para solucionarlo. Un estudio entre proveedores llamado Comment and Control engañó a los agentes Claude Code, Gemini CLI y GitHub Copilot para que filtraran sus propias claves API a través del texto de issues y pull requests, eludiendo las defensas de tiempo de ejecución añadidas por GitHub.
Qué hacer ahora
Noma divulgó GitLost a GitHub y publicó sus hallazgos con conocimiento de la empresa. La exposición se limita a organizaciones que hayan habilitado la vista previa y hayan conectado un agente para leer entradas públicas no confiables mientras tenga acceso de lectura a repositorios privados y pueda publicar en público. Lo que un atacante podría extraer depende de lo que el token del agente pueda ver, desde código fuente propietario hasta claves internas, documentos de diseño o secretos de CI/CD. Como dice Levi, el alcance es lo que más importa: un token de agente limitado al repositorio único que gestiona es "mucho menos peligroso que uno con acceso de lectura amplio a toda la organización" por conveniencia.
En la práctica, ese acceso entre repositorios proviene de un token de acceso personal que la organización configura, por lo que se debe limitar el token al repositorio único que gestiona el workflow, no a toda la organización. Las escrituras fluyen solo a través de salidas seguras declaradas, por lo que se debe limitar lo que un workflow orientado al público puede publicar, porque el comentario que produce es el canal de exfiltración. Restringir qué autores de contenido procesará el agente y filtrar sus salidas mediante revisión humana. El paso de detección de amenazas de GitHub escanea la salida del agente antes de publicarla, pero la omisión de una palabra en Noma es un recordatorio de que un filtro es una contención, no un límite.
GitHub, al igual que otros proveedores, construyó salvaguardas para exactamente esta clase de ataque, y un cambio de una palabra las eludió. Los investigadores y los propios proveedores siguen clasificando el resultado como "limitación arquitectónica", y el argumento de Levi explica por qué la etiqueta perdura: en lenguaje natural, no existe una línea clara entre datos e instrucciones como en SQL, por lo que la solución se basa en la arquitectura en lugar de filtrar la inyección, en el aislamiento, credenciales con alcance limitado y revisión por etapas. Hasta que exista ese límite, cualquier agente que lea datos privados, reciba entradas no confiables y pueda publicar en público está a un issue ingeniosamente redactado de una filtración.
Deja una respuesta