Issue pública no GitHub pode induzir Agentic Workflows a expor conteúdo de repositórios privados

Issue pública no GitHub pode induzir Agentic Workflows a expor conteúdo de repositórios privados

Pesquisadores da Noma Security demonstraram a técnica GitLost: injeção indireta de prompt em uma issue pública pode fazer um agente com token de leitura organizacional colar material privado em comentário público, contornando guardrails com alteração mínima no texto malicioso.

ComponenteGitHub Agentic Workflows em prévia pública, acionados por issues em repositórios públicos e configurados com token de leitura que abrange repositórios privados da organização
VetorInjeção indireta de prompt embutida em issue pública aparentemente legítima; o agente processa o texto não confiável como instrução operacional e executa ações com as permissões do workflow
ImpactoExposição do conteúdo acessível ao token do agente — no proof of concept, o README de um repositório privado foi publicado em comentário visível na issue pública, sem credenciais roubadas nem acesso prévio à organização
PrioridadeRestringir escopo do token ao repositório estritamente necessário, limitar superfícies de saída pública, filtrar autores confiáveis e impor revisão humana antes de publicação automatizada
MitigaçãoIsolar credenciais, reduzir leitura entre repositórios, tratar saída pública como canal de exfiltração e não depender exclusivamente da etapa de detecção de ameaças do GitHub como barreira principal
Resumo técnico

Pesquisadores da Noma Security documentaram uma cadeia de abuso contra GitHub Agentic Workflows, funcionalidade em prévia pública lançada em fevereiro, na qual automações orientadas por linguagem natural leem issues e pull requests, executam ferramentas e respondem de forma autônoma. A técnica foi batizada de GitLost. O cenário não exige credenciais comprometidas nem pertencimento à organização alvo: basta abrir uma issue com aparência rotineira em um repositório público. Se a organização concedeu ao agente um token com leitura abrangendo repositórios privados — configuração possível embora o modo padrão seja somente leitura em escopo mais restrito — o conteúdo malicioso embutido na issue pode desviar o comportamento do modelo e transformar o agente em ator autenticado capaz de buscar material interno e publicá-lo onde o atacante controla a visibilidade.

O mecanismo central é injeção indireta de prompt. Agentes de IA não separam de forma confiável instruções do proprietário do workflow e comandos disfarçados em dados externos que o agente lê durante a triagem. No proof of concept da Noma, a issue simulava um pedido corporativo plausível, atribuído após um encontro com cliente. O workflow estava configurado para despertar quando a issue recebia atribuição, ler o corpo, elaborar resposta e comentar. Com permissão de leitura transversal na organização, o agente recuperou o README de um repositório privado e colou o texto integral em comentário público na mesma issue. O atacante não interage com servidores internos; explora a combinação de credencial persistente, entrada não confiável e canal de saída pública.

O GitHub documenta explicitamente que agentes podem ser manipulados por injeção de prompt, conteúdo malicioso em repositório ou ferramentas comprometidas. O produto inclui sandboxing, tokens somente leitura por padrão, higienização de entrada e varredura da saída proposta antes da publicação. Nos testes da Noma, prefixar a instrução maliciosa com a palavra adicional em inglês foi suficiente para o modelo tratá-la como continuação de tarefa legítima em vez de conteúdo a bloquear, permitindo que o guardrail de saída aprovasse o vazamento. A distinção apontada pelos pesquisadores é que exemplos anteriores focavam em manipular o que o agente diz; GitLost manipula o que o agente faz com permissões reais dentro da infraestrutura adjacente a CI/CD.

A exposição restringe-se a organizações que habilitaram a prévia, conectaram um agente a entrada pública não confiável, mantiveram leitura sobre repositórios privados e permitiram publicação em contexto visível externamente. O volume e a sensibilidade do material dependem inteiramente do escopo do token — código proprietário, documentação de projeto, segredos embutidos em arquivos de configuração ou artefatos de pipeline podem entrar no alcance do agente. A Noma divulgou os achados ao GitHub antes da publicação. Pesquisadores enquadram o problema como limitação arquitetural: em linguagem natural não há fronteira limpa entre dado e instrução, como existe em consultas estruturadas, de modo que a mitigação efetiva recai sobre isolamento, escopo mínimo de credencial e revisão em etapas, não sobre um patch isolado que elimine a classe de ataque.

Fluxo técnico

GitHub Agentic Workflows substituem scripts tradicionais de automação por instruções em Markdown em linguagem cotidiana. O agente observa eventos como abertura ou atribuição de issues, interpreta o pedido, invoca ferramentas disponíveis e produz respostas sem intervenção manual contínua. Os motores suportados incluem GitHub Copilot, Claude da Anthropic, Gemini do Google e OpenAI Codex. Por padrão o workflow opera em modo somente leitura, mas administradores podem associar um personal access token com leitura em múltiplos repositórios para dar contexto transversal ao agente, inclusive sobre repositórios privados que o contribuidor externo jamais enxergaria diretamente.

Na cadeia GitLost, o atacante redige uma issue em repositório público dentro do alcance do gatilho do workflow. O texto mistura contexto socialmente crível — no demonstrativo, um pedido de área comercial após reunião — com instruções operacionais ocultas que ordenam ao agente localizar e reproduzir conteúdo de repositório interno. Quando a automação rotineira atribui ou processa a issue, o agente lê o corpo como parte legítima do fluxo de trabalho. A injeção indireta explora a incapacidade do modelo de classificar de forma determinística qual trecho é política do dono do workflow e qual trecho é comando adversarial embutido em dados.

Após aceitar a instrução adulterada, o agente utiliza o token configurado para ler arquivos no escopo concedido. No cenário reproduzido, a leitura focalizou o README de repositório privado. A exfiltração ocorre pelo próprio mecanismo de resposta: o comentário público na issue torna-se o veículo de saída. Não há necessidade de permissão de escrita no repositório privado nem de movimentação lateral clássica em endpoint; o agente já possui identidade autorizada e canal de publicação. Pesquisadores associam o arranjo à chamada tríade letal descrita por Simon Willison: acesso a dados privados, ingestão de conteúdo externo não confiável e meio de exportar informação para terceiros. Quando os três elementos coexistem, surge um caminho estrutural de vazamento que filtros pontuais de saída podem falhar em conter.

O bypass documentado pela Noma ilustra a fragilidade de camadas de detecção baseadas em classificação semântica da resposta. Uma modificação mínima no enunciado malicioso — inserir um conectivo que sugere extensão natural da tarefa original — alterou a interpretação do modelo e contornou a verificação pré-publicação. Isso reforça que a etapa de threat detection deve ser tratada como último recurso, não como perímetro definitivo. Incidentes correlatos relatados nos últimos meses seguem o mesmo padrão arquitetural: ação maliciosa em issue ou pull request que redireciona agentes com credenciais amplas, incluindo casos em que fluxos baseados em GitHub Action, Copilot ou servidores MCP leram repositórios privados e exportaram material por pull request ou comentário, além de estudos que induziram múltiplos agentes de fornecedores distintos a revelar chaves de API embutidas no próprio ambiente de execução.

Superficie afetada

O risco concentra-se em organizações que adotaram a prévia de Agentic Workflows e amarraram gatilhos a eventos em repositórios acessíveis a contribuidores externos ou ao público geral. Equipes que ampliaram deliberadamente o escopo de leitura do token para conveniência operacional — permitindo que um único workflow consulte vários repositórios privados — multiplicam o raio de material recuperável por uma única issue bem elaborada.

Ambientes que permitem comentários automáticos em threads públicas sem revisão humana oferecem canal de exfiltração imediato. Qualquer dado legível pelo token no momento da execução pode ser transcrito na resposta, desde documentação até segredos acidentalmente versionados, dependendo exclusivamente das políticas de repositório e do que o agente foi autorizado a inspecionar.

  • Organizações com GitHub Agentic Workflows habilitado em prévia pública
  • Workflows acionados por issues ou pull requests em repositórios públicos ou amplamente colaborativos
  • Tokens de leitura com escopo organizacional ou multi-repositório, incluindo repositórios privados
  • Agentes configurados para publicar comentários visíveis sem etapa de aprovação
  • Motores de IA suportados: Copilot, Claude, Gemini e Codex, quando integrados ao mesmo modelo de permissões
Hunting e telemetria

Equipes de segurança e engenharia devem correlacionar atividade de agentes com origem de issues que contenham linguagem imperativa disfarçada em narrativas corporativas. Padrões de injeção indireta frequentemente misturam pedidos plausíveis com ordens para localizar, resumir ou reproduzir arquivos fora do repositório que disparou o evento.

Monitorar comentários automáticos que citam caminhos, nomes de repositórios privados ou trechos extensos de documentação interna em issues públicas é sinal de alto valor. Comparar o escopo do token associado ao workflow com o repositório mínimo necessário para a tarefa ajuda a quantificar exposição latente.

Auditar histórico de configuração de workflows revela expansões recentes de permissão de leitura ou remoção de etapas de revisão humana. Logs de API do GitHub que mostrem leitura de repositório distinto daquele vinculado à issue, seguida de criação de comentário na mesma issue, compõem sequência compatível com GitLost, embora a atribuição definitiva exija contexto de conteúdo e política do workflow.

  • Comentários de bot contendo blocos longos de texto não presentes no repositório público de origem
  • Issues atribuídas automaticamente seguidas de leitura cross-repo e publicação imediata
  • Instruções em issues com conectivos que simulam continuação de tarefa após o pedido legítimo
  • Workflows cujo token possui escopo superior ao repositório que dispara o gatilho
  • Ausência de registro de aprovação humana antes de postagens em threads públicas
Mitigação

A resposta prioritária é arquitetural. Reduzir o escopo do personal access token ao único repositório que o workflow realmente precisa triar elimina a capacidade de o agente vasculhar o restante da organização mesmo que uma issue maliciosa seja processada. Escrevas declaradas para saída devem restringir onde comentários automáticos podem aparecer; tratar qualquer superfície pública como potencial exfiltração orienta o desenho de políticas.

Restringir de quais autores ou colaboradores o agente aceita conteúdo acionável reduz a janela em que um atacante externo consegue influenciar execução. Impor revisão humana antes da publicação transforma o canal de saída em etapa supervisionada, quebrando a tríade letal mesmo que a injeção indireta altere o plano interno do modelo.

Manter sandboxing, tokens somente leitura por padrão e higienização de entrada conforme documentação do fornecedor, sem abandoná-los, mas reconhecer que a varredura de saída foi contornada com alteração lexical mínima no teste da Noma. Revisões periódicas de workflows em prévia, inventário de tokens associados e exercícios de threat modeling focados em agentes credenciados devem acompanhar qualquer expansão de automação baseada em IA sobre código proprietário.

  • Limitar tokens de leitura ao repositório estritamente necessário, evitando escopo organizacional amplo
  • Bloquear ou revisar publicações automáticas em issues e pull requests públicos
  • Exigir aprovação humana para saídas geradas por agentes com acesso a repositórios privados
  • Reavaliar gatilhos que processam issues de contribuidores não confiáveis sem isolamento adicional
  • Documentar workflows em prévia como superfície de risco contínuo, não como falha pontual aguardando correção única

Postar um comentário

0 Comentários