GitHub corrigiu uma falha cr\u00edtica que permitia invadir reposit\u00f3rios com simples comando. Pesquisadores da Wiz identificaram a vulnerabilidade que afetou tanto o GitHub.com quanto o GitHub Enterprise Server. O problema poderia ser explorado por usu\u00e1rios autenticados, abrindo caminho para execu\u00e7\u00e3o de comandos arbitr\u00e1rios nos servidores.<\/p>\n
A falha, registrada como CVE-2026-3854, foi fechada rapidamente no GitHub.com, com corre\u00e7\u00e3o aplicada em menos de seis horas ap\u00f3s o relato. No Enterprise Server, patches foram disponibilizados, mas, na divulga\u00e7\u00e3o, 88% das inst\u00e2ncias ainda estavam vulner\u00e1veis.<\/p>\n
O defeito foi encontrado durante a an\u00e1lise de um pipeline de push. Em termos simples, o processo do push passa por babeld, gitauth e outros servi\u00e7os, que constroem um cabe\u00e7alho interno chamado X-Stat com pares chave=valor separados por ponto e v\u00edrgula.<\/p>\n
O X-Stat era lido pelo servi\u00e7o gitrpcd, que preparava o ambiente para etapas seguintes. A falha ocorria porque o Babeld aceitava op\u00e7\u00f5es arbitr\u00e1rias via o par\u00e2metro -o e as inseria no cabe\u00e7alho sem sanear o separador ponto e v\u00edrgula.<\/p>\n
Essa inser\u00e7\u00e3o permitia que um atacante explorasse o formato do cabe\u00e7alho, com o \u201c\u00faltimo vence\u201d de parsing, sobrescrevendo valores leg\u00edtimos. A pr\u00e1tica desativava pol\u00edticas de seguran\u00e7a, como limites de tamanho de arquivo, com um push malicioso.<\/p>\n
Ao analisar o hook de pr\u00e9-recebimento, pesquisadores descobriram dois caminhos de execu\u00e7\u00e3o: um com sandbox e outro sem isolamento. A escolha dependia do campo rails_env no X-Stat, que era mut\u00e1vel pela mesma t\u00e9cnica de inje\u00e7\u00e3o.<\/p>\n
O ataque envolvia tr\u00eas passos de inje\u00e7\u00e3o: alterar rails_env para sair da sandbox, mudar custom_hooks_dir para indicar scripts indesejados e injetar repo_pre_receive_hooks com path traversal para acionar um bin\u00e1rio arbitr\u00e1rio.<\/p>\n
O ataque permitia que um usu\u00e1rio autenticado executasse comandos remotos nos servidores do GitHub, com acesso potencial a \u00e1reas cr\u00edticas. Pesquisas mostraram que milh\u00f5es de reposit\u00f3rios poderiam ficar sob controle do invasor sem ferramentas adicionais.<\/p>\n
No GitHub.com, o caminho de hooks customizados n\u00e3o era ativo por padr\u00e3o, o que inicialmente reduzia o risco. No Enterprise Server, por\u00e9m, o modo de opera\u00e7\u00e3o permitia esse caminho com maior facilidade.<\/p>\n
A Wiz utilizou ferramentas de engenharia reversa com suporte de IA para reconstruir os protocolos internos. O uso do IDA MCP acelerou a an\u00e1lise de bin\u00e1rios, apontando para uma tend\u00eancia de vulnerabilidades em sistemas fechados que podem ser identificadas com IA.<\/p>\n
Os pesquisadores destacaram que a abordagem pode facilitar a detec\u00e7\u00e3o de falhas complexas em ambientes de grande escala. A Wiz informou as autoridades t\u00e9cnicas do GitHub, que implementaram patches e orientaram a atualiza\u00e7\u00e3o das inst\u00e2ncias afetadas.<\/p>\n
O GitHub confirmou que o problema foi resolvido no n\u00edvel p\u00fablico rapidamente e que patches chegaram ao Enterprise Server. A orienta\u00e7\u00e3o segue para que usu\u00e1rios e administradores atualizem seus ambientes para evitar explora\u00e7\u00e3o adicional.<\/p>\n
A divulga\u00e7\u00e3o segue relatos da Wiz e confirmam a\u00e7\u00f5es corretivas do GitHub. As informa\u00e7\u00f5es refor\u00e7am a import\u00e2ncia de atualiza\u00e7\u00f5es de seguran\u00e7a cont\u00ednuas em plataformas de c\u00f3digo-fonte hospedado.<\/p>\n","protected":false},"excerpt":{"rendered":"