Uma falha no Git colocou desenvolvedores, administradores de sistemas e equipes de DevOps em alerta após a descoberta de uma vulnerabilidade capaz de permitir a execução arbitrária de código durante a clonagem recursiva de repositórios maliciosos. Identificada como CVE-2026-111760, a brecha explora uma inconsistência no tratamento de caminhos de arquivos e pode permitir que um invasor execute comandos no computador da vítima sem que ela tenha a oportunidade de inspecionar previamente o código malicioso.
O problema faz parte de um pacote de segurança divulgado em 10 de novembro de 2026, que reúne seis vulnerabilidades no sistema de controle de versão. Além da execução de código por meio de submódulos, as correções abrangem problemas de travessia de diretórios, corrupção de memória, leitura fora dos limites e acesso indevido ao sistema de arquivos.
A atualização é particularmente importante porque o Git está presente em praticamente toda a cadeia de desenvolvimento de software, desde estações de trabalho individuais até servidores de integração contínua, plataformas de hospedagem de código e infraestruturas corporativas. Entre as empresas envolvidas na resposta estão GitHub e GitLab, que publicaram informações sobre as vulnerabilidades e medidas de proteção para seus respectivos ambientes.
Falha no Git permite execução de código durante clones recursivos
A vulnerabilidade CVE-2026-111760 é um dos problemas mais preocupantes do pacote. Sua origem está em uma falha de truncamento de inteiro no tratamento de entradas do índice do Git, mecanismo responsável por organizar e controlar os arquivos presentes em um repositório.
O problema acontece quando o Git verifica o tamanho de um caminho extremamente longo. Durante determinadas operações, o comprimento desse caminho pode sofrer truncamento, fazendo com que a validação de segurança considere um nome diferente daquele que efetivamente será utilizado na gravação do arquivo.
Essa inconsistência permite que um caminho aparentemente inofensivo passe pelas verificações de segurança, mas seja posteriormente interpretado de maneira diferente pelo sistema.
O resultado pode ser a substituição do arquivo .git de um submódulo por um link simbólico (symlink) que aponta para outro diretório controlado pelo invasor.
Esse detalhe é importante porque o Git utiliza arquivos .git para identificar e acessar os metadados dos submódulos. Ao conseguir manipular essa referência, um atacante pode direcionar o funcionamento do programa para uma estrutura que contém configurações e hooks maliciosos.
Como o ataque consegue executar código malicioso
O cenário de exploração envolve um repositório preparado especificamente para abusar dessa inconsistência.
Quando um desenvolvedor executa uma clonagem recursiva, utilizando o comando git clone --recurse-submodules, o Git também baixa automaticamente os submódulos associados ao projeto.
É nesse processo que a manipulação pode acontecer. O repositório malicioso utiliza caminhos especialmente construídos para contornar a validação e substituir a referência .git de um submódulo por um link simbólico.
Esse link pode apontar para um diretório contendo configurações maliciosas e hooks do Git controlados pelo atacante.
Os hooks são programas executados automaticamente em determinados momentos do funcionamento do Git. Dependendo do contexto e da operação envolvida, eles podem executar comandos e scripts no ambiente local.
Assim, quando o Git utiliza a estrutura manipulada durante a clonagem, existe a possibilidade de execução de código controlado pelo invasor.
A gravidade aumenta porque o usuário pode ser comprometido durante uma operação aparentemente rotineira, antes mesmo de analisar os arquivos baixados.
O projeto Git corrigiu o problema rejeitando caminhos de entradas do índice excessivamente longos antes que seus comprimentos possam sofrer truncamento.
Atualização do Git 2.56.1 corrige a falha no Git e outras versões
Para resolver os problemas identificados, o projeto Git disponibilizou a versão 2.56.1, acompanhada de correções retroativas para diferentes séries de manutenção.
Os administradores que não utilizam a versão mais recente não precisam necessariamente migrar imediatamente para uma nova série principal. Existem versões corrigidas específicas para as linhas anteriores.
As versões disponibilizadas são:
A recomendação é instalar a versão corrigida correspondente à série utilizada ou migrar para o Git 2.56.1.
Outro ponto importante envolve aplicações que incorporam suas próprias cópias do Git. Atualizar apenas o pacote instalado no sistema operacional pode não ser suficiente quando ferramentas de desenvolvimento, ambientes de automação e aplicativos utilizam versões independentes.
GitHub também atualiza sua infraestrutura e recomendações
O GitHub confirmou que implementou correções para as seis vulnerabilidades em seus serviços, incluindo o GitHub.com, o GitHub Enterprise Cloud e a modalidade Enterprise Cloud com residência de dados.
Para o GitHub Enterprise Server, foram disponibilizadas atualizações específicas nas seguintes versões:
- 3.19.15;
- 3.20.11;
- 3.21.9;
- 3.22.4.
A empresa também informou que está coordenando atualizações do GitHub Desktop e do aplicativo GitHub Copilot, além de preparar versões corrigidas para GitHub Codespaces e GitHub Actions.
Essa movimentação demonstra que a vulnerabilidade não representa apenas um risco para computadores individuais. Plataformas que processam repositórios de terceiros e executam operações automatizadas também precisam garantir que suas instalações estejam protegidas.
Medidas paliativas antes de atualizar o Git
Enquanto a atualização não estiver disponível em todos os ambientes, algumas precauções podem reduzir a exposição.
A primeira recomendação é clonar somente repositórios provenientes de servidores e organizações confiáveis. Projetos desconhecidos devem ser tratados com cautela, especialmente quando exigem o download automático de submódulos.
Outra medida importante é evitar temporariamente a clonagem recursiva de repositórios não confiáveis. Em vez de utilizar diretamente --recurse-submodules, os desenvolvedores podem clonar o repositório principal sem inicializar automaticamente seus submódulos.
Também é recomendável revisar a origem dos submódulos antes de inicializá-los e evitar executar operações automatizadas sobre projetos desconhecidos.
Essas medidas são paliativas. Elas não substituem a instalação das versões corrigidas.
Outras cinco vulnerabilidades corrigidas no pacote de segurança
Embora a execução de código durante clones recursivos seja o destaque, as outras cinco vulnerabilidades também merecem atenção. Elas atingem diferentes componentes internos do Git e podem afetar tanto estações de desenvolvimento quanto plataformas que processam repositórios de terceiros.
CVE-2026-113408: travessia de diretórios por referências HEAD
Essa vulnerabilidade permite que um servidor malicioso anuncie uma referência simbólica HEAD apontando para uma ramificação ainda inexistente, mas contendo componentes de travessia de diretórios.
Durante a clonagem de um repositório vazio utilizando o protocolo Git v2, a ausência de validação adequada poderia permitir que operações posteriores de atualização de referências gravassem arquivos fora do diretório esperado.
A correção adiciona verificações para os destinos anunciados pelo servidor e outros nomes de referências recebidos pelo protocolo.
CVE-2026-114467: corrupção de memória ao remover assinaturas GPG
O problema está relacionado ao tratamento de assinaturas GPG presentes em mensagens de commit.
O Git considerava que uma mensagem teria, no máximo, duas assinaturas. Uma mensagem especialmente preparada com mais assinaturas poderia ultrapassar os limites de um array de tamanho fixo na memória da pilha.
A situação pode provocar corrupção de memória e indisponibilidade do processo. Plataformas que realizam operações de mesclagem automaticamente também precisam considerar esse risco.
CVE-2026-114469: leitura fora dos limites durante aplicação de patches binários
O Git possui uma proteção para rejeitar patches com tamanho superior a aproximadamente 1 GB. Entretanto, a verificação considerava o tamanho do conteúdo recebido, sem levar adequadamente em conta a expansão de dados binários compactados.
Um patch malicioso poderia ultrapassar o limite após a descompactação e provocar uma leitura fora dos limites da memória.
A correção também verifica o tamanho descompactado declarado antes de processar o conteúdo.
CVE-2026-105437: corrupção de heap durante operações de mesclagem
Essa vulnerabilidade recebeu atenção especial do GitLab, que identificou um problema no mecanismo de mesclagem de três vias, conhecido como xdiff.
O problema envolve o atributo conflict-marker-size, utilizado para definir o tamanho dos marcadores apresentados em conflitos de mesclagem.
Um arquivo .gitattributes malicioso pode definir valores extremamente elevados para esse atributo. Quando combinado com uma quantidade suficientemente grande de conflitos, o cálculo do tamanho necessário para armazenar o resultado pode ultrapassar o limite de um inteiro de 32 bits.
O valor sofre uma volta numérica, levando o Git a reservar um buffer menor do que o necessário. Posteriormente, a gravação do resultado ultrapassa os limites da memória alocada, provocando corrupção de heap.
Entre os comandos potencialmente envolvidos estão git merge, git rebase, git cherry-pick e git merge-tree.
O risco é especialmente relevante para plataformas de hospedagem de código que realizam verificações automáticas de mesclagem. O GitLab documentou como um usuário capaz de enviar alterações e abrir uma solicitação de mesclagem pode explorar o problema em determinadas condições, inclusive com possibilidade de evolução para execução de código no contexto do processo Gitaly.
Para ambientes que ainda não conseguem atualizar, uma medida paliativa documentada pelo GitLab consiste em adicionar a seguinte configuração ao arquivo info/attributes de cada repositório:
* conflict-marker-size=7Essa configuração prevalece sobre os atributos definidos dentro do repositório. Outra possibilidade é desativar temporariamente as verificações de mesclagem do lado do servidor para projetos não confiáveis.
CVE-2026-114466: acesso indevido ao sistema de arquivos pelo fast-import
A última vulnerabilidade envolve o mecanismo git fast-import, utilizado para construir repositórios a partir de fluxos de comandos.
Três recursos não estavam adequadamente protegidos quando recebidos por uma entrada não confiável: rewrite-submodules-from, rewrite-submodules-to e export-pack-edges.
Os dois primeiros poderiam permitir a leitura de arquivos arbitrários, inclusive com exposição de informações por mensagens de erro. O terceiro poderia criar arquivos ou acrescentar dados a arquivos existentes.
A correção impede que esses recursos sejam utilizados por fluxos de entrada sem autorização explícita por meio da opção --allow-unsafe-features. Essa opção deve ser habilitada somente quando houver confiança na origem do fluxo processado.
Atualização imediata é essencial para proteger a cadeia de desenvolvimento
O pacote de novembro de 2026 demonstra como vulnerabilidades em ferramentas consideradas fundamentais podem produzir consequências que ultrapassam os computadores dos desenvolvedores.
A CVE-2026-111760 merece atenção especial porque transforma uma operação comum, como clonar um repositório com submódulos, em um possível vetor de execução de código malicioso.
Entretanto, os outros cinco problemas mostram que a superfície de ataque do Git também envolve referências, operações de mesclagem, processamento de patches binários e importação de dados.
Para administradores de sistemas, a prioridade deve ser identificar todas as instalações do Git, incluindo aquelas incorporadas em ferramentas de CI/CD, IDEs, aplicativos e serviços de hospedagem de código.
Em distribuições Linux, é importante verificar a disponibilidade das atualizações nos respectivos repositórios, considerando que os mantenedores podem distribuir correções por meio de versões com numeração própria ou backports.
Também é necessário atualizar servidores GitLab, instalações do GitHub Enterprise Server e outros serviços que executam operações automatizadas sobre conteúdo enviado por usuários.
A atualização para o Git 2.56.1 ou para a versão corrigida correspondente à série instalada deve ser tratada como prioridade. Em ambientes que não podem receber a correção imediatamente, a restrição de operações com repositórios não confiáveis deve fazer parte das medidas temporárias de contenção.
O Git é uma peça central da infraestrutura de desenvolvimento moderno. Manter essa ferramenta atualizada não é apenas uma questão de estabilidade, mas uma medida essencial para proteger estações de trabalho, pipelines de integração contínua e toda a cadeia de suprimentos de software.