Na noite de 17 de outubro de 2026, um pesquisador de segurança que opera sob o apelido "Wayne" enviou uma mensagem desconcertante para as equipes de confiança digital de Mozilla, Google, Apple e Microsoft: assinaturas digitais criptográficas, cada uma delas usando a chave privada de uma das oito autoridades certificadoras intermediárias da empresa indiana eMudhra. A mensagem era simples — "We have a problem here - Wayne" — mas o significado era devastador. Quem poderia verificar essas assinaturas com a chave pública correspondente sabia, sem sombra de dúvida, que Wayne possuía acesso às chaves privadas que deveriam estar guardadas em módulos de segurança de hardware (HSMs) trancados e protegidos por múltiplas autorizações.
As consequências potenciais desse comprometimento são das mais graves para a infraestrutura digital global. Certificados intermediários TLS atuam como elos na cadeia de confiança que conecta a raiz de uma autoridade certificadora (CA) aos certificados finais que os sites usam para se autenticar. Quando uma chave intermediária é comprometida, qualquer pessoa que a possuir pode criar certificados HTTPS válidos para qualquer domínio — google.com, banco.gov.br, seu-correio.com — que os navegadores aceitariam como legítimos. Isso habilita ataques de "man-in-the-middle" em que um atacante intercepta o tráfego cifrado de usuários, lendo e modificando comunicações que deveriam ser privadas, desde senhas de banco até mensagens de saúde.
O que foi comprometido
As oito chaves comprometidas pertencem a certificados intermediários emitidos pela eMudhra, uma empresa indiana de confiança digital que opera sob a marca emSign, com operações nos Estados Unidos, Países Baixos e Índia. Seis desses certificados são destinados à emissão de certificados TLS para sites — abrangendo validação de domínio (DV), validação de organização (OV) e validação estendida (EV). As duas restantes são certificados de assinatura de código.
Cada família de certificados TLS (DV, OV, EV) possui variantes G3B e G3C, emitidas sob a raiz "emSign Root TLS CA - G3". Essas chaves intermediárias são projetadas para manter a chave raiz offline em HSMs auditados, permitindo que a CA opere com mais flexibilidade sem expor a raiz principal. O que torna este incidente particularmente preocupante não é apenas o número de chaves comprometidas — oito simultaneamente seria improvável em uma falha isolada — mas o fato de que todas as oito pertencem à mesma autoridade, o que sugere uma falha sistêmica em vez de um acidente pontual.
A resposta das grandes empresas
A velocidade de resposta foi impressionante. O Chrome Root Program recebeu o relatório às 18h05 UTC de 17 de outubro e, em menos de duas horas, às 19h45 UTC, já tinha uma atualização de CRLSet bloqueando os seis intermediários TLS. A Mozilla recebeu a mesma notificação às 20h06 UTC e, às 22h59 UTC, tinha distribuído um bloqueio via OneCRL para todos os usuários Firefox com configurações padrão — tudo sem que fosse necessário atualizar ou reiniciar o navegador.
A Apple bloqueou os certificados em 19 de outubro, a Microsoft em 20 de outubro, e a equipe do projeto Go (a linguagem de programação do Google) lançou atualizações de emergência nas versões 1.27.3 e 1.26.10, atribuídas ao CVE-2026-111943. O projeto Go foi particularmente agressivo: em vez de confiar em listas de revogação externas, o código-fonte foi alterado para rejeitar hardcoded qualquer cadeia de confiança que contivesse uma das oito chaves comprometidas. O Python certifi e o Rust webpki-roots também foram atualizados, demonstrando que o impacto vai muito além dos navegadores.
Por que intermediários são piores que certificados "folha"
Para entender a gravidade, é útil diferenciar dois tipos de certificados. Um certificado "folha" (end-entity) é o que um site individual — digamos, um site de notícias — usa para criptografar sua conexão. Se a chave desse certificado for comprometida, o dono do site gera um novo par de chaves, solicita um substituto e o problema está resolvido. O impacto é contido.
Um certificado intermediário é diferente. Ele existe para delegar autoridade de assinatura sem expor a raiz. Um atacante com uma chave intermediária herda toda a confiança que os usuários colocam naquela linha hierárquica. Pode emitir certificados válidos para qualquer domínio, contornar as verificações de validação que CAs legítimas normalmente aplicam e criar uma fachada digital indistinguível para serviços bancários, governamentais ou corporativos.
O problema do cross-signing
A situação foi complicada por uma prática chamada "cross-signing". Para garantir que dispositivos mais antigos — que talvez não tivessem a versão mais recente das raízes da eMudhra — continuassem funcionando, os intermediários comprometidos foram cross-signados por uma autoridade estabelecida: a AAA Certificate Services da Sectigo. Isso significa que um cliente poderia construir uma cadeia de confiança válida que passa pela raiz da Sectigo em vez da eMudhra.
Se um navegador simplesmente desconfiasse a raiz da eMudhra, um atacante ainda poderia apresentar uma cadeia que passa pela Sectigo. A solução veio quando os navegadores passaram a bloquear os hashes SPKI (Subject Public Key Info) das chaves intermediárias comprometidas — ou seja, bloquearam as próprias chaves públicas, não apenas os números de série dos certificados. Isso fecha todos os caminhos de construção de cadeia, independentemente de qual raiz válida o cliente use. A própria Sectigo removeu os cross-signs dos intermediários afetados.
O que ainda não sabemos
Até o momento da publicação, nenhuma das partes envolvidas revelou como as chaves privadas saíram do controle da eMudhra, quando isso ocorreu ou se alguém além do pesquisador Wayne ainda as possui. As possibilidades vão desde um insider mal-intencionado até uma falha em um HSM, um backup vazado ou uma violação da infraestrutura de assinatura. A eMudhra não publicou nenhum aviso em seu repositório de serviços de confiança até 20 de outubro.
O pesquisador q3k demonstrou que é possível verificar a posse da chave publicamente: basta pegar a assinatura de "We have a problem here - Wayne" e verificar com OpenSSL usando a chave pública do certificado intermediário. Uma verificação bem-sucedida prova que o signatário possuía a chave privada no momento da assinatura. Isso estabelece o comprometimento sem, ironicamente, expor a própria chave.
O impacto real e o futuro
Nenhum dos relatórios, incluindo o aviso de segurança da Mozilla (MFSA2026-113), confirmou exploração em ambiente de produção. Isso se deve, em parte, ao fato de que um certificado TLS válido é apenas metade da batalha para um atacante — ele também precisa controlar o DNS do domínio visado ou a rota de IP da vítima. Além disso, o Chrome não encontrou nenhum certificado TLS assinado por esses intermediários registrado nos logs de Certificate Transparency antes de aplicar o bloqueio, o que significa que nenhum certificado fraudulento teria sido confiável por padrão no Chrome.
Por outro lado, o incidente levanta uma questão desconfortável: se o comprometimento não foi explorado em produção, quanto tempo isso levou? A eMudhra é uma das muitas CAs que operam sob o rigoroso regime do CA/Browser Forum, que exige separação de deveres, autorizações multi-pessoas e HSMs altamente auditados. Oito chaves comprometidas simultaneamente apontam para uma falha estrutural — e se isso aconteceu aqui, quantas outras CAs estão igualmente vulneráveis?
A pergunta que fica não é se o próximo comprometimento de uma CA vai acontecer, mas quando — e se a internet está realmente preparada para responder a tempo.
Fontes: heise online, The Hacker News, Mozilla Security Blog
✓ Fontes independentes cruzadas e verificadas antes da publicação
