Chaves de CA da eMudhra comprometidas: Go, Firefox e NSS lançam correções

As chaves privadas de oito certificados intermediários da eMudhra, uma autoridade certificadora indiana, foram expostas, confirmaram a Mozilla e o Google em 20 de outubro de 2026. Quem tiver essas chaves poderia emitir certificados HTTPS em que os navegadores confiariam, para sites que não são seus. Os navegadores bloquearam os certificados em poucas horas, mas muitos apps fora do navegador continuam expostos até serem atualizados.

O que aconteceu com as chaves da eMudhra

Uma autoridade certificadora, ou CA, atesta sites assinando os certificados deles. As grandes CAs assinam por meio de certificados “intermediários”, que ficam entre a raiz delas e cada site. Se a chave privada de um intermediário vaza, um invasor pode criar um certificado de aparência válida para qualquer domínio.

Um pesquisador informou as oito chaves aos fabricantes de navegadores no sábado, 17 de outubro. Ele comprovou isso assinando uma mensagem com cada chave: “We have a problem here - Wayne.” (Temos um problema aqui - Wayne.) Seis dos intermediários emitem certificados de sites (TLS) e dois assinam código de software, informa o The Hacker News.

As chaves também eram fracas, segundo o pesquisador de segurança Scott Helme. Cada uma era um número minúsculo, e ele recuperou as chaves privadas dos 16 certificados relacionados em menos de um segundo. Os intermediários são de abril de 2025, então qualquer pessoa poderia ter feito o mesmo por cerca de 17 meses. Helme cita a explicação da eMudhra: um bug em um script criou um segundo par de chaves, fraco, e a equipe escolheu o errado porque os nomes eram parecidos.

O The Hacker News diz que não se sabe como as chaves saíram da eMudhra nem quem mais as tem. A análise de Helme acrescenta que não há como saber se alguém as recuperou antes de agora.

Em 22 de outubro, a eMudhra anunciou que vai deixar por completo o negócio global de certificados SSL/TLS, como mostra eMudhra deixa o negócio global de certificados SSL/TLS após a falha de chaves fracas.

A rapidez de cada fornecedor

Quando (UTC)	Ação
17 de outubro, 18:05	O programa de raízes do Chrome recebe o relato
17 de outubro, 19:45	O Chrome bloqueia os seis intermediários TLS pelo CRLSet, sua lista de revogação
17 de outubro, 20:06	A Mozilla recebe o relato
17 de outubro, 22:59	O bloqueio via OneCRL do Firefox chega aos usuários com configurações padrão
19 de outubro	A Apple bloqueia os certificados
20 de outubro	A Microsoft os bloqueia; saem versões do Go, do Firefox e do NSS

A Mozilla diz que o Firefox não precisou de atualização nem de reinício para o bloqueio. Ela também lançou o Firefox 158.0.1, o ESR 115.43.1 e o ESR 153.5.1 para usuários cujas configurações personalizadas interromperam as atualizações do OneCRL. O NSS 3.131.1, a biblioteca de segurança da Mozilla, remove a raiz emSign ECC Root CA - G3, que assinou os intermediários. O Chrome vai retirar a mesma raiz na versão 43 do Chrome Root Store.

O Chrome não bloqueou os dois intermediários de assinatura de código, porque suas verificações de sites nunca passam por eles. O Chrome também disse que verificou todas as outras CAs da sua loja e “não encontrou outros casos desse modo de falha”. Nenhum certificado de site registrado em log se encadeava aos seis intermediários TLS antes do bloqueio do Chrome, informa o The Hacker News.

Por que apps fora do navegador ainda correm risco

Os navegadores recebem listas de bloqueio automaticamente. A maioria dos outros softwares nem sequer verifica revogação. Eles confiam em uma lista de CAs embutida até que alguém distribua uma nova.

Helme testou isso com um certificado forjado para api.stripe.com. Com as configurações padrão, curl, Python e Node o aceitaram no Linux e no macOS. No Windows, a biblioteca criptográfica do sistema o aceitou, a menos que a verificação de revogação estivesse ativada.

O Go precisou de uma mudança no código pelo mesmo motivo, explica o Cyber Kendra. Seu verificador de certificados não lê as listas de bloqueio dos navegadores, então os programas em Go confiam nas chaves até serem recompilados. Estas são as versões corrigidas citadas nas reportagens:

Software	Versão corrigida
Go	1.27.3 e 1.26.10 (CVE-2026-111943); 1.25 e anteriores estão fora de suporte
Firefox	158.0.1, ESR 115.43.1, ESR 153.5.1
NSS	3.131.1
Python certifi	2026.10.19
Rust webpki-roots	1.0.10
Electron	44.9.1, 43.8.1, 42.11.16

O que isso significa para desenvolvedores

Os navegadores estão cobertos. Seus servidores, ferramentas de build e contêineres provavelmente não estão, até você atualizá-los.

• Recompile os serviços em Go. Um binário Go carrega dentro dele as verificações de certificado. Recompile com o Go 1.27.3 ou 1.26.10 e faça o deploy de novo; atualizar apenas a lista de CAs da máquina não ajuda.
• Atualize as listas de CAs embutidas. Atualize o certifi em projetos Python, o webpki-roots em Rust e o Electron em apps de desktop. Recompile as imagens de contêiner para que elas recebam o novo pacote do sistema. As versões do Python de 21 de outubro trazem a correção para novas instalações, como mostra Python 3.15.1, 3.14.9 e 3.13.17 trazem o pip 26.2.2.
• Verifique suas próprias cadeias. Se um fornecedor ou serviço interno usa um certificado da eMudhra, descubra isso antes que as raízes desapareçam. Cole um certificado em um decodificador de certificados e leia o campo do emissor.
• Ative a verificação de revogação onde puder. O teste de Helme no Windows só detectou o certificado forjado com a verificação de revogação ativada. Trate essa configuração como parte da sua configuração de TLS, não como um extra.