Vulnerabilidade descoberta pela Wiz dava acesso a milhões de repositórios privados e afeta 88% das instâncias do GitHub Enterprise Server.
Pesquisadores da empresa de segurança Wiz identificaram uma falha crítica na infraestrutura do GitHub, permitindo que qualquer usuário autenticado executasse comandos arbitrários nos servidores da plataforma.
Essa vulnerabilidade, registrada como CVE-2026-3854, afetou tanto o GitHub.com quanto o GitHub Enterprise Server, e foi explorada utilizando apenas um cliente git padrão e um único comando. A descoberta foi potencializada por inteligência artificial, um marco na identificação de falhas desse tipo.
O GitHub solucionou o problema em menos de seis horas após ser notificado. No entanto, para o Enterprise Server, patches foram disponibilizados, mas 88% das instâncias continuavam vulneráveis na hora da divulgação.
Como funciona o pipeline interno do GitHub
Para entender a falha, é necessário compreender o processo de um git push. O comando passa por uma sequência de serviços internos antes de ser aceito pela plataforma.
O primeiro serviço, chamado babeld, atua como um proxy que recebe a conexão do usuário e encaminha a autenticação para o gitauth, o qual valida as credenciais e define as políticas de segurança da sessão, como limites de tamanho de arquivo e regras para nomes de branches.
Essas informações são então organizadas em um cabeçalho interno chamado X-Stat e enviadas para o próximo serviço.
O X-Stat utiliza 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 as próximas etapas. O ponto crítico está nas regras de parsing, que seguem a lógica de “último valor prevalece”.
Se uma mesma chave aparece mais de uma vez no cabeçalho, o valor mais recente sobrescreve o anterior.
A brecha estava na falta de sanitização
O 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 qualquer remoção ou escaping do caractere ponto e vírgula.
Esse cenário permitiu que um atacante incluísse 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ções, inserindo campos adicionais no cabeçalho. Com a lógica de “último vence”, o campo injetado sobrescrevia o original.
De injeção de campo para execução de código
Os pesquisadores foram além da desativação de políticas. Ao analisar o binário do hook de pré-recebimento, que valida um push antes de aceitá-lo, descobriram que ele possui dois caminhos de execução distintos.
O caminho de produção executa hooks em um ambiente isolado, enquanto o outro as executa diretamente, com acesso completo ao sistema de arquivos. A escolha entre os dois é determinada pelo campo rails_env do X-Stat, que pode ser injetado com a mesma técnica.
A exploração completa envolve três injeções. Primeiro, o campo rails_env é modificado para um valor não-produtivo, escapando da sandbox. Em seguida, o campo custom_hooks_dir é alterado para definir onde o binário busca scripts de hook.
Por último, o campo repo_pre_receive_hooks é injetado com uma definição que utiliza path traversal, permitindo apontar para um binário arbitrário no sistema. Esse binário é executado como o usuário do serviço git, levando a um acesso amplo ao servidor.
O mesmo ataque funcionou no GitHub.com
Os pesquisadores testaram a exploração no GitHub.com e notaram que, inicialmente, os hooks personalizados não eram executados. Após investigar, descobriram um campo no X-Stat que determina se o servidor opera em modo enterprise.
No Enterprise Server, esse campo é verdadeiro por padrão. No GitHub.com, é falso, desativando o uso de hooks personalizados.
O campo também era injetável. Com uma injeção adicional, a cadeia completa de exploração funcionou no GitHub.com. Os pesquisadores conseguiram executar comandos nos servidores de armazenamento compartilhado da plataforma como o usuário git, que, por natureza, acessa todos os repositórios hospedados naquele nó.
A equipe confirmou que os nós comprometidos hospedavam milhões de repositórios de usuários e organizações variados. Embora não tenham acessado o conteúdo de repositórios de terceiros, validaram que as permissões do usuário git permitiriam esse acesso.
O papel da IA na descoberta
A Wiz utilizou ferramentas de engenharia reversa potencializadas por inteligência artificial, especificamente o IDA MCP, para analisar os binários do GitHub e reestruturar os protocolos internos.
Os pesquisadores afirmaram que tal análise manual seria inviável dentro de um tempo razoável. A descoberta sinaliza uma tendência crescente de encontrar vulnerabilidades em sistemas complexos usando IA.
Acompanhe o TecMania nas redes sociais. Para mais atualizações de segurança e tecnologia, inscreva-se em nossa newsletter e canal no YouTube.