Chaves de oito certificados intermediários da eMudhra são comprometidas; Cloudflare já aplicou correções

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 estavam comprometidas. Esses certificados eram aceitos por navegadores, sistemas operacionais e também dentro da própria Cloudflare. Como as chaves são fracas, um atacante consegue forjar certificado para qualquer domínio e se passar por servidores para interceptar ou alterar tráfego. A empresa diz que sua revisão de segurança não identificou exploração ativa nos serviços dela.

A mitigação priorizou serviços que usam certificados públicos para autenticar endpoints remotos, como proxies que falam com origens e aplicações que chamam APIs externas. Também foram atualizados trust stores compartilhados e imagens base, seguidos de reloads, restarts e deploys de imagem para ativar as mudanças. Aplicações com trust store embutido ou customizado passam por avaliação separada. A Cloudflare ressalta que o problema está na autenticação por certificado, não nos algoritmos de criptografia do TLS.

Para quem opera origens, sobra trabalho. Atualizar o SDK sozinho pode não mudar a política, porque a verificação pode ser delegada a biblioteca HTTP, runtime, sistema operacional ou configuração própria. Depois do patch, erros de certificado podem aparecer nos dashboards, e a orientação é não resolvê-los desligando a verificação. A Cloudflare recomenda olhar a árvore de dependências, reconstruir imagens afetadas e validar pelo caminho TLS real da aplicação, já que um teste no navegador ou com curl não prova que um serviço em segundo plano está protegido.

Em 21 de outubro de 2026, o CEVIU noticiou "Oito certificados intermediários da eMudhra são comprometidos e acendem alerta na Internet", com o alerta inicial. Em 22 de outubro de 2026, em "Oito certificados TLS intermediários da eMudhra com chaves de 3 a 8 bits acendem alerta na internet", o foco foi o tamanho ínfimo das chaves. Agora o centro é a resposta operacional: correções já aplicadas em CDN, Zero Trust e Tunnel, atualizações de clientes e o que as equipes precisam fazer nas próprias origens e dependências.

Para quem opera plataforma, a leitura é que o incidente vira tarefa de inventário de trust stores. Imagens base, runtimes e bibliotecas com bundle próprio de CAs são onde o risco pode ficar parado. Navegadores resolvem com revogação rápida, mas workloads em containers dependem de rebuild e redeploy. Vale tratar a capacidade de atualizar a confiança sem esperar release como requisito de operação.