Uma issue pública pode enganar os GitHub Agentic Workflows (fluxos de trabalho agênticos do GitHub) e levá-los a vazar o conteúdo de repositórios privados de uma organização, mostraram pesquisadores da Noma Security.
O atacante só precisa abrir uma issue aparentemente comum em um repositório público, sem credenciais roubadas e sem acesso à organização. Se essa organização concedeu ao agente permissão de leitura sobre todos os seus repositórios — incluindo os privados —, a issue consegue direcioná-lo a colar conteúdo privado em um comentário público.
A Noma batizou a técnica de GitLost. O alvo são os GitHub Agentic Workflows, recurso lançado pelo GitHub em fevereiro e que está em pré-visualização pública. Em vez de escrever scripts de automação, o usuário escreve instruções para um agente de IA (Inteligência Artificial) em inglês simples, dentro de um arquivo Markdown. O agente lê issues e pull requests, executa ferramentas e responde por conta própria.
O agente pode ser alimentado pelo GitHub Copilot, pelo Claude, da Anthropic, pelo Google Gemini ou pelo OpenAI Codex. Os workflows são somente leitura por padrão, mas uma organização pode entregar a ele um token com acesso de leitura a todos os seus repositórios, para dar contexto entre repositórios — incluindo os privados.
Essa concessão é justamente a configuração que o GitLost explora.
Como o truque funciona
A fragilidade é bem conhecida: injeção indireta de prompt. Um agente de IA não consegue distinguir de forma confiável entre instruções vindas do seu proprietário e instruções escondidas no conteúdo que ele lê por acaso. Assim, se um atacante grava essas instruções em uma issue, o agente pode simplesmente obedecê-las.
Na prova de conceito (PoC) da Noma, a issue maliciosa foi disfarçada como um pedido rotineiro de um VP (vice-presidente) de Vendas após uma reunião com cliente. O workflow atingido estava configurado para ser acionado quando uma issue fosse atribuída, ler a issue e responder com um comentário. Ele também tinha acesso de leitura aos outros repositórios da organização.
Assim que uma automação de rotina atribuiu a issue, o agente puxou o README de um repositório privado e colou seu conteúdo em um comentário público na issue.
O GitHub construiu barreiras de proteção para impedir exatamente esse tipo de situação. Em sua própria documentação, a empresa alerta que "agentes de IA podem ser manipulados por injeção de prompt, conteúdo malicioso em repositório ou ferramentas comprometidas", e o produto vem de fábrica com sandboxing (isolamento de execução), tokens somente leitura por padrão, limpeza de entradas e uma etapa de detecção de ameaças que examina a saída proposta pelo agente antes de publicá-la.
A Noma relatou que, em seu teste, bastou mudar uma única palavra para escapar da proteção. Acrescentar a palavra "Additionally" (em inglês) antes da instrução maliciosa fez o modelo tratá-la como uma tarefa complementar, e não como algo a ser recusado — e a barreira de proteção deixou passar.
Por que este caso é diferente?
O que diferencia o GitLost é o que o atacante consegue controlar. "Os exemplos anteriores de injeção de prompt eram, em grande parte, sobre manipular o que um agente dizia", afirmou Sasi Levi, líder de pesquisa de segurança da Noma Security, ao The Hacker News. "O GitLost é sobre manipular o que um agente faz com suas permissões."
Segundo ele, o agente aqui não é uma janela de chat, mas um ator com credenciais dentro da infraestrutura adjacente de CI/CD (Integração e Entrega Contínuas) de uma organização, com acesso de leitura abrangendo repositórios que o atacante não consegue enxergar. Ele não toca em nenhum servidor, não precisa de credenciais roubadas e não exige permissão de escrita sobre nada privado. O atacante só precisa abrir uma issue pública.
O cenário se encaixa no que o desenvolvedor Simon Willison chamou de "tríade letal", e Levi usa o mesmo termo: um agente que consegue acessar dados privados, recebe conteúdo externo não confiável e tem um meio de enviar dados para fora. Combine os três fatores e você tem um caminho de vazamento.
Esse não é o tipo de falha que um patch corrige; como Levi define, é uma consequência estrutural de dar a agentes de IA credenciais permanentes enquanto eles leem textos acessíveis ao atacante.
Por que isso continua acontecendo
O GitLost é o mais recente de uma série de ataques do mesmo tipo, e o The Hacker News noticiou vários deles nos últimos meses. Uma falha no GitHub Action do Claude Code, da Anthropic, permitiu que uma única issue maliciosa empurrasse o agente a vazar segredos e assumir permissões de escrita em um repositório.
O RoguePilot, da Orca Security, usou um prompt escondido em uma issue do GitHub para fazer o Copilot vazar o token privilegiado de um repositório. A versão do problema voltada ao agente do GitHub remonta pelo menos a maio de 2025, quando a Invariant Labs mostrou que uma issue pública poderia levar um agente conectado ao servidor MCP (Protocolo de Contexto de Modelo) do GitHub a ler um repositório privado e vazá-lo por meio de um pull request; os pesquisadores classificaram o problema como arquitetural, sem patch no servidor capaz de corrigi-lo.
Um estudo entre fornecedores chamado Comment and Control (Comentário e Controle) então enganou os agentes Claude Code, Gemini CLI e GitHub Copilot, fazendo-os vazar suas próprias chaves de API (Interface de Programação de Aplicações) por meio de texto em issues e pull requests, driblando as defesas de execução adicionadas pelo GitHub pelo caminho.
O que fazer agora
A Noma divulgou o GitLost ao GitHub e publicou suas descobertas com o conhecimento da empresa. A exposição se limita a organizações que ativaram a pré-visualização e conectaram um agente capaz de ler entradas públicas não confiáveis enquanto mantém acesso de leitura a repositórios privados e consegue publicar em ambiente público.
O que um atacante pode extrair depende do que o token do agente consegue enxergar: de código-fonte proprietário a chaves internas, documentos de design ou segredos de CI/CD. Como resume Levi, o escopo é o que mais importa: um token de agente restrito ao único repositório que ele tria é "muito menos perigoso do que um emitido com acesso de leitura amplo em toda a organização" por questão de conveniência.
Na prática, esse acesso entre repositórios vem de um token de acesso pessoal (PAT) configurado pela organização. Por isso, o recomendado é delimitar o token a apenas o repositório que o workflow tria, e não a toda a organização. As escritas só fluem por saídas declaradamente seguras, então é preciso limitar o que um workflow com face pública pode postar, já que o comentário que ele produz é o canal de exfiltração. Restrinja os autores cujo conteúdo o agente vai processar e coloque a saída do agente atrás de revisão humana.
A etapa de detecção de ameaças do GitHub examina a saída do agente antes da publicação, mas o desvio de uma única palavra obtido pela Noma é um lembrete de que um filtro é uma rede de segurança, e não uma fronteira.
O GitHub, assim como os outros fornecedores, construiu barreiras de proteção exatamente para essa classe de ataque — e bastou trocar uma palavra para contorná-las. Pesquisadores e os próprios fornecedores continuam classificando o resultado como "limitação arquitetural", e o argumento de Levi explica por que o rótulo persiste: em linguagem natural, não existe uma linha clara entre dados e instruções como existe em SQL (Linguagem de Consulta Estruturada). Assim, a solução depende mais da arquitetura — isolamento, credenciais com escopo definido e revisão em etapas — do que de filtrar a injeção.
Até que essa fronteira exista, qualquer agente que lê dados privados, absorve entradas não confiáveis e consegue publicar em ambiente público está a uma issue bem escrita de distância de um vazamento.
