Los investigadores de Noma Security han demostrado que un problema revelado puede engañar a GitHub Agentic Workflows para que filtren el contenido de los repositorios privados de una organización.
Un atacante puede simplemente abrir un problema de apariencia normal en un repositorio público sin robar credenciales ni obtener acceso a su organización. Si la organización ha otorgado a los agentes acceso de lectura a todo el repositorio, incluidos los repositorios privados, este problema podría provocar que se incorpore contenido privado a los comentarios públicos.
Noma llama a esta técnica GitLost. El objetivo son GitHub Agentic Workflows, una característica que GitHub lanzó en febrero y que actualmente se encuentra en versión preliminar pública. En lugar de escribir scripts de automatización, escriba instrucciones para el agente de IA en inglés sencillo en archivos Markdown. Los agentes leen problemas y solicitan solicitudes, ejecutan herramientas y responden por su cuenta.
Puede utilizar GitHub Copilot, Claude de Anthropic, Google Gemini u OpenAI Codex. Los flujos de trabajo son de solo lectura de forma predeterminada, pero las organizaciones pueden pasar tokens a flujos de trabajo con acceso de lectura en todo el repositorio, dándoles contexto en todos los repositorios, incluidos los privados.
Ese permiso es una configuración a la que GitLost se opone.
Cómo funciona el truco
Esta debilidad es bien conocida y es una inyección inmediata e indirecta. Un agente de IA no puede distinguir de manera confiable entre las instrucciones del propietario y las instrucciones ocultas en el contenido que lee. Por lo tanto, si un atacante escribe estas instrucciones en el problema, el agente puede simplemente seguirlas.
En la prueba de concepto de Noma, el problema malicioso se disfrazó como una solicitud rutinaria de un vicepresidente de ventas después de una reunión con un cliente. El flujo de trabajo de visitas se configuró para activarse cuando se asignaba un problema, leer el problema y responder con un comentario. También tenía acceso de lectura a los otros repositorios de la organización.
Una vez que se asignó un problema mediante la automatización de rutina, el agente recuperó el archivo README en el repositorio privado y lo pegó en los comentarios públicos sobre el problema.
GitHub ha construido barreras de seguridad para evitar esto. La compañía advierte en su documentación que «los agentes de IA pueden ser manipulados mediante inyección rápida, contenido de repositorio malicioso o herramientas comprometidas», y el producto se entrega con sandboxing, tokens predeterminados de solo lectura, limpieza de entradas y un paso de detección de amenazas que escanea la salida sugerida por el agente antes de publicarla.
Norma informó que cambiar una palabra fue suficiente para superar la prueba. Al anteponer la instrucción maliciosa con «además», el modelo la trató como una tarea posterior en lugar de rechazarla, y las barreras de seguridad le permitieron pasar.
¿Por qué es esto diferente?
Lo que pasa con GitLost es que le da al atacante control sobre lo que hace. «Los ejemplos anteriores de inyección rápida tenían que ver principalmente con la manipulación de lo que decía un agente», dijo a The Hacker News Sasi Levi, líder de investigación de seguridad de Noma Security. «GitLost trata de manipular lo que hacen los agentes con sus permisos».
Dice que el agente aquí no es una ventana de chat, sino un atacante autenticado que reside dentro de la infraestructura adyacente a CI/CD de la organización y tiene acceso de lectura a través de repositorios que son invisibles para el atacante. Sin acceso a servidores, sin necesidad de robar credenciales, sin acceso de escritura a nada privado. El atacante sólo necesita plantear una cuestión pública.
Esta configuración se ajusta a lo que el desarrollador Simon Willison ha denominado la «trifecta letal», un término también utilizado por Levi. Es decir, un agente que tiene acceso a datos privados y a los medios para ingerir contenido externo que no es de confianza y transmitir datos. La combinación de los tres crea una ruta de fuga.
Este no es el tipo de error que se resuelve con un parche. Como señala Levi, esta es una consecuencia estructural de darle al agente de IA credenciales válidas y al mismo tiempo obligarlo a leer texto al que puede acceder un atacante.
¿Por qué sucede esto una y otra vez?
GitLost es el último de una serie de ataques similares, y THN ha informado de varios en los últimos meses. Una falla en Claude Code GitHub Action de Anthropic permite que un solo problema malicioso permita a un agente filtrar secretos y quitar el acceso de escritura a un repositorio.
RoguePilot de Orca Security utilizó un mensaje oculto en un problema de GitHub para filtrar el token privilegiado de un repositorio a Copilot. Las versiones del agente de GitHub en este número se remontan al menos a mayo de 2025. En ese momento, Invariant Labs indicó que un problema divulgado públicamente podría permitir que los agentes conectados a los servidores MCP de GitHub lean repositorios privados y los expongan mediante solicitudes de extracción. Los investigadores llamaron a esto «arquitectónico» y no había ningún parche del lado del servidor para cerrarlo.
Una investigación entre proveedores denominada Comment and Control engañó a los agentes de Claude Code, Gemini CLI y GitHub Copilot para que divulgaran sus propias claves API a través del texto de los problemas y las solicitudes de extracción, evitando las defensas de tiempo de ejecución agregadas por GitHub en el camino.
que hacer ahora
Noma publicó GitLost en GitHub y puso los resultados a disposición del público con el conocimiento de la Compañía. La publicación está limitada a organizaciones que permiten vistas previas, conectan agentes para leer entradas públicas que no son de confianza mientras conservan el acceso de lectura a repositorios privados y pueden publicar públicamente.
Lo que un atacante puede extraer depende de lo que el token del agente puede reconocer, desde código fuente propietario hasta claves internas, documentos de diseño o secretos de CI/CD. Como dice Levi, lo más importante es el alcance. Los tokens de agente asignados a un único repositorio para su clasificación son convenientemente «mucho menos riesgosos que uno emitido con acceso de lectura amplio para toda la organización».
En realidad, ese acceso entre repositorios proviene de un token de acceso personal configurado por su organización, por lo que limita el alcance del token al repositorio que prioriza en su flujo de trabajo, en lugar de a toda su organización. Las escrituras solo fluyen a través de salidas seguras declaradas. Por lo tanto, limite lo que los flujos de trabajo de publicación pueden publicar, ya que los comentarios que generan son un canal de salida. Restrinja el contenido de los autores sobre el que actúa el agente y controle el resultado detrás de la 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 de Noma es un recordatorio de que el filtro es un respaldo, no un perímetro.
GitHub, al igual que otros proveedores, había construido barreras de seguridad para protegerse exactamente contra este tipo de ataques y pudieron sortearlas cambiando solo una palabra. Los propios investigadores y proveedores continúan presentando resultados basados en «limitaciones arquitectónicas», señala Levi, razón por la cual las etiquetas están pegadas. Los lenguajes naturales no tienen una línea clara entre datos e instrucciones como la tienen en SQL. Por lo tanto, en lugar de filtrar las inyecciones, la corrección se basa en la arquitectura y se centra en el aislamiento, las credenciales de alcance y las revisiones graduales.
Hasta que exista ese límite, los agentes que pueden leer datos privados, ingerir información que no es de confianza y publicarla públicamente son una representación inteligente de un problema que está a un paso de la filtración.
Source link
