){kind=link}
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.
smart_display
Nossos vídeos em destaque
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.
Como funciona o pipeline interno do GitHub
Para 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.
)
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çã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 nenhuma remoção ou escaping do caractere ponto e vírgula.
)
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ódigo
Os 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.
)
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.
)
O mesmo ataque funcionou no GitHub.com
Os 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ó.
)
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 descoberta
A 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.