Git corrige CVE-2026-111760 que permite execução de código em submódulos durante clonagem

Nesta semana, o projeto Git publicou uma correção para uma vulnerabilidade séria (CVE-2026-111760) que permite a um repositório malicioso provocar a execução de código na máquina que o clone de forma recursiva junto com seus submódulos. O problema foi resolvido em Git 2.56.1, e foram publicados adesivos correspondentes para os ramos 2.50 a 2.55. As correcções evitam que as rotas de ficheiros demasiado longas passem por controlos de segurança e depois sejam cortadas ao escrever em disco com um nome que um atacante pode forçar a ser .git, o que abre a porta à substituição do arquivo .git de um submódulo por uma ligação simbólica para uma localização controlada pelo atacante. Depois disso, o Git pode ler hooks ou ficheiros de configuração dessa localização e executar código arbitrário em momentos controlados pelo fluxo normal do Git.

O que aconteceu (fatos confirmados): O projeto Git sabe de uma falha de troncamento inteiro no manejo do índice que permite que uma rota extremamente longa que deve ser bloqueada pelas verificações de segurança, passe e depois seja escrita com um nome mais curto. Essa diferença entre a verificação e a escrita permite que o nome resultante seja exatamente “.git”. Uma vez que o Git tenta diferentemente uma pasta .git e um ficheiro .git dentro de um submódulo recém- clonado, um atacante pode aproveitar esse comportamento para deixar um ficheiro .git que seja na verdade uma ligação simbólica para uma pasta atacante que contenha hooks ou outros ficheiros executáveis. Git executa hooks em pontos específicos (por exemplo, pós-checkout, pré-commit, etc.), pelo que a ativação desses hooks a partir de uma localização controlada pelo atacante é a rota para a execução remota de código. A correção entregue rejeita rotas tão longas antes de existir a possibilidade de que o nome seja truncado e possa se tornar .git. Estas correcções estão disponíveis na nota de lançamento do Git 2.56.1: https://github.com/git/git/releases/tag/v2.56.1.

Como funciona tecnicamente (explicação): a vulnerabilidade é uma condição de truncamento de inteiros na lógica que valida e escreve entradas no índice de Git. Durante uma operação de clonagem recursiva com submódulos, Git realiza verificações de segurança sobre as rotas que recebe do repositório remoto. Se uma rota exceder algum tamanho, deve ser invalidada. No entanto, neste caso, a verificação é feita com um valor que posteriormente se reduz (por truncamento) quando Git decide como criar o arquivo em disco. Um nome longo pode, após truncar-se, coincidir com “.git”. Em submódulos recém-criados, o .git não é uma pasta padrão, mas um ficheiro que indica a localização do objeto do Git; esse ficheiro pode ser substituído por uma ligação simbólica porque o Git não espera uma ligação num submódulo recém- clonado. Se a ligação aponta para uma pasta com o hooks maliciosos ou arquivos de configuração, operações normais do Git posteriores podem executar esse código ou ler configurações que alterem o comportamento do cliente.

A quem afeta e qual é o risco real (confirmado vs estimado): Os equipamentos e serviços que usam versões do Git anteriores às corrigidas e que realizam operações de clonagem recursiva de repositórios de origens não completamente confiáveis. Os usuários de clientes Git empacotados por terceiros aplicativos (IDE, clientes gráficos, copys do Git dentro de apps) estão potencialmente em risco se essas aplicações não atualizarem a cópia integrada. O GitHub aplicou as correções em sua infraestrutura pública e no GitHub Enterprise Cloud, e informou que versões do GitHub Enterprise Server e algumas aplicações do GitHub receberão ou já receberam atualizações; no entanto, os mantenedores do Git para Windows e outras distribuições tardaram em publicar binários baseados em 2.56.1 no momento do anúncio inicial. Isto significa que, até que cada plataforma ou pacote distribuído atualize sua cópia de Git, o risco persiste Para aqueles que não possam ou não querem atualizar.

É importante sublinhar o que não está confirmado publicamente: não há uma referência inequívoca à exploração activa na natureza (não foram apresentadas amostras públicas ou relatórios forenses amplamente verificados no momento do adesivo). Dado o vetor — repositorios que se clonam recursivamente — e a facilidade para incorporar submódulos, o risco de abuso é alto em teoria, especialmente contra desenvolvedores e servidores que automatizam clonados e merges de projetos de terceiros. Serviços que executam merges ou verificações em nome de usuários (por exemplo, verificações em servidores de integração contínua ou alojadores que executam operações sobre código fornecido por usuários) são grupos que, segundo GitLab, podem ser objetivos preferenciais para exploits centrados no comando git merge-tree.

Outras correcções incluídas: Além do CVE-2026-111760, a última rodada de adesivos corrige várias falhas com potencial de corrupção de memória, leitura fora de limites e abuso de funções de importação rápida. Entre eles estão vulnerabilidades que permitem escrita fora da árvore de referências após um clone vazio por protocolo v2, corrupções por etiquetas com múltiplas assinaturas GPG, adesivos binários que excedem o limite e provocam leituras fora de limites, sobreescritas de buffer em merges muito grandes com atributos conflict-marker-size modificados e a possibilidade de ler ou criar arquivos arbitrários através de certas características de git fast-import; estas últimas agora estão bloqueadas, salvo se invoque explicitamente --allow-unsafe-features. Os detalhes técnicos e as mitigações adicionais foram documentados pelo projeto Git e por equipes de alojamento como GitHub e GitLab.

O que o leitor deve fazer agora (ações concretas): Primeiro, verifique a versão do Git nas máquinas que administra executando o Git localmente (por exemplo, com git --version). Se você usa uma versão anterior a 2.56.1 ou as versões alteradas dos ramos 2.50–2.55, atualize quanto antes da fonte oficial ou o gestor de pacotes do seu sistema. Se a sua organização usar instâncias do GitHub Enterprise Server, verifique as notas de versão para as versões alteradas (as versões empresariais que já receberam as correções estão listadas pelo GitHub) e aplique as atualizações de plataforma de acordo com o calendário de manutenção. Além disso, Se usar aplicativos que incluem sua própria cópia do Git (clientes de desktop, IDEs, contêineres ou apps de terceiros), solicite ou verifique com o fornecedor quando incorporarão a versão corrigida e aplique suas atualizações. O GitHub também publica recomendações provisórias: clone apenas de origens que você confie e evite o uso de clonagem recursiva em repositórios não verificados; não misture conteúdo ou etiquetas de fontes não confiáveis; e não processa adesivos binários ou fluxos fast-import de fontes que não sejam de confiança. Para mais detalhes sobre a atualização do Git consulte a documentação oficial: https://docs.github.com/en/get-started/using-git/updating-git. Para entender como operam os hooks que podem ser abusados, a documentação oficial do Git sobre o hooks é útil: https://git-scm.com/docs/githooks.

Como medida adicional para administradores de servidores que ainda não possam atualizar, GitLab e outros sugeriram mitigações temporárias para falhas concretas (por exemplo, fixar conflict-marker-size em info/attributes dos repositórios ou desativar verificações de merge-tree para repos não confiáveis). Estas medidas específicas correspondem a certas vulnerabilidades entre as corrigidas e são aplicáveis em contextos onde a atualização imediata não seja possível.

Resumo: a vulnerabilidade expõe um vetor prático para executar código conteúdo em submódulos maliciosos durante uma clonagem recursiva. A solução oficial já está publicada; a responsabilidade imediata recai em atualizar as cópias de Git distribuídas em sistemas e serviços próprios, e em evitar operações automatizadas sobre repositórios de proveniência duvidosa até que todas as peças do ecossistema (sistemas operacionais, clientes e serviços) incorporem a correção.