GitLost: engañan a un agente de IA de GitHub para filtrar repositorios privados

• Noma Labs descubrió GitLost, una vulnerabilidad de inyección indirecta de prompts en GitHub Agentic Workflows, que permitía exponer datos de repositorios privados de la misma organización en comentarios públicos usando solo issues de repositorios públicos
• Esta función compila workflows en Markdown a archivos YAML de Actions, y funciona con un agente de IA basado en Claude o GitHub Copilot que lee issues, invoca herramientas y accede a repositorios dentro de la organización
• El workflow vulnerable leía el Title y el Body del issue en el evento issues.assigned y respondía con add-comment, mientras tenía permisos de lectura sobre repositorios públicos y privados
• Al atacante le bastaba con abrir un issue plausible en un repositorio público, sin código, permisos de acceso ni credenciales; en las pruebas, el contenido de README.md de poc y testlocal se publicó en comentarios de issues públicos
• Las barreras de seguridad de GitHub no bloquearon como se esperaba la variante con “Additionally”, y en IA agéntica la propia ventana de contexto debe considerarse superficie de ataque, separando el contenido controlado por usuarios de las instrucciones confiables

---

El límite de confianza al que apuntó GitLost

• Noma Labs descubrió una vulnerabilidad llamada GitLost en los nuevos Agentic Workflows de GitHub
• Si un atacante no autenticado publicaba un GitHub Issue manipulado en un repositorio público de la misma organización, podía inducir al agente a obtener datos de repositorios privados dentro de la organización
• El método de ataque corresponde a una inyección indirecta de prompts, que oculta instrucciones maliciosas dentro del contenido que lee el agente de IA
• Si las instrucciones ocultas por el atacante se procesan con prioridad sobre las instrucciones previstas por el operador, los datos privados pueden quedar expuestos en comentarios de issues públicos visibles para cualquiera

Cómo funcionan GitHub Agentic Workflows

• GitHub Agentic Workflows permite a los equipos escribir automatizaciones de repositorios en lenguaje natural
• Los workflows se escriben como archivos Markdown .md y se compilan a archivos GitHub Actions .yml en formato YAML
• Al ejecutarse, un agente de IA basado en Claude o GitHub Copilot trabaja dentro de los permisos configurados
  • Leer GitHub Issues
  • Invocar herramientas
  • Acceder a otros repositorios dentro de la organización

Condiciones del workflow vulnerable

• La configuración vulnerable identificada por Noma Labs se vuelve problemática cuando se combinan issues públicos y permisos del agente
  • El workflow se dispara con el evento issues.assigned de GitHub
  • Lee el Title y el Body del issue
  • Publica un comentario con la herramienta add-comment
  • Tiene permisos de lectura sobre otros repositorios dentro de la organización
    • Repositorios públicos
    • Repositorios privados
• El atacante no necesitaba escribir código adicional ni contar con permisos de acceso o credenciales
• La única condición necesaria era abrir un issue en un repositorio público de una organización que usara GitHub Agentic Workflow

Flujo del ataque

• Los investigadores redactaron un GitHub Issue plausible que parecía solicitado por el VP Sales después de una reunión con un cliente
• Cuando se asignó el issue, se disparó la acción del workflow, y en las pruebas también funcionó de la misma forma con otra GitHub workflow action
• Después de que la automatización de GitHub asignó el issue, el workflow ejecutado por el evento hizo que el agente obtuviera contenido de repositorios
• El agente fue inducido a obtener el contenido de README.md de los siguientes repositorios
  • Repositorio público poc
  • Repositorio privado testlocal
• Luego, el agente de GitHub publicó ese contenido como comentario en un issue del repositorio público, dejándolo accesible para cualquiera

Evasión de las barreras de seguridad con “Additionally”

• GitHub tenía barreras de seguridad limitadas para impedir este escenario
• Noma Labs probó iterativamente varias variantes, como lo haría un atacante
• Al agregar la palabra clave “Additionally”, se produjo un comportamiento no deseado: el modelo no se negó y reestructuró la salida
• Con esta evasión, las barreras de seguridad de GitHub no funcionaron como se esperaba y no impidieron la filtración de datos

PoC y datos expuestos

• Noma Labs publicó los hallazgos, el workflow reproducible y evidencia real
  • Workflow run: https://github.com/sasinomalabs/poc/actions/runs/23909666039
  • Issue: https://github.com/sasinomalabs/poc/issues/153
• Los datos filtrados incluían el contenido de README.md de los siguientes repositorios
  • sasinomalabs/poc: repositorio público
  • sasinomalabs/remote-ping: repositorio público, se confirmó que no tenía README
  • sasinomalabs/testlocal: repositorio privado

Premisas de seguridad que cambian en la IA agéntica

• La ventana de contexto del agente es al mismo tiempo espacio de trabajo y superficie de ataque
• Todo el contenido que lee el agente puede convertirse en arma
  • Issues
  • Pull Requests
  • Comentarios
  • Archivos
• Los modelos de seguridad tradicionales suelen asumir que los límites de confianza se aplican mediante código
• En los sistemas agénticos, parte de los límites de confianza se aplica mediante el comportamiento del modelo
• Como los modelos, por naturaleza, siguen instrucciones, la inyección de prompts se convierte en una vulnerabilidad categórica para la IA agéntica, del mismo modo que la inyección SQL lo fue para las aplicaciones web
• Este tipo de vulnerabilidad requiere estrategias y defensas sistemáticas

Defensas recomendadas y proceso de divulgación

• El contenido controlado por usuarios no debe tratarse como entrada de instrucciones confiable para un agente de IA
• Los permisos del agente deben limitarse al mínimo necesario
  • Los agentes que pueden acceder a múltiples repositorios se vuelven objetivos de ataque especialmente valiosos
• Debe limitarse lo que un agente puede publicar públicamente, como en los casos en que responde al contenido de un issue
• Antes de pasar entradas de usuario al modelo, deben sanearse o aislarse del contexto de instrucciones
• GitLost fue divulgado de forma responsable a GitHub, y los detalles de la vulnerabilidad se compartieron con conocimiento de GitHub

[GN⁺]

Opiniones de Hacker News

• La analogía de que la inyección de prompts ocupa en la IA agéntica el mismo lugar que la inyección SQL tuvo en las apps web me parece extraña. Creo que la inyección de prompts es mucho más fatal para los LLM que la inyección SQL
  La inyección SQL surgía cuando la entrada del usuario pasaba a formar parte de una cadena de comandos enviada al motor SQL; si una entrada maliciosa cerraba el comando actual con tokens de sintaxis SQL y luego añadía sus propios comandos SQL, el motor ejecutaba ambos. La solución fue usar cadenas de comandos fijas, estáticas y precompiladas, como sentencias preparadas, y aplicar cualquier entrada arbitraria del usuario solo como datos
  En un agente, una mitigación similar sería tener acciones fijas como “leer repo 1” y “leer repo 2”, y usar la entrada del usuario solo como datos para elegir qué acción ejecutar; pero esa tecnología ya la llamamos menú. La diferencia es que el valor de un LLM está, en esencia, en ser más que un menú, mientras que el valor de SQL no necesita ir más allá de “lógica predefinida aplicada a datos arbitrarios”

  • Exacto. La inyección SQL surgía porque la entrada del usuario se trataba no como datos puros sino como parte del comando, y se resolvió separando ambas cosas. La inyección de prompts es difícil de evitar porque la propia entrada del usuario está pensada como comando
  • Más que decir que “la solución son sentencias preparadas”, el punto central es el enlace de parámetros. Consiste en enviar los parámetros por separado de la sentencia SQL, separando el código de los datos del usuario
    Permitir solo acciones limitadas a un agente cubre solo algunos problemas especiales, y tampoco separa el código de los datos del usuario, así que no es el mismo problema. Tener solo acciones limitadas se parece más a usar permisos de base de datos más estrictos. Si solo se permite el SQL que el usuario de todos modos podría ejecutar, la inyección SQL pierde casi toda relevancia
  • Es el mismo tipo de problema que la inyección SQL, pero no tiene la misma dificultad de solución. Pueden aparecer muchos problemas más sutiles, pero como analogía explicativa está bastante bien
    Hacer que se elija de un menú también es una opción, pero el rango de acciones posibles puede diseñarse de forma más amplia. Si le das una herramienta de email, puede enviar spam a clientes; si la bloqueas para que solo pueda responder, reduces el alcance del accidente. Igual que con vulnerabilidades donde se filtran datos mediante renderizado de imágenes, también hay que limitar la filtración de datos
  • La inyección de prompts no es fatal y, en realidad, más que un problema real en sí, se acerca a exponer un problema subyacente de arquitectura de seguridad. Es similar a los ataques de ingeniería social contra humanos
    La solución también es la misma. Aplicar control de acceso basado en roles con privilegio mínimo y exigir aprobación de un administrador para acciones importantes. Entonces lo peor que un LLM puede hacer por sí solo es emitir palabras inapropiadas
  • No estoy seguro de que esto sea un problema tan profundo como todos creen. La inyección SQL es igual de peligrosa. Abre acceso ilimitado a todas las operaciones de base de datos que el usuario de la consulta puede realizar
    Una mitigación son las sentencias preparadas, pero otra es no permitir a ningún usuario acceso completo a toda la base de datos. Un usuario de solo lectura no debería poder hacer DROP TABLE, independientemente de si hay inyección SQL o no
    Este agente tiene acceso de lectura ilimitado y no tiene concepto de “destinatario” de la respuesta. Si se incluyeran los permisos del destinatario, hacer que el acceso de lectura se deniegue automáticamente sería bastante simple. No es la única solución, pero no es difícil imaginar soluciones en esa dirección
    El ejemplo del “menú” también implica que nada cambió. Ya sea un LLM o un empleado humano, lo permitido es solo un conjunto fijo y controlado de acciones. La libertad está sobre todo en la expresión; la autorización es un conjunto fijo. No veo por qué debería ser más que un menú

• No entiendo por qué esto sería una vulnerabilidad de GitHub. Si los investigadores le dieron al agente permisos de acceso a repositorios privados y le pidieron responder preguntas en un repositorio público, obviamente es posible extraer información privada.
  Es como crear una tarea común de CI con acceso a secretos y ejecutarla desde un PR público. Si configuras GitHub para que código público o instrucciones de un LLM se ejecuten en un contexto que puede acceder a cosas sensibles, habrá filtraciones. Eso no es culpa de GitHub, sino de quien lo configuró.

  • Parece que asumieron que los permisos estaban limitados solo al repositorio en el que se hacía la pregunta, y que no incluían repositorios privados. Entiendo la lógica de ambos lados.
  • GitHub no facilita configurar de forma segura el acceso de agentes. Los tokens de acceso normales y las credenciales de apps no tienen controles granulares suficientes como para dar acceso directo a repositorios privados.
    Aunque limites estrictamente el alcance del token, el acceso a repositorios públicos siempre queda permitido y, por ejemplo, permanece una ruta de filtración mediante issues de repositorios públicos. Para hacerlo de forma segura, habría que complementarlo con un proxy MITM que implemente controles más estrictos que los que ofrece GitHub.
    GitHub Agentic workflows debería ser la solución oficial de primera línea para este tipo de problema, pero parece que todavía queda trabajo por hacer, tanto en el modelo de seguridad como en la usabilidad segura.
    Más detalles: https://haulos.com/blog/do-not-give-your-agent-github-access...
  • En el centro de estos ataques de inyección de prompts está el problema de no limitar correctamente el alcance de permisos del agente. En este caso, según lo que el agente realmente deba hacer, se podrían tener agentes de workflow separados por repositorio, o bien un agente con acceso más amplio a repositorios pero configurado para que solo usuarios de una lista de permitidos puedan activarlo.
    Eso también es compatible con el desarrollo público, permite que externos abran issues públicos y refleja el nivel de confianza que quieres asignar a cada usuario. Si se piensa bien, seguramente hay más opciones.
    Para eso hace falta soporte técnico para alcances y permisos finos, y dedicar tiempo a evaluar qué se quiere lograr con el agente y cuáles son los permisos y capacidades mínimos necesarios.
    Lo primero probablemente llegue. El uso de agentes todavía es como el Lejano Oeste. Será interesante ver qué abstracciones reducen la fricción de descubrir y definir alcances y permisos al diseñar agentes, y qué interfaces logran equilibrar granularidad y usabilidad al limitar las capacidades de un agente.
    Lo segundo siempre ha sido el obstáculo central para construir software de alta calidad. Tomarse el tiempo para pensar bien e implementar bien choca de frente con la idea de “moverse rápido y romper cosas” lanzando agentes a cualquier lado.
  • ¿Hay alguna forma de separar el acceso por workflow agéntico, de modo que uno acceda a datos sensibles y otro solo a datos públicos? ¿El valor predeterminado limita el alcance solo al repositorio actual? ¿GitHub informa adecuadamente los riesgos de combinar acceso a datos de repositorios privados con workflows agénticos?
    Si la respuesta a cualquiera de estas preguntas es “no”, entonces hay un problema. Los GitHub Workflows clásicos también tienen un montón de escaladas de privilegios mediante workflows activados por PR, pero ese es otro tema.
  • Desde el punto de vista de permisos, un LLM es simplemente una terminal tonta. Lo que se quiere parece ser crear permisos sintéticos al vuelo a partir del prompt, pero eso no es una solución de “frases preparadas”; se parece más a “voy a limpiar consultas SQL de usuario con regex”. Ya sabemos cómo termina eso.
    La verdadera solución es mejorar la UI de control de permisos por prompt. Así como eliges “búsqueda web sí/no”, debería ser fácil activar o desactivar una opción como “incluir mis repositorios privados”.

• Es gracioso ver a los investigadores eludir las barreras de seguridad de las que GitHub presumía con una sola palabra como “Additionally”. Muestra que intentar establecer una frontera de seguridad fuerte dentro de la ventana de contexto de un LLM está condenado al fracaso.
  El modelo está hecho, en esencia, para seguir instrucciones, así que si mezclas reglas del sistema con entradas del usuario, ganan las instrucciones más recientes o más insistentes.

• ¿Por qué en la sección de “divulgación responsable” no aparece cuándo se corrigió, ni si GitHub lo aceptó o lo rechazó? Dice que GitLost fue divulgado responsablemente a GitHub y que comparten los detalles con conocimiento de GitHub, ¿pero todavía no lo arreglaron?

  • Esto no es un bug de software común, y no puede “arreglarse” de la misma forma en que no puedes “arreglar” que un empleado común de soporte sea engañado. La respuesta es no darle al LLM acceso simultáneo a entradas no confiables y datos sensibles.
  • Me pregunto si el autor original hizo el experimento con la siguiente configuración activada. Existe una configuración literal para bloquear esto. Quisiera saber si esa configuración surgió por este reporte o si fue una negligencia del reportero no mencionarla en un comentario.
    https://github.github.com/gh-aw/reference/cross-repository/#...
  • ¿Qué habría que arreglar? Solo le dieron al LLM acceso a datos privados junto con la capacidad de leer comentarios públicos. Es simplemente una mala configuración.

• Las grandes empresas como Microsoft, por presión de los inversionistas, ahora están metiendo AI en todos sus productos para afirmar que son compañías de AI. Algo similar a lo que hizo Adobe.
  Los consumidores se están cansando de estas integraciones de AI a medio hacer, y parece que pronto se llegará a un punto de quiebre.

  • Yo ya terminé. Me mudé a Forgejo. Es excelente y todo funciona mejor.
    En serio: al hacer clic por todos lados, todo responde al instante, y CI con runners conectados funciona de maravilla. La documentación para configurar runners podría ser un poco más clara, pero fuera de eso todo fue increíblemente fluido.
  • Microsoft es una empresa que cotiza en bolsa. ¿Qué inversionista está presionando para arruinar GitHub con funciones de AI que nadie pidió? ¿En qué reunión ocurre eso?
  • Estoy de acuerdo, pero creo que los productos empresariales de AI son bastante impresionantes. Los inversionistas y consumidores no lo entienden bien, y los empleados no tienen margen para negociar.
    Los ingresos realmente existen y son impresionantes, y están reemplazando ingresos basados en consumidores y asientos. El mercado todavía está reduciendo los múltiplos de SaaS, y creo que ese juicio es correcto. Si separas los ingresos en los reportes trimestrales, hay una gran historia de crecimiento derivada de eficiencia real.

• No entiendo por qué una action que se ejecuta en el contexto de un repositorio público tenía permisos de acceso a repositorios privados. Al ver el workflow, parece que usa un github token, que normalmente no concede permisos sobre repositorios privados.
  ¿O será que el propio agente somehow tenía permisos más altos? Si es así, el agente estaba mal configurado. Ya sabemos que no se debe confiar en que un agente imponga restricciones.

• Este artículo se lee como marketing de Noma. Tiene un nombre simpático, logo, título clickbait y hasta un tono dramático que parece dirigido a lectores no técnicos.
  ¿Cuál es la vulnerabilidad real? Que si le das datos privados a un LLM y permites que cualquiera interactúe con él, esos datos pueden filtrarse. Es demasiado obvio.

• Este tipo de gente le dará a un LLM permisos de escritura sobre todo el disco y luego se quejará de que hizo operaciones destructivas.
  Si no quieres que un agente de AI lea repositorios privados, no le des acceso a repositorios privados. Esto no es un problema de bypass de permisos, sino de prompt injection, y no se puede resolver de forma confiable en la capa del agente.

• O bien es un problema ya resuelto, o GitHub todavía no lo ha resuelto y, mientras tanto, actores maliciosos intentarán explotar vulnerabilidades en repositorios.
  Como hay muchos repositorios, existe una probabilidad distinta de cero de que ocurra alguna filtración. Pero, como pasa con las víctimas de estafas, casi nadie va a admitir que sufrió una filtración.