Pesquisadores da empresa de segurança Wiz descobriram uma vulnerabilidade crítica na infraestrutura interna do GitHub. Ela permitia a qualquer usuário autenticado a capacidade de executar comandos arbitrários nos servidores da plataforma.A falha, registrada como CVE-2026-3854, afetou tanto o GitHub.com quanto o GitHub Enterprise Server e foi explorada usando apenas um cliente git padrão e um único comando. A vulnerabilidade foi encontrada com ajuda de inteligência artificial, o que os pesquisadores apontam como uma mudança significativa na forma como esse tipo de falha é identificado.O GitHub corrigiu o problema no GitHub.com em menos de seis horas após o recebimento do relatório. Para o Enterprise Server, patches foram lançados e o CVE foi publicado, mas 88% das instâncias ainda estavam vulneráveis no momento da divulgação.O GitHub publicou o CVE-2026-3854 em 13 de março de 2026, classificando a falha como de alta severidade no GitHub Enterprise Server. Imagem: Wiz.Como funciona o pipeline interno do GitHubPara entender a falha, é preciso entender o que acontece quando alguém executa um git push. O comando passa por uma cadeia de serviços internos antes de ser aceito pela plataforma.O primeiro serviço, chamado babeld, funciona como um proxy que recebe a conexão do usuário e repassa a autenticação para o gitauth. Esse segundo serviço verifica as credenciais e define as políticas de segurança da sessão, como limites de tamanho de arquivo e regras de nomenclatura de branches.As informações são então empacotadas em um cabeçalho interno chamado X-Stat e enviadas ao próximo serviço.Diagrama da Wiz Research mostra o caminho de um git push pelos serviços internos do GitHub até a validação final de segurança. Imagem: Wiz.O X-Stat usa um formato simples de pares chave=valor separados por ponto e vírgula. Um terceiro serviço, o gitrpcd, lê esse cabeçalho e prepara o ambiente para os processos seguintes. O detalhe crítico está nas regras de parsing, que seguem a lógica de "último valor vence".Se uma mesma chave aparece duas vezes no cabeçalho, o valor mais recente sobrescreve o anterior.A brecha estava na falta de sanitizaçãoO git permite que usuários enviem opções arbitrárias junto com um push usando o parâmetro -o. Essas opções são incorporadas diretamente no cabeçalho X-Stat pelo babeld, sem nenhuma remoção ou escaping do caractere ponto e vírgula.Um único push malicioso comprometia nós de armazenamento compartilhado e dava acesso de leitura e escrita a milhões de repositórios de outros usuários. Imagem: Wiz.Isso criou o problema. Um atacante podia incluir um ponto e vírgula em uma opção de push seguido por um campo de segurança legítimo do X-Stat. O babeld copiava esse valor sem modificação, inserindo campos extras no cabeçalho. Como o gitrpcd usa a lógica de "último vence", o campo injetado sobrescrevia o original.Na prática, isso permitia desabilitar verificações de segurança como o limite de tamanho de arquivos simplesmente enviando um push com a opção correta.De injeção de campo para execução de códigoOs pesquisadores foram além da desativação de políticas. Ao analisar o binário do hook de pré-recebimento, componente responsável por validar um push antes de aceitá-lo, descobriram que ele tem dois caminhos de execução distintos.A falha permitia que um atacante autenticado executasse comandos remotos nos servidores do GitHub sem nenhuma ferramenta especial.O caminho de produção executa hooks em uma sandbox isolada. O outro caminho executa os hooks diretamente, sem isolamento, com acesso completo ao sistema de arquivos. A escolha entre os dois é feita com base no campo rails_env do X-Stat, que era injetável pela mesma técnica.A cadeia de exploração completa envolve três injeções. Primeiro, o campo rails_env é substituído por um valor não-produção para sair da sandbox. Depois, o campo custom_hooks_dir é alterado para controlar o diretório onde o binário busca scripts de hook.Por fim, o campo repo_pre_receive_hooks é injetado com uma definição de hook que usa path traversal, técnica que navega por diretórios usando sequências como ../, para apontar para um binário arbitrário no sistema. Esse binário é então executado como o usuário do serviço git, com acesso amplo ao servidor.A descoberta foi possível graças a ferramentas de engenharia reversa com inteligência artificial, que aceleraram a análise dos binários internos da plataforma.O mesmo ataque funcionou no GitHub.comOs pesquisadores testaram a exploração no GitHub.com e encontraram uma diferença inicial. Os hooks customizados nunca eram executados. Investigando mais, identificaram um campo no X-Stat que controla se o servidor opera em modo enterprise.No Enterprise Server, esse campo é verdadeiro por padrão. No GitHub.com, é falso, o que desativa o caminho dos hooks customizados.O campo também era injetável. Com mais uma injeção, a cadeia completa funcionou no GitHub.com. Os pesquisadores conseguiram executar comandos nos servidores de armazenamento compartilhados da plataforma como o usuário git, que por design tem acesso de leitura a todos os repositórios hospedados naquele nó.O GitHub corrigiu o problema em menos de seis horas após receber o relatório da Wiz e liberou patches para o Enterprise Server.A equipe confirmou que os nós comprometidos hospedavam milhões de repositórios de usuários e organizações diferentes. Eles não acessaram o conteúdo de repositórios de terceiros, mas validaram que as permissões do usuário git permitiriam esse acesso.O papel da IA na descobertaA Wiz usou ferramentas de engenharia reversa aumentadas por IA, especificamente o IDA MCP, para analisar os binários compilados do GitHub e reconstruir os protocolos internos.Segundo os pesquisadores, esse tipo de análise não seria viável manualmente em tempo razoável. A descoberta aponta para uma tendência crescente: vulnerabilidades em sistemas fechados e complexos sendo encontradas com ajuda de IA.Acompanhe o TecMundo nas redes sociais. Para mais notícias de segurança e tecnologia, inscreva-se em nossa newsletter e canal do YouTube.