Oito certificados intermediários da eMudhra são comprometidos e acendem alerta na Internet

O ponto central do incidente é a confiança, não a criptografia. Em 19 de outubro de 2026, por volta das 17h UTC, a Cloudflare soube que as chaves privadas de oito certificados intermediários da eMudhra foram comprometidas. Como as chaves são fracas, um atacante pode emitir certificado forjado para qualquer domínio e se passar por servidor para interceptar ou alterar tráfego. Esses intermediários eram aceitos por navegadores, sistemas operacionais e pela própria Cloudflare. A empresa não identificou exploração ativa em seus serviços e priorizou o que autentica endpoints remotos com certificados públicos, como proxies que falam com origens e aplicações que chamam APIs externas.

Para quem desenvolve, o recado é olhar abaixo do SDK. A verificação pode ficar com a biblioteca HTTP, o runtime, o sistema operacional ou uma trust store própria, então atualizar só o SDK pode não mudar a política. Atualize dependências (inclusive as indiretas), reconstrua imagens e confirme se é preciso reload, restart ou redeploy. Se aparecerem erros de certificado depois do patch, não desative a verificação: isso tira justamente a proteção que a correção devolve. Os testes de Dennis Jackson, da Mozilla, só valem para o caminho de verificação testado. Um teste de navegador ou de curl não prova que um serviço em segundo plano com outro verificador está protegido.

A cobertura do CEVIU vinha mostrando a confiança em certificados sob pressão por vários lados. Em 15 de abril de 2026, a falha CVE-2026-5194 na wolfSSL permitia certificados forjados passarem na verificação. Em 9 de setembro de 2026, a matéria sobre chaves RSA de 512 bits em raízes antigas da E-Certify e, em 8 de outubro de 2026, a dos certificados TLS fraudulentos para o Google via sequestro de ccTLDs apontavam na mesma direção. Agora o problema chega a intermediárias amplamente confiáveis, com chaves fracas e emissão forjada possível para qualquer domínio.

Uma CA confiável com chave fraca vale para todo o ecossistema, e o ritmo da correção depende de cada stack. Navegadores resolveram rápido com revogação rápida (como CRLSets), mas serviços de backend, imagens e apps com trust store própria exigem ação manual. O episódio de 5 de maio de 2026, com o Defender removendo raízes da DigiCert, mostra o outro lado: mexer em trust stores sem cuidado também quebra sistemas.