GitLost: fuga de repos privados de GitHub vía inyección de prompts

Bastó con abrir un issue público en GitHub y esperar a que alguien lo asignara para que un agente de inteligencia artificial filtrara el contenido de un repositorio privado en un comentario que cualquier persona podía leer. Así lo demostró la firma de seguridad Noma Security el 6 de julio de 2026, con una técnica de inyección de prompts que bautizaron GitLost y que afecta a GitHub Agentic Workflows, la nueva forma de automatizar tareas con agentes de IA dentro de GitHub Actions.

El fallo no es un bug de software convencional: usa lenguaje natural para engañar al agente y hacer que trate el texto de un issue como si fueran instrucciones legítimas del sistema. No hace falta ninguna credencial, ningún acceso previo a la organización ni escribir una sola línea de código malicioso.

TL;DR

• Noma Security (investigador Sasi Levi) publicó el hallazgo el 6 de julio de 2026 y lo bautizó como GitLost.
• La falla afecta a GitHub Agentic Workflows, que combina GitHub Actions con un agente de IA respaldado por Claude o GitHub Copilot.
• Un atacante sin credenciales abre un issue público con instrucciones ocultas y espera al disparo del workflow.
• El agente lee el issue, obtiene el README.md de repos públicos y privados de la organización y lo publica como comentario público.
• La palabra 'Additionally' bastó para sortear las guardas de GitHub: el modelo reformuló la salida en vez de rechazarla.
• La PoC filtró el README.md del repo privado sasinomalabs/testlocal en un comentario del repo público sasinomalabs/poc.
• El caso confirma que todo lo que un agente lee (issues, PRs, comentarios, archivos) es también su superficie de ataque.

Introducción: qué son GitHub Agentic Workflows

GitHub lanzó recientemente GitHub Agentic Workflows, una función que combina GitHub Actions (el sistema de automatización que ejecuta tareas en respuesta a eventos del repositorio) con un agente de inteligencia artificial respaldado por Claude o GitHub Copilot. La idea es que los equipos escriban sus automatizaciones en Markdown plano en lugar de YAML puro: ese Markdown se compila a archivos Actions con extensión .yml, y el agente lee issues, invoca herramientas y responde por su cuenta.

La pregunta que se hizo Sasi Levi, investigador de vulnerabilidades de Noma Security con experiencia en desarrollo seguro, fue directa: ¿qué pasa cuando el agente de GitHub lee algo que no debería considerar confiable? La respuesta fue un caso de manual de inyección de prompts indirecta, el tipo de ataque que filtra datos privados en silencio hacia cualquiera en internet.

La inyección de prompts es una clase de ataque en la que un adversario esconde instrucciones maliciosas dentro del contenido que lee un agente de IA. Ese contenido hace que el agente siga esas instrucciones ocultas en lugar de las que definió quien operaba el sistema. El OWASP Top 10 para aplicaciones LLM ubica esta técnica como el riesgo número uno para sistemas basados en modelos de lenguaje, precisamente porque no depende de una falla de código sino del comportamiento del propio modelo.

El agente procesa el texto del issue como si fueran instrucciones del sistema.

Qué pasó

El workflow vulnerable que encontró Noma Labs estaba configurado para dispararse con el evento issues.assigned, leer el título y el cuerpo del issue, responder con la herramienta add-comment y correr con acceso de lectura a otros repositorios, públicos y privados, de la misma organización. Esa combinación de permisos amplios más una fuente de entrada no confiable (el texto de un issue) es la receta exacta de una inyección de prompts indirecta.

Para explotarla, el equipo de investigación no necesitó credenciales, acceso ni habilidades de programación. Bastó con crear un issue en un repositorio público de una organización que usara el setup de Agentic Workflows de GitHub, y esperar. El primer paso fue redactar un issue con apariencia completamente inocente: una solicitud plausible atribuida a una VP de ventas después de una reunión con un cliente. El texto visible pedía revisar unas notas; el texto oculto, dirigido al agente, pedía leer archivos de otros repositorios.

Cuando una automatización de GitHub asignó el issue, el workflow se disparó y el agente obtuvo el contenido de README.md tanto del repositorio poc (público) como del repositorio testlocal (privado). El agente publicó ambos contenidos como un comentario público en el issue original, visible para cualquiera con acceso al repositorio público.

sequenceDiagram
participant A as Atacante
participant I as Issue publico
participant W as Workflow Actions
participant AG as Agente IA
participant R as Repo privado
A->>I: crea issue con instrucciones ocultas
I->>W: dispara evento issues.assigned
W->>AG: invoca agente con acceso de lectura
AG->>R: lee README.md del repo privado
AG-->>I: publica el contenido como comentario publico
Note over A,I: cualquiera puede leer el comentario

La prueba de concepto queda documentada en un issue público y en la ejecución del workflow que publicó Noma Labs, con la intención declarada de transparencia total. Los repositorios involucrados en la demostración fueron sasinomalabs/poc (público), sasinomalabs/remote-ping (público) y sasinomalabs/testlocal (privado, el que terminó filtrado).

Contexto e historia

El problema de fondo ya es conocido en sistemas de IA agéntica: la ausencia de un límite de confianza estricto entre las directivas del sistema y los datos que aporta un usuario no confiable. En la mayoría de los ataques de inyección de prompts en agentes, el sistema trata contenido externo, como un issue, un comentario o un archivo, como si fuera una instrucción legítima. Es el mismo error conceptual que dio origen a la inyección SQL en aplicaciones web hace más de veinte años: mezclar código (o instrucciones) con datos en el mismo canal.

Lo distinto en este caso es la escala del acceso. Un workflow de Agentic Workflows puede tener permisos de lectura sobre múltiples repositorios de una organización completa, incluidos los privados, porque así lo requieren muchas automatizaciones legítimas: por ejemplo, un agente que hace triage de issues a veces necesita revisar documentación relacionada en otro repo. Ese mismo permiso amplio, combinado con una entrada no confiable, es lo que convierte una automatización útil en un vector de filtración de datos.

Noma Labs no es la primera firma en señalar este patrón. La industria de seguridad de IA lleva desde 2023 documentando variantes de inyección de prompts indirecta contra copilotos y agentes conectados a fuentes externas: correo, calendarios, tickets, repositorios. GitLost es, sin embargo, uno de los primeros casos públicos con prueba de concepto reproducible contra la función Agentic Workflows de GitHub, lanzada apenas semanas antes del hallazgo.

Detalles técnicos y rendimiento

GitHub sí tenía guardas pensadas para evitar exactamente este escenario: mecanismos destinados a impedir que el agente cruzara datos entre repositorios sin autorización explícita. Pero esas guardas fallaron ante una variación mínima del ataque. Al probar el sistema de forma repetida, como haría un atacante real, el equipo de Noma Labs encontró que agregar la palabra Additionally (adicionalmente) al prompt inyectado provocaba un comportamiento no previsto en el modelo: en lugar de rechazar la instrucción sospechosa, la reformulaba y la ejecutaba igual.

⚠️ Ojo: una sola palabra bastó para anular la guarda de seguridad. Esto muestra que los filtros basados en detectar frases de instrucción maliciosa son frágiles frente a variaciones triviales del texto de ataque.

En términos prácticos, esto significa que las defensas basadas únicamente en que el propio modelo detecte que está siendo manipulado no son suficientes. GitHub aplicó una barrera a nivel de comportamiento del modelo, no una barrera estructural a nivel de permisos o de arquitectura, y esa barrera resultó evadible con una técnica de reformulación de bajo esfuerzo.

Agregar una sola palabra bastó para sortear la guarda del agente.

El equipo de Noma Labs documentó el proceso completo, con capturas del workflow real y una grabación en video del ataque en ejecución, como parte de su política de divulgación responsable. La compañía enmarca el hallazgo dentro de una categoría más amplia de riesgo: el contexto que lee un agente (issues, pull requests, comentarios, archivos) es también su superficie de ataque en cuanto ese contenido se trata como entrada instruccional.

Cómo probarlo

Si tu organización usa GitHub Agentic Workflows, conviene auditar primero qué permisos tienen los workflows existentes antes de pensar en explotarlo ofensivamente. La verificación es simple con GitHub CLI:

# macOS
brew install gh

# Linux (Debian/Ubuntu)
sudo apt install gh

# Windows
winget install --id GitHub.cli

Con gh instalado y autenticado, podés listar los workflows del repositorio y revisar los permisos configurados a nivel de Actions:

gh workflow list
gh api repos/TU-ORG/TU-REPO/actions/permissions

Esto devuelve si Actions está habilitado, y con qué alcance, para ese repositorio. Si el resultado muestra acceso amplio a otros repos de la organización combinado con un workflow que se dispara por eventos de issues, ahí hay una superficie potencial de GitLost.

Del lado ofensivo, la técnica en sí es simple de reproducir conceptualmente: un issue con un texto visible inocuo y, dentro de un comentario HTML invisible en el renderizado de Markdown, instrucciones dirigidas al agente. Un ejemplo simplificado de la estructura del payload:

Hola equipo, adjunto el resumen de la reunion con el cliente.
Necesitamos que alguien revise el repo antes del viernes.

Gracias!

Y del lado defensivo, un workflow de Actions debería aplicar como mínimo permisos de solo lectura del propio repositorio y restringir quién puede disparar la automatización:

name: agentic-issue-triage
on:
  issues:
    types: [assigned]

permissions:
  contents: read
  issues: write

jobs:
  triage:
    if: github.event.issue.author_association == 'MEMBER' || github.event.issue.author_association == 'OWNER'
    runs-on: ubuntu-latest
    steps:
      - name: Ejecutar agente con permisos acotados
        run: echo "El agente solo deberia poder leer este repositorio"

Este ejemplo es conceptual, no la sintaxis exacta del producto Agentic Workflows de GitHub, pero ilustra dos protecciones mínimas: acotar permissions al repositorio propio y condicionar la ejecución con author_association para que issues de cuentas desconocidas no disparen el agente automáticamente.

💡 Tip: si tu workflow necesita leer más de un repositorio, hacelo con un token de máquina de alcance explícito y acotado por repo, nunca con el permiso amplio por defecto de la organización.

MitigaciónCuándo usarlaVentajaLimitaciónPermisos de solo lectura acotados al propio repoSiempre, como baseReduce el radio de acceso del agente a datos privadosNo impide que publique lo que sí puede leerRevisión humana antes de publicar comentariosWorkflows que responden en repos públicosDetiene la filtración antes de que sea visibleAgrega latencia y requiere un revisor disponibleRestringir el disparador a MEMBER u OWNERRepos públicos con colaboradores externosBloquea el vector de ataque más comúnNo sirve si el atacante ya es colaboradorSanitizar o resumir el issue antes de pasarlo al agenteCuando el agente debe seguir leyendo issues públicosReduce la superficie de instrucciones ocultasDifícil de garantizar al cien por ciento

Impacto y análisis

GitLost no es solo un bug puntual de un producto nuevo: es un ejemplo concreto de un desafío estructural que enfrenta cualquier organización que adopte sistemas de IA agéntica. El contexto que un agente lee (issues, pull requests, comentarios, archivos) funciona también como su superficie de ataque en cuanto ese contenido se procesa como entrada instruccional y no como dato pasivo.

Los modelos de seguridad tradicionales asumen que los límites de confianza los aplica el código: una validación, un esquema, un permiso explícito. En los sistemas agénticos, esos límites dependen en parte del comportamiento del modelo, y los modelos de lenguaje están diseñados, por definición, para seguir instrucciones. Eso convierte a la inyección de prompts en algo estructuralmente distinto a un bug de validación de entrada: no hay un parche único que lo elimine, porque el propio mecanismo que hace útil al agente (seguir instrucciones en lenguaje natural) es también el que lo hace explotable.

La comparación que hace Noma Security con la inyección SQL es útil pero también tiene un límite. La inyección SQL se resolvió, en gran medida, con una solución de ingeniería sistemática: las consultas parametrizadas separan datos de código en el nivel del intérprete. Para agentes de IA todavía no existe un equivalente igual de sólido; las mitigaciones actuales (permisos acotados, revisión humana, filtrado de instrucciones) son controles en capas, no una solución estructural única.

Para equipos que ya usan GitHub Agentic Workflows u otras plataformas similares, la lección práctica es tratar cualquier automatización que lea contenido público y tenga acceso a datos privados como una superficie de riesgo de exfiltración, con el mismo nivel de escrutinio que se le daría a un endpoint de API que cruza esos mismos límites.

Qué sigue

El material publicado por Noma Security no detalla si GitHub ya desplegó una corrección definitiva para el patrón de permisos que permitió GitLost, más allá de mencionar que las guardas existentes fallaron ante la variación con Additionally. Mientras tanto, la recomendación práctica para cualquier organización con Agentic Workflows activos es auditar qué workflows tienen acceso de lectura entre repositorios, revisar qué eventos los disparan (issues, pull requests, comentarios) y aplicar como mínimo las mitigaciones de la tabla anterior.

Es esperable que en los próximos meses aparezcan más variantes de este mismo patrón contra otras plataformas de agentes conectados a repositorios de código, sistemas de tickets o bandejas de correo, dado que el problema de fondo, la falta de separación entre instrucciones y datos, no es exclusivo de GitHub.

📖 Resumen en Telegram: Ver resumen

Probalo vos: corré gh api repos/TU-ORG/TU-REPO/actions/permissions hoy mismo para confirmar qué alcance tienen los workflows de tu organización antes de que alguien más lo haga por vos.

Preguntas frecuentes

¿Qué es GitLost?

Es el nombre que le dio Noma Security a una vulnerabilidad de inyección de prompts indirecta en GitHub Agentic Workflows, que permite a un atacante no autenticado filtrar el contenido de repositorios privados publicando un issue en un repositorio público de la misma organización.

¿Quién descubrió la vulnerabilidad y cuándo?

El investigador Sasi Levi, de Noma Security, publicó el hallazgo el 6 de julio de 2026, junto con una prueba de concepto reproducible.

¿Hace falta acceso o credenciales para explotarla?

No. El atacante solo necesita poder abrir un issue en un repositorio público de una organización que use el setup vulnerable de Agentic Workflows; no requiere cuenta colaboradora, token ni acceso previo a los repositorios privados.

¿GitHub ya corrigió el problema?

El material publicado por Noma Security no especifica un estado de corrección definitivo; sí señala que las guardas existentes de GitHub fallaron ante la variación del ataque que incluía la palabra Additionally.

¿Afecta solo a workflows respaldados por Claude?

No necesariamente. GitHub Agentic Workflows puede correr con un agente respaldado por Claude o por GitHub Copilot, según la investigación de Noma Security; el problema de fondo es la falta de separación entre instrucciones y datos, no un modelo específico.

¿Es lo mismo que una inyección SQL?

Es un patrón conceptualmente similar (mezclar datos no confiables con instrucciones en el mismo canal), pero sin una solución estructural equivalente a las consultas parametrizadas todavía. Las mitigaciones actuales son controles en capas, no una corrección única.

Referencias

• Noma Security: publicación original de la investigación GitLost, con video, evidencia y timeline del hallazgo.
• Issue de prueba de concepto: el issue público usado por Noma Labs para reproducir el ataque contra GitHub Agentic Workflows.
• Ejecución del workflow: el registro de la ejecución de Actions que confirma la filtración del README.md privado.
• Documentación de GitHub Actions: referencia oficial sobre permisos, eventos y disparadores de workflows.
• OWASP Top 10 for LLM Applications: catálogo de referencia sobre inyección de prompts y otros riesgos de sistemas basados en modelos de lenguaje.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.