Uma falha no Git pode permitir que um repositório malicioso execute o código de um invasor em um computador que o clone recursivamente, junto com seus submódulos. O projeto Git corrigiu o problema nesta semana na versão 2.56.1, com correções correspondentes para as séries 2.50 a 2.55 nas versões 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 e 2.55.1.
A falha, catalogada como CVE-2026-111760 (sigla de Common Vulnerabilities and Exposures, ou Vulnerabilidades e Exposições Comuns, sistema de identificação de vulnerabilidades), é um truncamento de inteiro na forma como o Git lida com seu índice. Um caminho extremamente longo em um repositório pode passar pela verificação de segurança do Git, mas o Git então o grava no disco com um nome mais curto, que um invasor pode definir como .git.
Isso permite que um invasor substitua o arquivo .git de um submódulo por um link simbólico apontando para uma pasta que contém hooks ou configurações maliciosas. Hooks são programas que o Git executa em momentos determinados. Assim, quando o Git usa essa pasta, o código do invasor pode ser executado.
Os submódulos são relevantes aqui porque o Git recusa substituir uma pasta .git por um link simbólico, mas, em um submódulo recém-clonado, .git é um arquivo.
As versões corrigidas, listadas no anúncio de lançamento do projeto Git, recusam caminhos extremamente longos antes que seu tamanho possa ser encurtado.
O GitHub, que distribui o Git em suas próprias ferramentas, explicou as correções em uma análise detalhada. A empresa recomenda instalar uma versão corrigida por meio do sistema operacional ou de um distribuidor do Git e atualizar qualquer aplicativo que tenha sua própria cópia do Git.
A empresa já aplicou as correções ao github.com e ao GitHub Enterprise Cloud. Para o GitHub Enterprise Server, elas estão nas versões 3.19.15, 3.20.11, 3.21.9 e 3.22.4.
Versões corrigidas do GitHub Desktop e do aplicativo GitHub Copilot estão sendo preparadas. GitHub Codespaces e GitHub Actions também receberão a versão corrigida do Git.
O Git para Windows ainda não havia publicado uma versão baseada no Git 2.56.1 até a terça-feira, às 19:09 UTC (Tempo Universal Coordenado), segundo uma verificação de suas tags de lançamento feita pelo The Hacker News.
Até que uma versão corrigida seja instalada, o GitHub sugere os seguintes passos, que não substituem as correções:
- Clone apenas de servidores em que você confia.
- Não clone recursivamente repositórios em que você não confia.
- Não faça merge de conteúdos ou tags em que você não confia.
- Não processe patches binários nem fluxos de fast-import de fontes em que você não confia.
As versões do Git também corrigem outras cinco falhas:
- CVE-2026-113408: Quando alguém clona um repositório vazio pelo protocolo Git v2, um servidor malicioso pode enviar um nome de branch que contém travessia de caminho. Com o backend de referências files, uma atualização posterior nesse branch pode gravar arquivos fora da pasta de referências do Git.
- CVE-2026-114467: Fazer merge de uma tag com mais de duas assinaturas GPG (GNU Privacy Guard) corrompe a memória de pilha do Git e pode causar negação de serviço. Serviços de hospedagem que executam esses merges para usuários também podem ser afetados.
- CVE-2026-114469: Um patch binário que se expande para um tamanho muito grande pode ultrapassar o limite de tamanho de patch do Git, de cerca de 1 GiB (gibibyte), e fazer o Git travar com uma leitura fora dos limites.
- CVE-2026-105437: Um merge muito grande, com muitos conflitos e um atributo conflict-marker-size de tamanho elevado, pode fazer o Git escrever além do fim de um buffer pequeno demais, corrompendo a memória heap.
- CVE-2026-114466: Três recursos do git fast-import, rewrite-submodules-from, rewrite-submodules-to e export-pack-edges, podiam ser usados para ler arquivos arbitrários ou criar arquivos e adicionar dados a eles. Agora o Git rejeita esses recursos em um fluxo de entrada, a menos que --allow-unsafe-features esteja definido.
O GitLab, que atribuiu o CVE-2026-105437, afirmou que servidores de hospedagem de código têm mais chances de ser alvo por meio do git merge-tree. Um servidor pode executar esse comando para verificar se um pull ou merge request pode ser integrado.
O atributo conflict-marker-size pode ser definido em um arquivo .gitattributes confirmado em um repositório. Se um servidor ler atributos do repositório, qualquer usuário que possa enviar branches e abrir um pull ou merge request pode acionar a falha.
Como solução provisória, servidores que ainda não podem atualizar podem adicionar conflict-marker-size=7 ao arquivo info/attributes de cada repositório, ou desativar essas verificações de merge para repositórios não confiáveis.
