GitLost: una issue pública puede filtrar repositorios privados vía un workflow agéntico de GitHub

¿Qué es esto?

El 7 de julio de 2026, los investigadores de Noma Security publicaron GitLost, una técnica que convierte una issue pública corriente en un canal para exfiltrar el código fuente privado de una organización. El objetivo es GitHub Agentic Workflows, una funcionalidad que entró en vista previa técnica en febrero de 2026 y que permite reemplazar los scripts de automatización por instrucciones en lenguaje natural (Markdown) dirigidas a un agente de IA —impulsado por GitHub Copilot, Claude de Anthropic, Google Gemini u OpenAI Codex— que lee issues y pull requests, invoca herramientas y responde por sí mismo.

El hallazgo fue difundido el mismo día por The Hacker News y The Register. Noma lo comunicó a GitHub y lo publicó con el conocimiento de la empresa. No hay CVE: según lo plantean los investigadores, es una consecuencia estructural de cómo están cableados estos agentes, no un defecto de código que cierre un solo parche.

Cómo funciona

El mecanismo es la inyección de prompt indirecta. Un agente LLM no puede distinguir de forma fiable las instrucciones de su operador de las ocultas en el contenido no confiable que lee. Los Agentic Workflows son de solo lectura por defecto, pero una organización puede entregar a un workflow un token de acceso personal con permiso de lectura sobre todos sus repositorios —incluidos los privados— para darle al agente contexto entre repositorios. Es precisamente esa concesión la que GitLost vuelve en contra de la víctima.

En la prueba de concepto de Noma, el atacante abre una issue de apariencia inofensiva en un repositorio público de la organización objetivo. El cuerpo de la issue se disfraza de solicitud rutinaria —en la demo, un mensaje de un «VP of Sales» tras una reunión con un cliente— con instrucciones ocultas que piden al agente recuperar el contenido de un repositorio privado y republicarlo. Una automatización rutinaria asigna la issue, el workflow se activa, lee la issue, sigue las instrucciones inyectadas y copia el README de un repositorio privado en un comentario público de esa misma issue.

GitHub había anticipado exactamente este tipo de abuso: su documentación advierte que los agentes «pueden ser manipulados mediante inyección de prompt», y el producto incorpora aislamiento (sandbox), lectura seguridad por defecto, limpieza de entradas y una etapa de detección de amenazas que analiza la salida propuesta antes de publicarla. Noma informa que un cambio de una sola palabra bastó para sortear esa protección: anteponer «Additionally» («Además») a la instrucción maliciosa llevó al modelo a tratarla como una tarea complementaria legítima en lugar de rechazarla, y la salida pasó.

Por qué importa

Lo que distingue a GitLost de las demostraciones de inyección anteriores es lo que controla el atacante. Los ejemplos previos manipulaban sobre todo lo que el agente decía; aquí el atacante manipula lo que un agente con credenciales hace con sus permisos. El agente no es una ventana de chat: es un actor alojado en infraestructura adyacente a la CI/CD, con acceso de lectura que abarca repositorios que el atacante no puede ver. El ataque no toca ningún servidor, no requiere credenciales robadas ni permisos de escritura. Basta con abrir una issue pública.

Este montaje es un caso de manual de la lethal trifecta de Simon Willison: un agente que puede alcanzar datos privados, ingiere contenido externo no confiable y dispone de una vía para exfiltrar. Reúna los tres y tendrá una ruta de fuga; lo que un atacante puede extraer depende por completo del alcance del token —código propietario, claves internas, documentos de diseño o secretos de CI/CD—. GitLost prolonga una serie de la misma familia, junto a la falla bot-actor de Claude Code GitHub Action y la técnica multiproveedor Comment and Control —y, como ellas, se archiva bajo «limitación arquitectónica», porque el lenguaje natural no ofrece una frontera nítida entre dato e instrucción que hacer cumplir.

Defensas

Las mitigaciones de Noma se centran en el alcance y la arquitectura, no en un mejor filtrado:

• Restrinja el token a un solo repositorio, no a la organización. El acceso entre repositorios proviene de un PAT que configura la organización. Un token limitado al repositorio que el workflow procesa es mucho menos peligroso que un acceso de lectura a toda la organización concedido por comodidad. Es el control de mayor impacto.
• Limite lo que un workflow público puede publicar. Las escrituras pasan por salidas seguras declaradas, y el comentario público es el canal de exfiltración: acótelo. Rompa la pata «exfiltrar» de la trifecta allí donde el agente lea entradas no confiables.
• Restrinja de qué autores procesa contenido el agente y someta las salidas del agente a revisión humana antes de publicarlas.
• Aísle la entrada no confiable del contexto de instrucciones antes de que llegue al modelo, y considere la detección de amenazas integrada una red de seguridad, no una frontera: el sorteo con «Additionally» lo demuestra.
• Audite los workflows que reúnen la trifecta: entrada pública no confiable, acceso de lectura privado y salida pública. Eliminar cualquiera de los tres cierra la ruta de fuga.

Estado

Elemento	Valor
Técnica	GitLost — inyección de prompt indirecta en GitHub Agentic Workflows
Divulgada por	Noma Security (Noma Labs)
Fecha de publicación	7 de julio de 2026
CVE	Ninguno — limitación estructural / arquitectónica
Afectados	Workflows agénticos que leen entrada pública no confiable, con acceso de lectura privado, capaces de publicar en público
Protección sorteada	La detección de amenazas de GitHub franqueada con un prefijo de una palabra («Additionally»)
Estado del proveedor	Divulgación responsable a GitHub; publicada con su conocimiento

Fechas clave: 13 de febrero de 2026 — GitHub Agentic Workflows en vista previa técnica. 7 de julio de 2026 — Noma Security publica GitLost.