Git allows arbitrary code execution through broken config quoting

Falha no parsing de arquivos de configuração do Git (.gitmodules) permite execução arbitrária de código ao clonar um repositório malicioso com submódulos. O Git remove CR/LF ao ler um valor de config, mas não citava (quota) valores com CR final ao escrever — criando uma divergência que permite mascarar o caminho real de um submódulo. Está no catálogo KEV da CISA com exploração confirmada, mas o vetor exige interação do usuário (clone recursivo) e checkout de um submódulo malicioso, não é RCE remoto sem ação da vítima.

O bug está na camada de leitura/escrita de config do Git. Ao ler um valor de configuração, o parser descarta qualquer CRLF/CR final à direita. Ao escrever um valor de config que termine em CR, o Git não envolve o valor em aspas — então essa proteção que deveria preservar o CR é perdida na próxima leitura. O resultado prático: um caminho de submódulo definido em .gitmodules com um CR final é gravado sem quoting no config interno e, quando lido de volta, o CR desaparece silenciosamente, alterando efetivamente o caminho resultante do submódulo em relação ao que o atacante originalmente declarou.

O atacante cria um repositório com um submódulo cujo path em .gitmodules contém um CR à direita. Quando a vítima clona esse repositório de forma recursiva (com --recurse-submodules, ou faz `git submodule update --init` depois), o Git inicializa o submódulo no caminho alterado (sem o CR) em vez do caminho declarado. Se o repositório também contém um symlink que aponta esse caminho alterado para o diretório .git/hooks/ do submódulo, e o submódulo possui um hook post-checkout executável, esse hook pode ser executado sem intenção explícita da vítima logo após o checkout — resultando em execução de código com os privilégios do usuário que fez o clone.

A correção definitiva é atualizar o Git para a versão corrigida do ramo correspondente. Como paliativo quando não é possível atualizar imediatamente, o advisory oficial recomenda evitar clonar recursivamente submódulos de repositórios não confiáveis (não usar --recurse-submodules nem `git submodule update --init` em repositórios de origem desconhecida). Não existe flag de configuração ou controle de linha de comando documentado que neutralize a falha sem a correção de código — a mitigação real é a atualização binária do Git ou a abstenção de operações recursivas com submódulos em fontes não confiáveis. Distribuições backportaram a correção em pacotes próprios (ex.: Debian 11 em 1:2.30.2-1+deb11u5, via DLA-4323-1); a Apple corrigiu o Git empacotado no Xcode 26.

Procure em repositórios clonados por entradas em .gitmodules cujo campo `path` termine em caractere de controle (CR, 0x0D) — isso não é visível em editores comuns e exige inspeção binária/hexdump do arquivo. Outro sinal é a presença de symlinks dentro do repositório apontando para dentro do diretório .git/hooks/ de um submódulo, combinada com um hook post-checkout executável no submódulo — essa combinação é o indicador estrutural do ataque. Não há assinatura de rede confiável, pois a exploração ocorre inteiramente no processamento local do repositório clonado; monitorar execução inesperada de processos filhos do `git` (via hooks) após operações de clone/submodule update em ambientes de CI é o sinal comportamental mais prático.