Go bloqueia certificados de oito intermediários comprometidos da eMudhra

O Go↳Go23 conteúdosEntendendo o Green Tea GC do Go 1.26Dev (Back & Front) · mai 2026Função recursiva em Go para acessar valores em mapas aninhadosDev (Back & Front) · set 2025Publicando projeto desenvolvido em Golang em um server grátisDev (Back & Front) · mar 2025Ver tudo em Dev (Back & Front) → corrigiu, em caráter emergencial, a CVE-2026-111943: o runtime agora recusa qualquer cadeia de certificados que passe por um grupo de oito intermediários com chaves comprometidas, ligados à autoridade certificadora eMudhra.

Nota da redação: este artigo originalmente descrevia Brad Fitzpatrick como 'um dos criadores do Go'. Isso está incorreto: os criadores da linguagem são Robert Griesemer, Rob Pike e Ken Thompson. Fitzpatrick é um contribuidor histórico de peso no time do Go, responsável pelo commit de bump para a versão 1.27.3 citado no texto, mas não um dos criadores originais. Mantemos o restante do conteúdo, que foi verificado e confirmado contra a issue fonte.

O Go corrigiu, em caráter emergencial, a CVE-2026-111943: o runtime agora recusa qualquer cadeia de certificados que passe por um grupo de oito intermediários com chaves comprometidas, ligados à autoridade certificadora eMudhra.

O Go corrigiu, em caráter emergencial, a CVE-2026-111943: o runtime agora recusa qualquer cadeia de certificados que passe por um grupo de oito intermediários com chaves comprometidas, ligados à autoridade certificadora eMudhra.

O patch de emergência

No dia 19 de outubro de 2026, o time do Go abriu a issue golang/go#82345, marcada como release-blocker e associada à CVE-2026-111943. A partir desse patch, o pacote crypto/x509 passou a filtrar, dentro da função Verify(), qualquer cadeia de certificados que contenha um conjunto de oito certificados intermediários específicos. A cadeia simplesmente não é mais retornada ao chamador: não há aviso, há rejeição.

O rótulo release-blocker foi aplicado à issue, sinalizando urgência: o time não esperou o ciclo normal de patches menores. No mesmo dia da abertura da issue, backports foram criados para as issues #82348 (branch do Go 1.26) e #82349 (branch do Go 1.27), e o texto da issue original recomenda, literalmente, atualizar imediatamente.

Por que oito intermediários caíram juntos

A issue não detalha publicamente os motivos técnicos da suspensão de confiança além de falar em "preocupações de segurança específicas sobre a operação" dos intermediários. Quem deu o contexto foi Filippo Valsorda, referência histórica na área de criptografia do Go, direto nos comentários da issue:

Isso não é uma decisão de política baseada em quão bem a CA escreve sua CPS: as chaves estão comprometidas e os certificados, revogados.

This is not a policy decision based on how well the CA writes their CPS, the keys are compromised and their certificates revoked.Filippo Valsorda, referência em criptografia do projeto Go

Ele explica por que a correção precisou ser hardcoded direto na biblioteca. No Linux↳Linux34 conteúdosKali Linux em um Servidor VPS: como, quando e por que usar?DevSecOps · dez 2024Construindo um Windows Service ou Linux Daemon com Worker Service & .NET Core – Parte 2Dev (Back & Front) · jul 2020Criando uma WebApi utilizando .NET, Linux e VSCodeDev (Back & Front) · ago 2019Ver tudo em DevSecOps →, segundo ele, os repositórios de certificados raiz são "uma pilha de PEMs atrás de uma lixeira": não existe um mecanismo confiável para propagar a revogação de um intermediário até as aplicações que o consomem. Hardcodar o bloqueio em crypto/x509 foi, na visão do time, a única forma prática de garantir que aplicações Go parem de confiar nessas cadeias de fato.

Qual CA está por trás do bloqueio

A issue pública não nomeia a autoridade certificadora, mas os commits que foram subindo em dezenas de repositórios dependentes do Go, horas depois, deixaram escapar o nome. Um commit do desenvolvedor phinze descreve a atualização como feita "for the eMudhra intermediate CA distrust", apontando a eMudhra como a CA cujos intermediários tiveram a confiança revogada.

Quais versões já trazem a correção

• Go 1.26.10 recebeu o backport do distrust (branch da issue #82348, CL https://go.dev/cl/851145).
• Go 1.27.3 recebeu o mesmo backport (branch da issue #82349, CL https://go.dev/cl/851165).
• Go 1.28, ainda em desenvolvimento, já nasce com a mitigação aplicada, já que é o milestone original da issue (CL https://go.dev/cl/851047).

Na prática, qualquer versão do Go anterior a essas não tem o bloqueio. É possível conferir a versão instalada com go version e o toolchain usado num projeto específico olhando o campo toolchain do go.mod.

A mesma correção chegou ao Node.js

O problema de confiança nesses intermediários não é exclusivo do ecossistema Go. Horas depois do patch original, um commit atribuído à conta automatizada nodejs-github-bot apareceu no repositório do projeto com a mesma descrição de intenção: "tls: reject chains containing blocked public keys". O runtime JavaScript portou a mesma lógica de bloqueio para o próprio módulo tls, confirmando que qualquer stack que dependa dos mesmos certificados intermediários está exposta ao mesmo risco, independentemente da linguagem.

A polêmica: filtro de confiança dentro da biblioteca padrão

Nem todo mundo concordou com a abordagem. O comentário mais reagido da issue, de um usuário identificado como Drugoy, questiona se esse tipo de decisão deveria estar na biblioteca padrão de uma linguagem:

Na minha opinião, isso cria um precedente ruim. Esse tipo de filtro extra não é trabalho de um pacote padrão de linguagem de programação. A biblioteca deveria confiar no máximo tanto quanto o sistema confia, a menos que tenha sido projetada desde o início para ter seu próprio repositório de confiança, como o Java faz.

IMO, this sets a bad precedent. Such extra filtering isn't a job for a programming language's standard package / lib. The library should trust no less than the system does, unless it is initially designed to have its own truststore, like Java does.Drugoy, comentário na issue do GitHub

O comentário recebeu 24 reações de concordância e 3 de discordância, entre elas a de Daniel McCarney, que reagiu contra a crítica, ou seja, a favor da decisão do time do Go. Valsorda reconheceu a tensão: disse que o time vai investir em "soluções menos improvisadas" no futuro, mas que isso exige coordenação em larga escala do ecossistema e não vai acontecer rápido.

O que fazer agora em produção

Se o seu serviço em Go faz chamadas HTTPS de saída, roda um proxy reverso ou termina TLS em Go, o risco é concreto: se o certificado do outro lado da conexão foi emitido por um dos intermediários agora bloqueados, a verificação passa a falhar assim que você atualizar o runtime, com um erro de x509 na cadeia de certificação.

1. Atualize o toolchain Go para 1.26.10, 1.27.3 ou a versão mais recente disponível, tanto localmente quanto no pipeline de CI/CD.
2. Depois de atualizar, rode os testes de integração contra todos os endpoints HTTPS externos que o seu serviço consome, não só contra os seus próprios certificados.
3. Se algum handshake começar a falhar, use openssl s_client -connect host:443 -showcerts para inspecionar a cadeia e identificar o emissor do intermediário suspeito.
4. Para certificados emitidos à sua própria empresa via eMudhra, contate a CA ou o provedor de certificado para reemissão por uma cadeia não afetada.

Vale notar que vários projetos de peso já tinham atualizado o Go no mesmo dia do patch, incluindo bumps assinados por Brad Fitzpatrick e commits em dezenas de repositórios dependentes espalhados pelo ecossistema. O volume de atualizações no primeiro dia é um indicativo de quão seriamente o ecossistema tratou o aviso.

Fonte 1: Hacker News (https://github.com/golang/go/issues/82345)

crypto/x509: mitigation for security concerns with a specific Certificate Authority · Issue #82345 · golang/go · GitHub

Skip to content

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session.

Dismiss alert

crypto/x509: mitigation for security concerns with a specific Certificate Authority #82345 New issue Copy link New issue Copy link Closed Closed crypto/x509: mitigation for security concerns with a specific Certificate Authority #82345 Copy link Labels Security release-blocker Milestone Go1.28 Description thatnealpatel opened on Oct 19, 2026 Issue body actions We're blocking trust in a small set of intermediate certificates due to specific security concerns around their operation.

Verify will now filter out chains which contain these intermediates, preventing them from being returned to the caller.

We highly recommend immediately upgrading to this release.

This is CVE-2026-111943 and Go issue https://go.dev/issue/82345 .

This was an URGENT track issue originally tracked in http://b/575512169 . Reactions are currently unavailable Activity Next thatnealpatel added this to the Go1.28 milestone on Oct 19, 2026 thatnealpatel added Security release-blocker on Oct 19, 2026

thatnealpatel commented on Oct 19, 2026 thatnealpatel on Oct 19, 2026 Last edited by dmitshur Member Author More actions @gopherbot Please open backports for this issue.

gopherbot commented on Oct 19, 2026 gopherbot on Oct 19, 2026 Contributor More actions Backport issue(s) opened: #82348 (for 1.26), #82349 (for 1.27).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases . 👍 React with 👍 1 Reacted by AriESQ gopherbot added 2 commits that reference this issue on Oct 20, 2026 [release-branch.go1.26] crypto/x509: distrust a handful of intermediates ... aa64342 [release-branch.go1.27] crypto/x509: distrust a handful of intermediates ... 90617fb

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851165 mentions this issue: [release-branch.go1.27] crypto/x509: distrust a handful of intermediates

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851145 mentions this issue: [release-branch.go1.26] crypto/x509: distrust a handful of intermediates

gopherbot commented on Oct 20, 2026 gopherbot on Oct 20, 2026 Contributor More actions Change https://go.dev/cl/851047 mentions this issue: crypto/x509: distrust a handful of intermediates thatnealpatel changed the title [-] security: fix CVE-2026-111943 [/-] [+] crypto/x509: mitigation for security concerns with a specific Certificate Authority [/+] on Oct 20, 2026 gopherbot added a commit that references this issue on Oct 20, 2026 crypto/x509: distrust a handful of intermediates ... 7f86f95 thatnealpatel closed this as completed on Oct 20, 2026 chenxiaolong added 2 commits that reference this issue on Oct 20, 2026 external/go: Update to go1.27.3 ... 0e623cf external/go: Update to go1.27.3 ... 06bfbc8

14 remaining items Load more sluongng added a commit that references this issue on Oct 20, 2026 deps: upgrade Go to 1.27.3 ( #13875 ) ... 880460c

Drugoy commented on Oct 20, 2026 Drugoy on Oct 20, 2026 More actions IMO, this sets a bad precedent. Such extra filtering isn't a job for a programming language's standard package / lib.

The library should trust no less than the system does, unless it is initially designed to have its own truststore, like Java does. 👍 React with 👍 24 Reacted by minullin, deanos2310, Tobias, Raffy E., Ellen Emilia Anna Zscheile, Cirno the Strongest, Jason Healy, makeworld, Brandon Mendrick, Denis and 14 more 👎 React with 👎 3 Reacted by Macy D., Youfu Zhang and Daniel McCarney bradfitz added a commit that references this issue on Oct 20, 2026 go.toolchain.rev: bump to Go 1.27.3 ... b2bbb0b vettid added 5 commits that reference this issue on Oct 20, 2026 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ...

3d7ce03 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ... 4c072c4 Build: golang 1.26.10-alpine by tag and digest (crypto/x509 distrusts… ... 2693249 Build: toolchain go1.26.10 (crypto/x509 distrusts eight intermediates) ( ... a70b98e Build: Go 1.26.10 (crypto/x509 distrusts eight intermediates) ( #133 ) ... a527822 dims added a commit that references this issue on Oct 20, 2026 build: bump Go to 1.27.3 ( #1821 ) ... b386658

FiloSottile commented on Oct 20, 2026 FiloSottile on Oct 20, 2026 Contributor More actions This is not a policy decision based on how well the CA writes their CPS, the keys are compromised and their certificates revoked.

Unfortunately, the state of Linux root stores (a pile of PEM files behind a dumpster) is such that the revocation of these intermediates has no way to propagate to applications, short of hardcoding them in code like this.

The Go cryptography libraries exist to help developers build secure applications . An application that accepts chains through these revoked intermediates is not secure, so we patched the Go cryptography libraries accordingly.

We'll be investing in less ad-hoc solutions for the future, but that requires large-scale ecosystem coordination, so it won't be quick. 👍 React with 👍 6 Reacted by AriESQ, Serge Bazanski, Apoorv Munshi, Khiman Louer, Jack Platten and Kane York nickoneill added a commit that references this issue on Oct 20, 2026 go.toolchain.rev: bump to Go 1.27.3 ( #21870 ) ... 42347eb nodejs-github-bot added a commit that references this issue on Oct 20, 2026 tls: reject chains containing blocked public keys ... d9a3f3d lizthegrey added a commit that references this issue on Oct 20, 2026 maint: bump go to 1.27.3 ...

2373ff0 phinze added a commit that references this issue on Oct 20, 2026 Build with Go 1.27.3 for the eMudhra intermediate CA distrust ... a08d3b4 maint: bump go to 1.27.3 ... 6c44005 Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment Metadata Assignees No one assigned Labels Security release-blocker Type No type Projects No projects Milestone Go1.28 No due date Relationships None yet Development No branches or pull requests Issue actions

Open in GitHub Copilot app

You can’t perform that action at this time.

Fonte: Hacker News