Cómo funciona el ataque

Los investigadores describieron el patrón vulnerable de GitHub Agentic Workflow como aquel que:

• Se activa con eventos issues.assigned (cuando se asigna un issue).
• Lee el título y el cuerpo del issue.
• Publica un comentario usando una herramienta del agente, como add-comment.
• Se ejecuta con acceso de lectura a otros repositorios de la organización, incluidos los repositorios privados.

El ataque se desarrolla en cuatro pasos:

1. El atacante abre un issue de GitHub aparentemente inofensivo en un repositorio público que pertenece a una organización que utiliza el patrón vulnerable de Agentic Workflow.
2. Ocultas en el cuerpo del issue hay instrucciones en lenguaje natural que le ordenan al agente de IA que busque archivos en repositorios privados.
3. Cuando la automatización de GitHub asigna el issue, el flujo de trabajo activado por el evento hace que el agente obtenga datos de los repositorios a los que tiene acceso, incluidos los privados.
4. El agente publica el contenido obtenido como un comentario público en el issue, exponiendo potencialmente los datos a cualquier persona que pueda ver el issue.

La debilidad arquitectónica subyacente

El fallo principal es la incapacidad de mantener un límite de confianza estricto entre las instrucciones del sistema y los datos de usuario no confiables dentro de la ventana de contexto del agente de IA. Como afirmó Sasi Levi, de Noma: "La ventana de contexto del agente es también su superficie de ataque. Cualquier contenido que el agente lea —ya sean issues, pull requests, comentarios o archivos— puede ser utilizado como arma si el agente trata ese contenido como una entrada instructiva."

Los agentes basados en LLM tienen dificultades para distinguir entre datos e instrucciones cuando ambos aparecen en el mismo contexto o en la misma salida de una herramienta. Esto no es simplemente un error de programación convencional, sino un riesgo estructural en los flujos de trabajo de IA agentivos, donde el contenido no confiable puede influir en el comportamiento del agente si el flujo de trabajo no lo aísla o lo restringe.

Los investigadores han clasificado formalmente esta clase de fallo como Agentic Workflow Injection (AWI), identificando dos patrones principales: Prompt-to-Agent (P2A), donde el contenido no confiable llega al límite del prompt del agente, y Prompt-to-Script (P2S), donde la influencia del atacante se propaga a través de las salidas derivadas del modelo hacia scripts posteriores.

La técnica para eludir las protecciones: la palabra "Además"

GitHub había implementado protecciones para evitar la exfiltración de datos, pero los investigadores de Noma informaron que podían eludirse con una técnica sorprendentemente simple. Añadir la palabra "Además" a las instrucciones inyectadas hacía que el modelo reformulara su salida en lugar de rechazar la solicitud, permitiendo que la fuga de datos continuara como si fuera una continuación autorizada de la tarea.

Este enfoque es consistente con investigaciones más amplias sobre inyección de prompts que muestran que frases particulares o texto devuelto por herramientas pueden hacer que los modelos sigan instrucciones maliciosas que no deberían seguir. Esta técnica de evasión refleja patrones observados en incidentes anteriores, como la vulnerabilidad de GitHub MCP descubierta por Invariant Labs, donde un issue malicioso podía secuestrar el agente de un usuario para filtrar datos de repositorios privados.

Mitigaciones recomendadas para las organizaciones

Basándose en los hallazgos de GitLost y en las guías de seguridad más amplias para flujos de trabajo agentivos, las organizaciones afectadas deberían implementar los siguientes controles:

• Adoptar un modelo de confianza cero para las entradas del agente: nunca tratar el contenido controlado por el usuario como una instrucción de entrada confiable, y aislar los datos de usuario no confiables de los prompts centrales del sistema.
• Aplicar permisos estrictos de mínimo privilegio: eliminar el acceso innecesario entre repositorios y restringir la capacidad de los agentes para exponer datos a través de salidas públicas.
• Usar listas de permitidos para las herramientas en lugar de listas bloqueadas, y requerir pasos de aprobación humana antes de que los agentes realicen acciones sensibles, como publicar comentarios visibles externamente o acceder a repositorios sensibles.
• Auditar las integraciones de agentes de IA en los flujos de trabajo de CI/CD y automatización de repositorios, especialmente cuando el contexto de eventos no confiables de GitHub se incorpora a los prompts o a las entradas del agente.
• Aislar lógicamente la entrada de usuario no confiable de las directivas a nivel de sistema, tratando el texto generado por el usuario como datos no confiables en lugar de instrucciones autoritativas.

Las organizaciones también deberían aplicar el principio de mínimo privilegio a los secretos del agente e implementar un monitoreo de seguridad continuo para detectar intentos de inyección de prompts.

Respuesta de GitHub (al 7 de julio)

Según Dark Reading y la cronología de divulgación de Noma Security:

• Noma divulgó responsablemente la falla a GitHub.
• GitHub le comunicó a Noma que actualizó la documentación asociada con el patrón de flujo de trabajo vulnerable, y los investigadores informaron que la configuración vulnerable ya no estaba presente cuando la verificaron por última vez.
• Al 7 de julio, GitHub no había emitido un comunicado público formal ni un CVE para GitLost.
• La vulnerabilidad parece haberse solucionado parcialmente mediante la eliminación o revisión de la documentación y la plantilla de flujo de trabajo que la habilitaban, en lugar de una corrección de seguridad claramente documentada a nivel de plataforma.

El panorama general: un riesgo sistémico

GitLost no es un incidente aislado. Representa una clase creciente de vulnerabilidades en las que los agentes de IA con acceso a datos sensibles están expuestos a contenido de usuario no confiable. Problemas similares han afectado las integraciones de GitHub MCP, los flujos de trabajo de Gemini CLI de Google (la vulnerabilidad TrustIssues) y las GitHub Actions de Claude Code. El denominador común es que los agentes basados en LLM carecen de una capacidad inherente para distinguir entre datos e instrucciones cuando ambos aparecen en la misma ventana de contexto: un desafío arquitectónico fundamental que ningún parche de plataforma individual puede resolver por completo.

Cómo funciona el ataque

Los investigadores describieron el patrón vulnerable de GitHub Agentic Workflow como aquel que:

• Se activa con eventos issues.assigned (cuando se asigna un issue).
• Lee el título y el cuerpo del issue.
• Publica un comentario usando una herramienta del agente, como add-comment.
• Se ejecuta con acceso de lectura a otros repositorios de la organización, incluidos los repositorios privados.

El ataque se desarrolla en cuatro pasos:

1. El atacante abre un issue de GitHub aparentemente inofensivo en un repositorio público que pertenece a una organización que utiliza el patrón vulnerable de Agentic Workflow.
2. Ocultas en el cuerpo del issue hay instrucciones en lenguaje natural que le ordenan al agente de IA que busque archivos en repositorios privados.
3. Cuando la automatización de GitHub asigna el issue, el flujo de trabajo activado por el evento hace que el agente obtenga datos de los repositorios a los que tiene acceso, incluidos los privados.
4. El agente publica el contenido obtenido como un comentario público en el issue, exponiendo potencialmente los datos a cualquier persona que pueda ver el issue.

La debilidad arquitectónica subyacente

El fallo principal es la incapacidad de mantener un límite de confianza estricto entre las instrucciones del sistema y los datos de usuario no confiables dentro de la ventana de contexto del agente de IA. Como afirmó Sasi Levi, de Noma: "La ventana de contexto del agente es también su superficie de ataque. Cualquier contenido que el agente lea —ya sean issues, pull requests, comentarios o archivos— puede ser utilizado como arma si el agente trata ese contenido como una entrada instructiva."

Los agentes basados en LLM tienen dificultades para distinguir entre datos e instrucciones cuando ambos aparecen en el mismo contexto o en la misma salida de una herramienta. Esto no es simplemente un error de programación convencional, sino un riesgo estructural en los flujos de trabajo de IA agentivos, donde el contenido no confiable puede influir en el comportamiento del agente si el flujo de trabajo no lo aísla o lo restringe.

Los investigadores han clasificado formalmente esta clase de fallo como Agentic Workflow Injection (AWI), identificando dos patrones principales: Prompt-to-Agent (P2A), donde el contenido no confiable llega al límite del prompt del agente, y Prompt-to-Script (P2S), donde la influencia del atacante se propaga a través de las salidas derivadas del modelo hacia scripts posteriores.

La técnica para eludir las protecciones: la palabra "Además"

GitHub había implementado protecciones para evitar la exfiltración de datos, pero los investigadores de Noma informaron que podían eludirse con una técnica sorprendentemente simple. Añadir la palabra "Además" a las instrucciones inyectadas hacía que el modelo reformulara su salida en lugar de rechazar la solicitud, permitiendo que la fuga de datos continuara como si fuera una continuación autorizada de la tarea.

Este enfoque es consistente con investigaciones más amplias sobre inyección de prompts que muestran que frases particulares o texto devuelto por herramientas pueden hacer que los modelos sigan instrucciones maliciosas que no deberían seguir. Esta técnica de evasión refleja patrones observados en incidentes anteriores, como la vulnerabilidad de GitHub MCP descubierta por Invariant Labs, donde un issue malicioso podía secuestrar el agente de un usuario para filtrar datos de repositorios privados.

Mitigaciones recomendadas para las organizaciones

Basándose en los hallazgos de GitLost y en las guías de seguridad más amplias para flujos de trabajo agentivos, las organizaciones afectadas deberían implementar los siguientes controles:

• Adoptar un modelo de confianza cero para las entradas del agente: nunca tratar el contenido controlado por el usuario como una instrucción de entrada confiable, y aislar los datos de usuario no confiables de los prompts centrales del sistema.
• Aplicar permisos estrictos de mínimo privilegio: eliminar el acceso innecesario entre repositorios y restringir la capacidad de los agentes para exponer datos a través de salidas públicas.
• Usar listas de permitidos para las herramientas en lugar de listas bloqueadas, y requerir pasos de aprobación humana antes de que los agentes realicen acciones sensibles, como publicar comentarios visibles externamente o acceder a repositorios sensibles.
• Auditar las integraciones de agentes de IA en los flujos de trabajo de CI/CD y automatización de repositorios, especialmente cuando el contexto de eventos no confiables de GitHub se incorpora a los prompts o a las entradas del agente.
• Aislar lógicamente la entrada de usuario no confiable de las directivas a nivel de sistema, tratando el texto generado por el usuario como datos no confiables en lugar de instrucciones autoritativas.

Las organizaciones también deberían aplicar el principio de mínimo privilegio a los secretos del agente e implementar un monitoreo de seguridad continuo para detectar intentos de inyección de prompts.

Respuesta de GitHub (al 7 de julio)

Según Dark Reading y la cronología de divulgación de Noma Security:

• Noma divulgó responsablemente la falla a GitHub.
• GitHub le comunicó a Noma que actualizó la documentación asociada con el patrón de flujo de trabajo vulnerable, y los investigadores informaron que la configuración vulnerable ya no estaba presente cuando la verificaron por última vez.
• Al 7 de julio, GitHub no había emitido un comunicado público formal ni un CVE para GitLost.
• La vulnerabilidad parece haberse solucionado parcialmente mediante la eliminación o revisión de la documentación y la plantilla de flujo de trabajo que la habilitaban, en lugar de una corrección de seguridad claramente documentada a nivel de plataforma.

El panorama general: un riesgo sistémico

GitLost no es un incidente aislado. Representa una clase creciente de vulnerabilidades en las que los agentes de IA con acceso a datos sensibles están expuestos a contenido de usuario no confiable. Problemas similares han afectado las integraciones de GitHub MCP, los flujos de trabajo de Gemini CLI de Google (la vulnerabilidad TrustIssues) y las GitHub Actions de Claude Code. El denominador común es que los agentes basados en LLM carecen de una capacidad inherente para distinguir entre datos e instrucciones cuando ambos aparecen en la misma ventana de contexto: un desafío arquitectónico fundamental que ningún parche de plataforma individual puede resolver por completo.