0xmrma/cve-2026-14361O helper writeToFile do Consul Template abria diretamente um destino fornecido pelo operador e seguia componentes de caminho com link, permitindo que a saída renderizada escapasse do diretório pretendido e sobrescrevesse um arquivo pré-existente.
O helper writeToFile do Consul Template abria diretamente um destino fornecido pelo operador e seguia componentes de caminho vinculados, permitindo que a saída renderizada escapasse do diretório pretendido e sobrescrevesse um arquivo preexistente.
Encontrei este problema ao revisar o HashiCorp Consul Template, com uma pergunta direta de segurança de filesystem em mente:
Se writeToFile receber um caminho que parece estar dentro do diretório pretendido, ele verifica onde o filesystem realmente gravará os dados?
Neste caso, a resposta foi não.
O helper de template writeToFile abria o caminho final fornecido pelo usuário diretamente por meio de os.Create() ou os.OpenFile().
Essas operações seguiam links simbólicos, junções de diretório e redirecionamentos equivalentes de filesystem já presentes no caminho de destino.
Isso significava que a string de caminho podia permanecer sob a raiz pretendida pelo operador enquanto a gravação real ocorria em outro lugar.
Na minha prova de conceito controlada, um diretório pai vinculado redirecionou a saída renderizada para fora da árvore pretendida e fez com que um arquivo de destino preexistente fosse sobrescrito.
Esse problema tornou-se CVE-2026-14361.
Boletim da HashiCorp: HCSEC-2026-20
Boletim da IBM: Boletim de segurança CVE-2026-14361
CVE: CVE-2026-14361
Corrigido em: 0.42.1
photo0
o destino fornecido pelo operador parece estar dentro da raiz pretendida -> o atacante pré-posiciona o componente pai ou final vinculado -> writeToFile abre o caminho diretamente -> o filesystem resolve a gravação fora do diretório pretendido -> o segredo renderizado é redirecionado -> o destino preexistente pode ser sobrescrito
O Consul Template renderiza dados de fontes como Consul e Vault.
O helper writeToFile permite que um template grave conteúdo selecionado em um arquivo local separado, aplicando um proprietário, grupo e modo de permissão solicitados.
A documentação da HashiCorp demonstra especificamente o helper com material de PKI:
private key -> writeToFile /my/path/to/cert.key
certificate authority -> writeToFile /my/path/to/cert.pem
certificate -> append to /my/path/to/cert.pem
Isso faz dele mais do que um helper de saída comum.
O conteúdo que cruza esse limite pode incluir:
A pergunta importante não era se o writeToFile poderia criar um nome de arquivo solicitado.
A pergunta real era:
O processo grava no local de filesystem pretendido pelo operador, ou meramente em qualquer objeto para o qual o caminho resolva no momento da abertura?
Em versões vulneráveis, ele confiava na segunda opção.
Helpers de gravação são superfícies de segurança de alto valor porque fazem a transição de dados de aplicação para mutação do filesystem.
As falhas interessantes geralmente não são a travessia clássica de ../.
São falhas de resolução:
Isso é especialmente importante quando o processo executa com mais privilégios de filesystem do que o atacante.
Um atacante local com baixos privilégios pode não conseguir sobrescrever diretamente um arquivo sensível.
Mas se ele puder influenciar um componente de caminho sob um diretório de gravação pretendido, um processo do Consul Template com mais privilégios pode realizar a gravação por ele.
Essa foi a fronteira na qual me concentrei.
Não abordei isso como uma revisão genérica de travessia de caminho.
O caminho fornecido não precisava de segmentos ...
Ele podia permanecer lexicalmente dentro da raiz pretendida durante todo o tempo.
A pergunta mais forte era:
Os componentes de destino vinculados são rejeitados antes que o conteúdo sensível seja gravado?
Essa pergunta importa para ambos os casos:
O segundo caso é especialmente útil porque logs e configuração ainda mostram um caminho de aparência inofensiva sob o diretório esperado.
O filesystem o resolve em outro lugar.
A causa raiz era a criação direta de arquivos baseada em caminho, sem validação ciente de links.
Na revisão testada, writeToFile() selecionava um de dois caminhos de abertura.
O modo de anexação usava:
f, err = os.OpenFile(
path,
os.O_APPEND|os.O_WRONLY|os.O_CREATE,
perm,
)
O modo de gravação normal usava:
dirPath := filepath.Dir(path)
if _, err := os.Stat(dirPath); err != nil {
err := os.MkdirAll(dirPath, os.ModePerm)
if err != nil {
return "", err
}
}
f, err = os.Create(path)
Nenhum dos dois caminhos rejeitava componentes de destino vinculados antes que o arquivo fosse aberto.
Isso importa porque:
os.Create(path) segue redirecionamentos de filesystem existentes e trunca o arquivo resolvidoos.OpenFile(path, ...) segue componentes de caminho vinculados durante o modo de anexaçãoA mesma suposição baseada em caminho continuava após a gravação.
Proprietário e permissões eram aplicados usando o caminho novamente:
err = os.Chown(path, uid, gid)
err = os.Chmod(path, perm)
Isso significava que as operações de metadados também estavam vinculadas a um nome de caminho mutável, em vez do descritor de arquivo já aberto.
Porque o atacante pode preparar o redirecionamento antes que o writeToFile execute.
Nenhuma condição de corrida (race) probabilística é necessária para o ataque básico.
A sequência é direta:
writeToFile o abre diretamenteEssa é a vulnerabilidade por completo.
É verdade que sistemas operacionais normalmente seguem symlinks ao abrir arquivos por caminho.
Isso não torna esse comportamento de aplicação seguro.
A pergunta de segurança não é:
"O Go se comportou como documentado?"
A pergunta real é:
Um helper que grava dados sensíveis renderizados verificou se o destino resolvido correspondia ao local pretendido pelo operador?
Em versões vulneráveis, não verificou.
Essa distinção importa porque o Consul Template pode executar:
Seguir redirecionamentos de filesystem posicionados pelo atacante nesse contexto cria um problema real de privilégio e de fronteira de confiança.
Construí um reprodutor independente em torno do comportamento exato do writeToFile no commit testado.