Git corrige seis vulnerabilidades críticas em clone, merge e patches

Em 10 de novembro de 2026, o projeto Git divulgou seis vulnerabilidades de segurança corrigidas na versão 2.56.1, com backports para as séries de manutenção 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2. O anúncio foi publicado pelo GitHub Blog, assinado por Elijah Newren, Staff Software Engineer do GitHub e autor do merge-ort, a estratégia de merge padrão do Git desde a versão 2.34.

O ponto que importa para quem usa Git todo dia: as falhas não exigem nenhuma ação exótica para serem exploradas. Clonar um repositório com submódulos, fazer merge de uma tag, aplicar um patch binário ou rodar um git fast-import recebido de terceiros são operações rotineiras em qualquer pipeline de CI, hospedagem de código ou fluxo de contribuição open source↳Open source71 conteúdosComo o Open Source Está Liberando o Poder da Automação para TodosDev (Back & Front) · out 2025Código aberto: programadores criam software da NASA sem saberDev (Back & Front) · abr 2021N8N: O que é a ferramenta open source que está revolucionando a automação em TI?Dev (Back & Front) · dez 2025Ver tudo em Dev (Back & Front) →.

As seis falhas, uma a uma

A mais grave na prática é a CVE-2026-111760. Ela explora uma truncagem de inteiro na forma como o Git valida caminhos no index: um caminho extremamente longo passa na validação com um nome, mas é gravado com um nome mais curto. Um atacante usa essa diferença para substituir o arquivo .git de um submódulo por um link simbólico apontando para um diretório com hooks maliciosos, que o Git acaba executando durante um clone recursivo.

A CVE-2026-105437 afeta qualquer serviço que faça merge de conteúdo não confiável em nome do usuário, incluindo plataformas de hospedagem. O Git calculava o tamanho do buffer de saída do merge antes de escrever o resultado, e esse cálculo podia sofrer overflow quando o merge envolvia muitos conflitos combinados com um atributo de conflict-marker-size grande, levando a heap corruption.

Já a CVE-2026-114466 mexe em um recurso menos usado no dia a dia, mas presente em scripts de migração e automação: git fast-import. Três funcionalidades (rewrite-submodules-from, rewrite-submodules-to e export-pack-edges) não tinham a restrição que já existia para comandos capazes de acessar arquivos fora do repositório. Agora, elas são rejeitadas por padrão quando vêm de um stream não confiável, a menos que o chamador ative explicitamente --allow-unsafe-features.

O que o GitHub já fez e o que fica com você

O GitHub aplicou as correções em github.com, GitHub Enterprise Cloud e GitHub Enterprise Cloud com residência de dados antes mesmo do anúncio público. Para quem roda GitHub Enterprise Server on-premises, os patches saíram nas versões 3.19.15, 3.20.11, 3.21.9 e 3.22.4, e a recomendação do próprio GitHub é atualizar o quanto antes.

GitHub Codespaces e GitHub Actions também vão receber versões corrigidas do Git, e o GitHub coordenou lançamentos do GitHub Desktop e do app do GitHub Copilot com o binário atualizado. Isso cobre a infraestrutura do GitHub, mas não resolve o Git instalado na sua máquina, no seu runner self-hosted ou embutido em qualquer ferramenta que empacote uma cópia própria do Git.

Em resumo: se você usa Git local, CI próprio ou qualquer aplicação que embuta Git (clientes desktop, ferramentas de deploy, bots de automação), a correção do GitHub não te protege automaticamente. É preciso atualizar cada instalação.

Como atualizar

O caminho recomendado pelo projeto Git é direto:

1. Instalar a versão 2.56.1 ou o patch correspondente à sua série de manutenção (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ou 2.50.2) via sua distribuição Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, Homebrew, instalador oficial do Windows/macOS ou gerenciador de pacotes.
2. Atualizar qualquer aplicação ou serviço que embuta uma cópia própria do Git, como clientes GUI, ferramentas de CI auto-hospedadas ou bots que processam repositórios automaticamente.
3. Revisar scripts de automação que usam git fast-import com dados de origem não confiável, já que o comportamento padrão agora bloqueia os recursos citados na CVE-2026-114466.

Para quem não consegue atualizar de imediato, o próprio aviso do Git lista mitigações paliativas: clonar apenas de servidores confiáveis, evitar clones recursivos de repositórios de origem desconhecida, não fazer merge de conteúdo ou tags não confiáveis, e não processar patches binários ou streams de fast-import vindos de fontes não verificadas. Nenhuma dessas práticas substitui o patch: elas só reduzem a janela de exposição enquanto a atualização não roda.

O que ainda fica em aberto

O anúncio não traz prova de exploração ativa em produção para nenhuma das seis CVEs, e o GitHub não divulgou números sobre quantos clientes ou repositórios estariam expostos antes do patch. Também não há, no texto, cronograma para quando distribuições Linux que empacotam Git em versões mais antigas (fora das séries listadas) vão receber backport próprio além do que o projeto já publicou.

Vale lembrar que operações como recursive clone, merge de tags assinadas e aplicação de patches binários são comuns em pipelines automatizados que processam pull requests de fora, caso típico de projetos open source que aceitam contribuição externa. Para quem mantém esse tipo de infraestrutura, atualizar o Git usado pelos runners de CI deveria vir antes, não depois, da atualização das máquinas de desenvolvimento.

Fonte: The Github Blog