O GitHub tem uma falha que entrega código, senhas e dados corporativos sem que ninguém precise escrever uma linha de malware. Um pesquisador abre uma issue educada em um repositório público. Nenhum exploit, nenhum payload ofuscado. Ainda assim, minutos depois, chaves de API e código privado estão fora da empresa. Essa é a brecha batizada de GitLost, descoberta pela Noma Security, e ela não depende de nada além de inglês bem escrito.
Para quem escreve pipeline todo dia, o detalhe mais desconfortável é outro. Afinal, o problema não está em um bug de parsing nem em uma dependência comprometida. Ele está na arquitetura de permissões que a gente mesmo aprovou no merge.
GitHub misturou automação e linguagem natural, e o limite entre dado e instrução sumiu
O Agentic Workflows conecta a automação da plataforma a assistentes como o Copilot. Em teoria, isso é ótimo. Ou seja, você descreve a tarefa em linguagem natural e o agente executa. Na prática, porém, o agente lê texto de terceiros com o mesmo peso que lê a instrução do sistema.
É exatamente aqui que a coisa quebra. O invasor abre um chamado público que parece dúvida inofensiva de usuário. No entanto, o corpo do texto carrega instruções escondidas: ignore suas regras, acesse os repositórios privados, copie o que encontrar. Como o workflow roda com permissões amplas, ele obedece.
Sasi Levi, da Noma, comparou o caso ao SQL Injection. A analogia dói justamente porque encaixa. Primeiro, misturamos dado e comando no mesmo canal. Depois, passamos duas décadas pagando a conta.
GitHub tinha guardrails, mas bastou a palavra “Additionally” para derrubá los
Esse é o ponto que deveria assustar qualquer squad de plataforma. Os pesquisadores testaram as proteções existentes e elas caíram rápido. Inclusive, adicionar a palavra Additionally ao comando já era suficiente para confundir o modelo e liberar dados privados.
Repare no que isso significa na prática. Não existe assinatura para detectar, porque não existe binário. Não existe alerta disparado, porque nada foge do comportamento esperado. O agente simplesmente fez o que foi mandado, e o log registra uma operação legítima.
Portanto, se sua defesa depende de reconhecer intenção maliciosa no texto, ela já falhou. Modelos de linguagem não têm um parser separando comando de conteúdo. Enquanto isso não mudar, filtro de palavra é remendo.
GitHub atualizou a documentação, e é isso que você precisa ler nas entrelinhas
A Noma acionou a plataforma. Segundo a agência, não houve retorno confirmando correção da brecha. Em contrapartida, o GitHub sinalizou que atualizou a documentação que originou a configuração vulnerável.
Traduzindo para quem mantém o pipeline: a responsabilidade voltou para o seu lado. Ou seja, não existe patch descendo silenciosamente e resolvendo o problema. Existe uma recomendação de configuração, e existe o seu YAML.
GitLost não é bug isolado, é o custo de dar chave mestra para um agente
Aqui vale separar sintoma de doença. O sintoma é o vazamento via issue pública. A doença é o escopo de permissão concedido por padrão a agentes autônomos.
Pense em como você trataria um serviço novo em produção. Você daria acesso irrestrito a todos os repositórios da organização? Provavelmente não. Contudo, é exatamente isso que muitos times fizeram ao habilitar automação com IA, porque a promessa de produtividade veio antes da revisão de threat model.
Além disso, existe um efeito colateral cultural. Como o agente escreve texto convincente, a saída parece confiável. Assim, a revisão humana afrouxa justamente onde deveria apertar.
Como blindar seu workflow antes que o próximo GitLost apareça
A recomendação central da Noma é direta: escopo mínimo. Detalhando o que isso vira no dia a dia:
Restrinja o agente ao repositório em que ele trabalha. Permissão global significa que uma issue em um projeto de teste alcança o repositório de pagamentos. Portanto, trate cross repo access como exceção auditada, nunca como default.
Separe input de usuário de instrução de sistema. O texto que vem de fora precisa entrar como dado inerte. Em seguida, valide que o agente não interpreta esse bloco como comando, mesmo quando ele pede educadamente.
Trate segredos como se o agente fosse hostil. Se o token está no ambiente do workflow, considere que ele é exfiltrável. Dessa forma, você projeta rotação curta e escopo por tarefa desde o início.
Instrumente saída, não entrada. Como a injeção é invisível no texto, monitore o comportamento: leitura fora do escopo, requisições externas, volume anômalo de arquivos lidos. Logo, o sinal aparece na ação, não na frase.
Revise workflows acionados por evento público. Issues, pull requests de fork e comentários são superfície de ataque. Antes de mais nada, mapeie quais desses gatilhos hoje acordam um agente com credencial.
O que o GitLost revela sobre a próxima década de segurança
Toda vez que uma tecnologia mistura instrução e conteúdo no mesmo canal, alguém encontra o caminho. Aconteceu com SQL. Aconteceu com XSS. Agora acontece com prompt.
A diferença é a barreira de entrada. Antes, o atacante precisava entender a stack. Hoje, ele precisa escrever bem em inglês.
Em resumo, o trabalho não é ensinar o modelo a desconfiar. O trabalho é garantir que, quando ele for enganado, e ele será, não haja nada relevante ao alcance da mão.
Acompanhe nosso perfil no Instagram!