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:
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.