Ing. Calogero Bono
O projeto Git lançou a versão 2.56.1 para corrigir seis vulnerabilidades de segurança. Uma delas permite executar código de terceiros ao clonar de forma recursiva um repositório malicioso. As outras envolvem gravações em arquivos não previstos e danos à memória durante merges e patches binários. Isso importa porque o Git está presente em editores, ferramentas de automação e servidores de muitas empresas, e precisa ser atualizado em todos esses lugares.
Alguns termos, antes de entrarmos nos fatos. Clone recursivo é a cópia de um repositório junto com os seus submódulos. Um submódulo é um repositório dentro de outro repositório. Os hooks são programas que o Git executa em momentos específicos. O path traversal usa caminhos com componentes especiais para sair da pasta permitida. O CVE é o código que identifica uma vulnerabilidade pública.
O que o projeto Git lançou?
Segundo o blog do GitHub, as correções estão na versão 2.56.1. Também existem backports para as séries 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 e 2.50.2.
O GitHub recomenda migrar para a 2.56.1 ou para a versão corrigida da sua série, e atualizar também os aplicativos que incluem uma cópia do Git. Quem leu o nosso percurso sobre Git para desenvolvedores sabe o quanto a ferramenta está presente no dia a dia.
Como se chega a executar código com um clone recursivo?
O defeito está catalogado como CVE-2026-111760. É um truncamento de inteiro no tratamento do índice. Um caminho muito longo passa pela verificação do Git, mas é depois gravado no disco com um nome mais curto, que um invasor pode fazer virar .git.
Assim, o arquivo .git de um submódulo é substituído por um link simbólico apontando para uma pasta com hooks ou configurações hostis. Como explica o The Hacker News, o Git se recusa a substituir uma pasta .git por um link simbólico, mas em um submódulo recém-clonado o .git é um arquivo. Quando o Git usa essa pasta, o código do invasor pode ser executado.
A correção descarta os caminhos excessivamente longos antes que o comprimento seja truncado.
Quais são as outras cinco vulnerabilidades?
- CVE-2026-113408. Ao clonar um repositório vazio com o protocolo v2, um servidor malicioso pode indicar um nome com path traversal. Com o backend de referências em arquivo, uma atualização posterior pode gravar fora da pasta prevista.
- CVE-2026-114467. Uma tag com mais de duas assinaturas GPG, se unida por merge, corrompe a pilha e pode causar uma interrupção do serviço.
- CVE-2026-114469. Um patch binário pequeno que se expande muito contorna o limite de cerca de 1 GiB e faz o Git travar.
- CVE-2026-105437. Um merge muito grande, com muitos conflitos e um atributo conflict-marker-size alto, corrompe a memória heap.
- CVE-2026-114466. Três funções do fast-import podem ler arquivos arbitrários ou criá-los e acrescentar dados neles.
No último caso, o Git agora recusa essas funções em fluxos de entrada, a menos que se use a opção --allow-unsafe-features, que deve ser usada apenas se você confiar no programa que gera o fluxo.
Quem corre mais risco, e o que o GitHub já atualizou?
Os servidores que fazem merge em nome dos usuários estão mais expostos. O GitLab, que atribuiu a CVE-2026-105437, aponta o git merge-tree como alvo provável, porque um servidor pode usá-lo para verificar se uma merge request pode ser integrada. O atributo é definido em um arquivo .gitattributes do repositório, então quem pode abrir uma solicitação poderia acionar o defeito.
O GitHub afirma ter corrigido o github.com e o GitHub Enterprise Cloud. Para o Enterprise Server são necessárias as versões 3.19.15, 3.20.11, 3.21.9 ou 3.22.4. O GitHub Desktop, o aplicativo Copilot, o Codespaces e o Actions receberão o Git corrigido.
Limites que você precisa conhecer
As fontes não relatam exploits ativos nem um nível de gravidade para cada CVE. Não sabemos se alguém já explorou essas falhas. Segundo o The Hacker News, na terça-feira às 19h09 UTC o Git for Windows ainda não tinha uma versão baseada na 2.56.1, então os prazos para essa plataforma podem mudar. Também não há prazos informados para GitHub Desktop, Copilot, Codespaces e Actions.
O que muda para quem trabalha com tecnologia
O primeiro passo é mapear onde o Git está rodando. Não só no seu computador, mas nos programas que incluem uma cópia dele, nos sistemas de integração contínua e nos serviços que processam repositórios de outras pessoas. Quem administra servidores com repositórios de terceiros precisa atualizar também as automações. Se você não puder atualizar agora, o workaround do GitLab é adicionar conflict-marker-size=7 ao arquivo info/attributes de cada repositório, ou desativar essas verificações em repositórios não confiáveis. Quem usa uma hospedagem com atualizações de segurança gerenciadas delega parte desse trabalho.
Nossa opinião
São seis vulnerabilidades, mas a mensagem é uma só. O Git deve ser tratado como software que processa entradas não confiáveis, e não como uma simples ferramenta local. Clonamos, fazemos merge e aplicamos patches de fontes externas sem pensar muito, e as automações fazem isso no nosso lugar. O risco mais concreto está nas cópias do Git escondidas dentro de outros programas, que ninguém atualiza até lembrar que existem. As precauções listadas pelo GitHub servem como paliativo, mas continuam sendo paliativos. Sobre ferramentas que usam o Git de forma intensiva, escrevemos sobre o GitHub Rubicon, onde o tema das entradas não confiáveis pesa ainda mais.
Perguntas frequentes
Qual versão do Git devo instalar?
Instale a 2.56.1 ou a versão corrigida da sua série, ou seja, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ou 2.50.2. Atualize também os aplicativos que incluem uma cópia própria do Git.
Basta não clonar repositórios desconhecidos?
Ajuda, mas não basta. O GitHub recomenda clonar apenas de servidores confiáveis e evitar clones recursivos, merges e patches binários de fontes não confiáveis, ressaltando que essas precauções não substituem as atualizações.
Qual é a vulnerabilidade mais grave?
As fontes não trazem uma classificação. A que permite executar código durante um clone recursivo é a CVE-2026-111760, e é nela que se concentra a cobertura.
O Git for Windows já está atualizado?
Ainda não, segundo a última verificação do The Hacker News. Na terça-feira às 19h09 UTC não havia uma versão baseada na 2.56.1 entre as tags de lançamento.
Os usuários do GitHub precisam fazer algo?
Depende. O GitHub já corrigiu o github.com e as versões Enterprise Cloud. Quem usa o Enterprise Server deve migrar para uma das versões indicadas, e quem usa ferramentas locais deve atualizar o Git.
As atualizações do Git para acompanhar nos próximos dias
A correção existe, mas a distribuição está fragmentada. Vale acompanhar quem ainda não lançou a sua versão.
- Verifique quando o Git for Windows publicar uma build baseada na 2.56.1 e atualize imediatamente.
- Acompanhe a data das versões corrigidas do GitHub Desktop, do Copilot, do Codespaces e do Actions.
- Se você administra um servidor de hospedagem de código, avalie o workaround do GitLab até poder atualizar.
