Michael JohnsonSe você atualizou o Git no terminal, o trabalho ainda não terminou: aplicativos e ambientes de compilação podem executar uma cópia própria. Em 10 de novembro de 2026, o projeto Git lançou correções para seis vulnerabilidades — desde a execução de código durante a clonagem recursiva até a corrupção de memória em uma mesclagem. Portanto, é preciso verificar cada ambiente que processa repositórios ou seu conteúdo, e não apenas o resultado de git --version no seu shell.
O que mudou na atualização
As correções foram incluídas no Git 2.56.1 e retroportadas para as versões ainda suportadas: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. A atualização corrige seis problemas em diferentes partes do Git — no tratamento de caminhos, links, assinaturas, patches binários, mesclagens e fluxos de importação. A análise das vulnerabilidades e a recomendação de atualização foram publicadas pelo GitHub em 10 de novembro; as notas de lançamento do Git 2.56.1 listam os CVEs corrigidos nesta série.
Na prática, é preciso atualizar o Git usado em três lugares: nos computadores de trabalho, nas automações e dentro de aplicativos que incluem sua própria compilação do Git. Este último ponto é fácil de deixar passar: atualizar o pacote do sistema não altera automaticamente as versões incluídas em cada cliente ou imagem de compilação.
Por que a clonagem recursiva merece atenção
A cadeia de ataque mais evidente começa com a clonagem recursiva de um repositório não confiável. Devido ao truncamento do comprimento do caminho, uma entrada muito longa podia passar pela validação com um nome e depois ser gravada no disco com um nome encurtado. No cenário descrito pelo Git, isso permitia substituir o arquivo .git de um submódulo por um link simbólico para um diretório com configuração ou hooks maliciosos. Em uma operação posterior, o Git poderia executar código definido pelo atacante.
Um detalhe importante para a prática: trata-se de um repositório preparado especificamente para isso e de uma operação correspondente. Equipes que clonam regularmente projetos de fontes externas com o parâmetro --recurse-submodules devem priorizar a atualização de clientes e ambientes automatizados. A correção rejeita caminhos excessivamente longos antes que seu comprimento seja truncado.
Outros pontos em que o Git processa dados não confiáveis
Outro problema ocorre ao clonar um repositório vazio pelo Git protocol v2. O servidor podia enviar uma referência HEAD com um nome de branch contendo componentes de travessia de diretórios; depois, uma operação de atualização do branch podia gravar um arquivo fora do diretório de referências esperado. Nas versões corrigidas, o Git valida esse destino e outros nomes de referências recebidos pelo protocolo.
Vulnerabilidades separadas afetavam operações de mesclagem e patches. Ao processar assinaturas, um array de tamanho fixo comportava no máximo duas; uma mensagem especialmente preparada com mais assinaturas podia provocar uma gravação fora dos limites do array e corromper a memória. Ao aplicar um patch binário, a verificação de tamanho considerava a representação original, embora os dados compactados pudessem se expandir para um volume muito maior. Agora, o Git verifica o tamanho descompactado declarado antes do processamento.
Mesclagens grandes também podiam provocar um estouro no cálculo do buffer necessário e, em seguida, uma gravação além de seus limites. Isso também afeta hospedagens e aplicativos que mesclam conteúdo não confiável. Por fim, três recursos do git fast-import receberam restrições para comandos do fluxo de entrada: rewrite-submodules-from e rewrite-submodules-to podiam ler arquivos arbitrários, enquanto export-pack-edges podia criar arquivos ou acrescentar dados a arquivos existentes. Agora, esses recursos ficam bloqueados, a menos que a flag --allow-unsafe-features seja especificada; ela só deve ser usada com um gerador de fluxo confiável.
Onde procurar cópias separadas do Git
Para quem desenvolve, basta começar fazendo um inventário dos locais que executam o Git. Verifique a versão no terminal e use a ferramenta de atualização integrada das IDEs e dos clientes Git de desktop. Depois, verifique imagens de CI, contêineres, executores e tarefas de servidor que fazem clone ou merge, aplicam patches binários ou executam fast-import. Ter uma versão recente do Git no host não garante que o aplicativo use essa versão.
Nas organizações, também é útil conferir não apenas as imagens de origem, mas os ambientes de trabalho já implantados: um executor permanente ou serviço interno pode ter mantido um binário antigo após a atualização da imagem-base. Para o GitHub Enterprise Server, o GitHub indica as versões corrigidas 3.19.15, 3.20.11, 3.21.9 e 3.22.4. A empresa informou que já implantou as correções no github.com e no GitHub Enterprise Cloud, inclusive nas opções com hospedagem de dados. Os lançamentos do GitHub Desktop e do aplicativo GitHub Copilot com o Git corrigido estão sendo coordenados; versões corrigidas para Codespaces e GitHub Actions também ainda serão disponibilizadas.
Como reduzir o risco antes da atualização
Se não for possível instalar a correção imediatamente, restrinja temporariamente as operações com dados não confiáveis: clone repositórios somente de servidores confiáveis, evite a clonagem recursiva de projetos não verificados, não faça merge de seu conteúdo e não aplique patches binários ou fluxos de fast-import recebidos desses projetos. Essas medidas reduzem a exposição aos cenários vulneráveis específicos, mas não substituem a atualização.
A principal conclusão prática é simples: procure a correção do Git onde o programa realmente o executa. O comando no terminal é apenas um desses pontos; clientes de desenvolvimento, CI e serviços de processamento de repositórios exigem uma verificação separada.
