--- title: "Go 1.26.5 corrige CVEs em crypto/tls e os.Root" url: "https://golang.com.br/novidades/go-1-26-5-cves-crypto-tls-os-root/" markdown_url: "https://golang.com.br/novidades/go-1-26-5-cves-crypto-tls-os-root.MD" description: "Go 1.26.5 e Go 1.25.12 corrigem CVEs em crypto/tls e os.Root. Veja impacto, risco real e como atualizar serviços Go." date: "2026-07-13" author: "Go Brasil" --- # Go 1.26.5 corrige CVEs em crypto/tls e os.Root Go 1.26.5 e Go 1.25.12 corrigem CVEs em crypto/tls e os.Root. Veja impacto, risco real e como atualizar serviços Go. TL;DR: o Go 1.26.5 e o Go 1.25.12 foram publicados com duas correções de segurança relevantes: uma em `os.Root`, que podia permitir escape por symlink em Unix quando o caminho terminava com barra, e outra em `crypto/tls`, envolvendo vazamento de identidades de PSK durante handshakes com Encrypted Client Hello. Se você compila serviços com Go 1.26 ou mantém a linha anterior 1.25, a atualização deve entrar na próxima janela de deploy; para sistemas expostos a caminhos controlados por usuário ou TLS com ECH, trate como prioridade maior. ## O que foi lançado O anúncio oficial no golang-nuts, publicado em 7 de julho de 2026, marcou o lançamento de **Go 1.26.5** e **Go 1.25.12** como releases menores de correção. A página de histórico de releases também registra que o Go 1.26.5 inclui correções de segurança nos pacotes `crypto/tls` e `os`, além de ajustes no compilador, runtime, comando `go` e pacotes `net`, `os` e `syscall`. Para quem ainda está na linha 1.25, o Go 1.25.12 traz as mesmas correções de segurança em `crypto/tls` e `os`, mais correções no compilador, comando `go`, `net` e `os`. Ou seja: não é uma mudança de linguagem nem um release para testar novidade; é o tipo de atualização que deve percorrer CI, staging e produção com foco em reduzir risco conhecido. ## CVE-2026-39822: escape em os.Root A primeira falha, **CVE-2026-39822**, afeta `os.Root` em Unix. Segundo o anúncio, um caminho terminado com barra podia escapar da raiz por meio de um symlink. O exemplo citado é `root.Open("symlink/")`: se `symlink` apontasse para fora da raiz, a chamada podia abrir o alvo mesmo quando a intenção era limitar o acesso à árvore controlada por `os.Root`. Isso importa porque `os.Root`, introduzido nas versões recentes do Go, existe justamente para reduzir bugs de traversal de caminho. A API é útil para código que precisa abrir arquivos enviados por usuário, servir conteúdo de diretórios controlados, manipular uploads extraídos em área temporária ou limitar operações a uma raiz lógica. Quando a abstração de contenção falha, o impacto tende a aparecer em fronteiras de segurança: arquivos fora do diretório permitido, leitura indevida ou comportamento diferente entre validação e abertura real. O ponto prático para revisar é simples: se o seu serviço usa `os.Root` em Unix e recebe caminhos externos, atualize o toolchain antes de considerar a contenção resolvida. Também vale procurar testes que cubram symlinks, caminhos com barra final e diretórios controlados por usuário. A correção no runtime não substitui esse cuidado, mas remove uma armadilha específica da implementação. ## CVE-2026-42505: ECH e identidades de PSK A segunda falha, **CVE-2026-42505**, está em `crypto/tls`. O problema envolve **Encrypted Client Hello** e identidades de chave pré-compartilhada, ou PSK. De acordo com o anúncio, durante o handshake TLS, essas identidades podiam ser expostas de forma que um observador passivo inferisse o hostname do servidor, apesar do uso de ECH. ECH é uma peça voltada a privacidade no TLS: a ideia é criptografar partes do ClientHello para esconder metadados que historicamente ficavam visíveis na conexão. Se um detalhe do handshake entrega uma pista suficiente para recuperar o nome do servidor, a promessa de privacidade fica enfraquecida mesmo sem quebrar a criptografia do tráfego de aplicação. Nem todo serviço Go usa ECH hoje. Mesmo assim, a correção é importante para bibliotecas, proxies, clientes, gateways e produtos que acompanham versões modernas de TLS. Se você mantém infraestrutura que depende de `crypto/tls`, especialmente código que ativa ECH ou trabalha com PSK, não trate esse patch como cosmético. ## Como atualizar sem transformar em incidente Para aplicações comuns, o fluxo recomendado é o de qualquer atualização de patch do Go: trocar a versão do toolchain, rodar a suíte, gerar os artefatos com a nova versão e promover por ambiente. O cuidado extra aqui é garantir que a versão usada no build real mudou, não só a versão instalada na máquina de alguém. Um checklist mínimo: ```bash go version go test ./... govulncheck ./... ``` Em CI, confira imagens Docker, arquivos `toolchain`/`go` no `go.mod`, versões fixadas em actions, caches de build e scripts de release. Em serviços containerizados, a atualização normalmente passa pela imagem base ou pela etapa que baixa o tarball do Go. Em CLIs distribuídas para clientes, lembre que o binário carrega a biblioteca padrão compilada junto; atualizar o ambiente de build e republicar o binário é parte da correção. Se o projeto está em Go 1.26, o alvo natural é Go 1.26.5. Se ainda está preso em Go 1.25 por compatibilidade, use Go 1.25.12. O que não vale é ficar em Go 1.26.3 achando que `go get` resolve: vulnerabilidades na biblioteca padrão exigem recompilar com o toolchain corrigido. ## Saiba mais - [Anúncio oficial: Go 1.26.5 e Go 1.25.12](https://groups.google.com/g/golang-nuts/c/HatL1GnWess) - [Histórico de releases do Go](https://go.dev/doc/devel/release#go1.26.5) - [govulncheck em Go: Vulnerabilidades que Importam](/blog/govulncheck-go-vulnerabilidades-dependencias/) - [Go completa 16 anos: os.Root e avanços de segurança](/blog/go-16-anos-aniversario/)