Mastodon Mastodon Mastodon Mastodon

Cómo GitLost explota los Agentic Workflows de GitHub para filtrar repos

Foto del autor

CyberSecureFox Editorial Team

Publicado:

Investigadores de Noma Security han demostrado la técnica de ataque GitLost, que permite extraer el contenido de los repositorios privados de una organización a través de la función GitHub Agentic Workflows. Para la ataque basta con crear un issue normal en un repositorio público, sin credenciales robadas y sin ningún tipo de acceso a la organización. Si el agente de IA está configurado con permisos de lectura sobre los repositorios privados, un atacante puede hacer que publique datos confidenciales en un comentario público. Las organizaciones que utilicen la versión preliminar de Agentic Workflows deberían limitar de inmediato el alcance de los tokens de los agentes a un único repositorio.

Mecanismo de ataque

GitHub Agentic Workflows es una función lanzada en febrero de 2026 en modo de vista previa técnica pública. En lugar de escribir scripts de automatización, el usuario describe instrucciones para el agente de IA en lenguaje natural dentro de un archivo Markdown. El agente lee de forma autónoma los issues y pull requests, ejecuta herramientas y publica respuestas. Como motor pueden utilizarse GitHub Copilot, Anthropic Claude, Google Gemini u OpenAI Codex.

Por defecto, los workflows funcionan en modo de «solo lectura», pero la organización puede proporcionar al agente un token de acceso personal con permisos de lectura sobre todos los repositorios, incluidos los privados. Es precisamente esta configuración la que explota GitLost.

La base del ataque es la inyección indirecta de prompts (indirect prompt injection): el agente de IA no es capaz de distinguir de forma fiable las instrucciones del propietario de las instrucciones inyectadas en el contenido que procesa. Según los investigadores, en la demostración PoC el issue malicioso se disfrazó de una solicitud rutinaria del vicepresidente de ventas tras una reunión con un cliente. El workflow estaba configurado para activarse al asignar el issue, leer su contenido y publicar una respuesta en un comentario. Tras la asignación automática, el agente extrajo el README de un repositorio privado e insertó su contenido en un comentario público.

Elusión de los mecanismos de protección

GitHub había previsto defensas precisamente contra esta clase de ataques. Según la documentación oficial, la plataforma advierte de que «los agentes de IA pueden ser vulnerables a la manipulación mediante inyección de prompts, contenido malicioso en repositorios o herramientas comprometidas». El producto incluye una sandbox, tokens de solo lectura por defecto, depuración de entradas y una fase de detección de amenazas que analiza la salida del agente antes de su publicación.

Sin embargo, según informan los investigadores de Noma, para sortear la protección bastó con añadir una sola palabra —«Additionally»— antes de la instrucción maliciosa. El modelo la interpretó como una continuación de la tarea, y no como una orden sospechosa, y el filtro de seguridad permitió la salida. Cabe señalar que este bypass concreto solo ha sido confirmado por los investigadores de Noma y aún no se ha reproducido de forma independiente.

Por qué este ataque es fundamentalmente distinto

Según Sasi Levi, responsable de investigación de seguridad en Noma Security, la diferencia clave de GitLost frente a ejemplos anteriores de inyección de prompts es que el ataque no manipula lo que el agente dice, sino lo que el agente hace con sus privilegios. En este caso, el agente no es una ventana de chat, sino un actor autenticado dentro de la infraestructura de la organización, con permisos de lectura sobre repositorios a los que el atacante no tiene acceso.

Esta configuración se ajusta al modelo que el investigador Simon Willison denominó «tríada letal»: el agente tiene acceso a datos privados, acepta entradas externas no verificadas y dispone de un canal para sacar datos al exterior. La combinación de estas tres condiciones crea una vía de fuga de información.

Contexto: un problema sistémico de los agentes de IA

GitLost no es un caso aislado, sino parte de una serie de ataques similares contra agentes de IA en el ecosistema de GitHub. En mayo de 2025, Invariant Labs demostró que un issue público puede obligar a un agente conectado a un servidor MCP de GitHub a leer un repositorio privado y extraer datos a través de un pull request. Los investigadores calificaron el problema de arquitectónico, sin posibilidad de corrección en el lado del servidor.

El estudio multi‑vendor Comment and Control mostró que los agentes Claude Code, Gemini CLI y GitHub Copilot pueden ser forzados a revelar sus propias claves de API mediante texto en issues y pull requests, eludiendo al mismo tiempo los mecanismos de protección en tiempo de ejecución que GitHub había añadido.

Levi subraya que no se trata de un tipo de error que pueda cerrarse con un simple parche: es una consecuencia estructural de proporcionar a los agentes de IA credenciales persistentes mientras procesan texto accesible para un atacante. En el lenguaje natural no existe una frontera clara entre datos e instrucciones, como en SQL, por lo que la solución debe basarse en la arquitectura y no en el filtrado.

Evaluación del impacto

El impacto queda limitado a las organizaciones que simultáneamente han activado la vista previa de Agentic Workflows, han configurado al agente para procesar entrada pública no verificada y le han otorgado permisos de lectura sobre repositorios privados. No obstante, para estas organizaciones las posibles consecuencias son graves: en función del alcance del token, el agente puede exponer código fuente propietario, claves internas, documentación de diseño o secretos de CI/CD.

Recomendaciones de protección

  • Limite el alcance del token: el token de acceso personal utilizado por el workflow debe restringirse al único repositorio que atiende el agente, en lugar de proporcionar acceso a nivel de toda la organización.
  • Limite los canales de salida: minimice las capacidades de publicación de los workflows que procesan entrada pública; el comentario del agente es un canal de exfiltración.
  • Filtre a los autores: configure restricciones sobre de qué autores acepta contenido el agente para su procesamiento.
  • Implante revisión manual: sitúe la salida del agente detrás de una etapa de aprobación humana antes de su publicación.
  • No confíe en los filtros como frontera de seguridad: la fase integrada de detección de amenazas de GitHub es una defensa adicional, no una barrera fiable, como demostró el bypass con una sola palabra.

Noma reveló GitLost a GitHub y publicó los resultados con conocimiento de la compañía. Mientras Agentic Workflows siga en modo de vista previa, las organizaciones que lo utilicen deberían guiarse por el principio de mínimos privilegios: cada agente de IA debe tener acceso solo al repositorio que atiende directamente, y cualquier salida hacia espacios públicos debe pasar por una confirmación manual.


CyberSecureFox Editorial Team

El equipo editorial de CyberSecureFox cubre noticias de ciberseguridad, vulnerabilidades, campañas de malware, actividad de ransomware, AI security, cloud security y security advisories de proveedores. Los materiales se preparan a partir de official advisories, datos de CVE/NVD, alertas de CISA, publicaciones de proveedores e informes públicos de investigadores. Los artículos se revisan antes de su publicación y se actualizan cuando aparece nueva información.

Deja un comentario

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.