Oito chaves privadas de autoridades certificadoras intermediárias da indiana eMudhra podiam ser recalculadas a partir dos próprios certificados públicos, e o alerta chegou aos programas de raízes de Google, Mozilla, Apple e Microsoft em 17 de outubro de 2026. Até 21 de outubro, os navegadores já tinham bloqueado as intermediárias, mas bibliotecas, distribuições Linux e imagens de container ainda dependem de atualização manual.
Para quem administra servidor ou mantém aplicação, o risco não está no Chrome do usuário. Está no curl, no cliente HTTP em Go, no Python com certifi antigo e no container que ninguém reconstrói há meses.
Por que oito chaves fracas afetam quem nunca usou eMudhra
As chaves não foram roubadas. Segundo as equipes de segurança do Google, citadas pelo The Hacker News, elas foram geradas com aleatoriedade insuficiente. Seis intermediárias serviam para TLS e duas para assinatura de código, de acordo com o Tecnoblog.
Quem tem essas chaves consegue emitir um certificado que qualquer sistema ainda confiante na cadeia aceita como legítimo, para qualquer domínio. Para explorar isso, o atacante precisa interceptar o tráfego entre a vítima e o serviço. Até a publicação, não havia registro público de certificado fraudulento usado em ataque.
| Quem | Ação | Data |
|---|---|---|
| Chrome | Bloqueio das seis intermediárias TLS via CRLSet | 17/10 |
| Firefox | Bloqueio via OneCRL; Firefox 158.0.1 e NSS 3.131.1 | 17/10 a 20/10 |
| Android | Bloqueio pelo Google Play Services | 19/10 |
| Apple | Bloqueio dos certificados | 19/10 |
| Microsoft | Bloqueio dos certificados | 20/10 |
Antes de começar: o que verificar na sua stack
Navegador atualizado está protegido. O problema são os programas que leem o próprio pacote de raízes e não checam revogação. Faça um inventário rápido:
- Pacote ca-certificates do sistema operacional de cada servidor.
- Bibliotecas que trazem raízes embutidas: certifi (Python), webpki-roots (Rust), o bundle do Node.js.
- Binários Go, que embutem a lógica de verificação na compilação.
- Imagens base de containers e navegadores instalados via snap, que têm base própria.
- Sites seus com certificado emitido sob emSign ECC Root CA – G3 ou emSign Root TLS CA – G3.
Passo a passo para limpar servidores e builds
- Ubuntu: aplique os avisos USN-8944-1 e USN-8944-2, publicados em 20/10. Eles removem a raiz emSign ECC G3 e, em versões anteriores à 22.04, também a AAA Certificate Services.
- Debian 13: atualize para o pacote 20250419+deb13u1 (DSA-6572-1).
- Python: suba o certifi para a versão 2026.10.19 ou posterior.
- Rust: atualize o webpki-roots para 1.0.10.
- Node.js: instale 26.12.1, 24.22.1 ou 22.23.4, lançadas em 21/10.
- Go: recompile com Go 1.27.3 ou 1.26.10 (CVE-2026-111943). Go 1.25 e anteriores não recebem correção.
- Containers: reconstrua as imagens depois que a imagem base trouxer o pacote novo. Atualizar o host não muda o que está dentro do container.
- Teste: confirme que seus clientes HTTP rejeitam uma cadeia que passe pelas intermediárias comprometidas.
Pontos em que a limpeza empaca
RHEL ainda sem pacote
A Red Hat classificou o caso como Importante no boletim RHSB-2026-012, mas os pacotes não tinham saído até 21/10. Existe um contorno para RHEL 7 e posteriores, com um efeito colateral: ele também derruba certificados legítimos emitidos sob essas raízes. O RHEL 6 precisa esperar o pacote.
Remover a raiz quebra sites legítimos
A correção remove raízes inteiras, não só as intermediárias ruins. Se algum fornecedor seu usa certificado sob emSign G3, a conexão vai falhar depois da atualização. O Chrome prevê levar a remoção da raiz emSign ECC Root CA – G3 aos dispositivos na manhã de 27 de outubro (horário do Pacífico), e quem tem certificado nessa raiz precisa migrar antes.
Quem acompanhou a corrida do patch do PHP, liberado em 21 de outubro, vai reconhecer o padrão de inventário primeiro, atualização depois, descrito no texto sobre o PHP2Shell.
Pacotes que ainda não tinham correção em 21 de outubro
Segundo o levantamento citado pelo The Hacker News, ainda estavam pendentes Fedora, Arch, Alpine, Gentoo, FreeBSD, o bundle do curl, pip, uv, Electron e Bun. O curl do macOS também seguia aceitando a cadeia. Não há como detectar abuso passado além da busca nos logs de Certificate Transparency, que só cobre certificados registrados. Para essas plataformas, o que resta definir é a data dos pacotes, e o monitoramento dos avisos de segurança de cada uma é a única forma de saber quando aplicar.
