Na sexta-feira, 16 de outubro de 2026, às 18h05 UTC, a equipe do Chrome Root Program recebeu uma denúncia de um pesquisador de segurança que se identifica apenas como "Wayne": oito certificados intermediários de uma autoridade de certificação indiana, a eMudhra (que opera sob a marca emSign), tinham chaves privadas geradas com entropia criptográfica tão fraca que qualquer pessoa poderia recuperá-las testando apenas 256 valores possíveis.
Em vez de simplesmente relatar o problema aos fornecedores, o pesquisador fez o que todo mundo faria: assinou uma mensagem de teste com cada uma das oito chaves comprometidas e enviou as provas diretamente às equipes de segurança da Mozilla, Microsoft, Apple e Google. O resultado foi uma resposta de fim de semana que forçou atualizações de emergência em toda a base de software do mundo.
O que aconteceu de errado
A eMudhra é uma autoridade de certificação (CA) de confiança que emite certificados TLS para milhares de sites, governos e serviços financeiros na Índia e em outros mercados emergentes. O problema começa em abril de 2025, quando um script defeituoso gerou um segundo conjunto de chaves privadas P-384 significativamente mais fracas. Por engano, essas chaves fracas foram selecionadas para assinaturas de certificado porque tinham rótulos visualmente semelhantes aos das chaves geradas corretamente.
O resultado foi catastrófico. Todas as oito chaves tinham valores menores que 2⁵⁶ — ou seja, menores que 72 quadrilhões — o que, em termos práticos, significa que qualquer pessoa com acesso a um computador doméstico moderno pode testar todos os valores possíveis em questão de minutos. O pesquisador Flüpke publicou no GitHub uma das chaves comprometidas: o valor da chave privada para o certificado "EM OV TLS CA – G3C" da eMudhra era simplesmente o número 4.
Por que certificados intermediários são piores que certificados de folha
Perder uma chave de certificado de folha — o tipo que um site como google.com ou seu banco usa — é um problema local. O administrador do domínio gera um novo par de chaves, solicita um substituto e o certificado antigo expira ou é revogado. É simples.
Um certificado intermediário é diferente. Os intermediários existem para manter as chaves-raiz offline e protegidas em módulos de segurança de hardware (HSM). A raiz delega autoridade de assinatura ao intermediário, que emite certificados para o público. Um invasor que controla a chave privada de um intermediário herda toda a confiança colocada naquela ramificação da hierarquia. Ele pode cunhar certificados TLS válidos para qualquer domínio e pular as verificações de validação de domínio que CAs legítimas aplicam.
Além disso, esses certificados intermediários eram "cross-signados" pela Sectigo's AAA Certificate Services — ou seja, um cliente podia construir uma cadeia de confiança válida que passava por uma raiz diferente. Se um navegador rejeitava apenas a raiz da eMudhra, um atacante ainda podia apresentar uma cadeia que rodava pela Sectigo.
A resposta dos browsers
A Mozilla reagiu rapidamente. Recebeu a denúncia às 20h06 UTC do dia 17 de outubro e empurrou um update de blocklist através do OneCRL, no sistema de configurações remotas da Firefox, às 22h59 UTC. Isso força o Firefox a rejeitar os certificados específicos independentemente de sua validade criptográfica ou data de expiração.
O Google Chrome também bloqueou os seis intermediários comprometidos autorizados a emitir certificados naquela data, através de uma atualização da CRLSet. Como essa atualização bloqueia por SPKI (Subject Public Key Info), os usuários do Chrome foram imediatamente protegidos contra todos os certificados que compartilhavam essas chaves, sem necessidade de atualização do navegador ou reinicialização.
A Apple adicionou proteções em 19 de outubro, e o Android recebeu um update equivalente através do Google Play Services.
O problema que ninguém vê: a cauda longa de software embutido
Aqui está a parte que ninguém conta nas reportagens: browsers podem empurrar blocklists de emergência para centenas de milhões de usuários em horas. O resto da internet é muito mais lento e fragmentado.
No dia 19 de outubro, a equipe do Go lançou atualizações de segurança emergenciais, nas versões 1.27.3 e 1.26.10, com o CVE-2026-111943. Diferente de um navegador web que depende da loja de certificados do sistema operacional hospedeiro, a biblioteca padrão do Go `crypto/x509` implementa sua própria lógica de verificação de certificados e empacota seus próprios mecanismos de verificação de confiança.
Isso cria um trabalho real para empresas. Se um microserviço backend foi compilado com uma versão mais antiga do Go, atualizar o toolchain no host não faz absolutamente nada para o binário em execução, que já contém a lógica de verificação antiga. Garantir o ambiente significa encontrar cada binário Go compilado, atualizar o pipeline de build, recompiler contra o toolchain corrigido e fazer deploy em produção.
Um administrador pode corrigir todas as estações de trabalho Windows e macOS e ainda ter dúzias de clientes de API internos, runners de pipelines de CI/CD e aplicações containerizadas que nunca viram as atualizações do OneCRL da Mozilla ou da Apple. Nesses ambientes, um handshake TLS bem-sucedido apenas mostra que o cliente aceitou o certificado sob suas regras de validação desatualizadas. Não diz nada sobre se a conexão é segura.
O que a eMudhra precisa provar agora
Autoridades de certificação são esperadas para manter separação de deveres, autorização multi-pessoa e módulos de segurança de hardware fortemente auditados. Oito chaves intermediárias comprometidas ao mesmo tempo apontam para uma falha sistêmica, não para um acidente isolado.
A empresa atribuiu o problema a um erro de script, mas isso levanta questões que precisam ser respondidas: por que o script gerou chaves tão fracas? Por que chaves fracas com rótulos semelhantes foram selecionadas ao invés das corretas? Por que a validação de entropia não bloqueou essa operação?
A eMudhra já revogou os oito certificados comprometidos e suspendeu a emissão de novos certificados sob sua raiz G3. A empresa comprometeu-se a trabalhar com assinantes impactados para migrar clientes para fora da raiz afetada, o emSign ECC Root CA - G3.
O sistema de confiança da web inteira depende da premissa de que cada CA é impenetrável. Com oito chaves quebradas por um script defeituoso, essa premissa parece mais um desejo do que uma garantia — e deixa uma pergunta sem resposta: quantas outras CAs no mundo ainda operam com falhas equivalentes, esperando que ninguém descubra?
Fontes: BleepingComputer, Google Security Blog, The CyberSec Guru
✓ Fontes independentes cruzadas e verificadas antes da publicação
