Cloudflare alerta sobre oito certificados eMudhra com chaves fracas
Chaves privadas de oito intermediários eMudhra foram comprometidas. A Cloudflare já aplica mitigações e pede atualizações a clientes e desenvolvedores.
Foto: Nothing Ahead (Pexels)
A Cloudflare informou que, em 19 de outubro de 2026, por volta das 17h UTC, tomou conhecimento de que chaves privadas ligadas a oito certificados intermediários da autoridade certificadora indiana eMudhra estavam comprometidas. Esses certificados eram amplamente confiados por navegadores, sistemas operacionais e também dentro da própria Cloudflare.
Como as chaves são fracas, um invasor pode forjar um certificado para qualquer domínio e usá-lo para se passar por servidores, interceptando ou alterando o tráfego. A empresa descreveu o episódio como um incidente grave de segurança, com implicações para a internet como um todo, e afirmou que a revisão interna não identificou exploração ativa nos serviços da Cloudflare.
O que aconteceu
Segundo o blog da Cloudflare, a prioridade imediata foi aplicar correções em serviços críticos antes da divulgação pública da vulnerabilidade. Foram lançadas atualizações para os clientes Cloudflare One — também conhecidos como WARP ou aplicativo 1.1.1.1 — e para o Cloudflare Tunnel (cloudflared). Mitigações também foram implantadas em produtos de CDN, desenvolvimento e Zero Trust. Clientes de Zero Trust com Gateway e cliente atualizado ficam protegidos de forma automática, de acordo com a empresa.
A resposta incluiu a atualização de serviços que usam certificados públicos para autenticar endpoints remotos, como proxies que se conectam a origens e aplicações que chamam APIs externas. Em paralelo, a Cloudflare atualizou repositórios de confiança compartilhados, imagens-base e outras bases comuns, além de recarregar, reiniciar e fazer novo deploy do que era necessário. Aplicações com lojas de confiança embutidas ou personalizadas receberam avaliação e correções separadas. O trabalho trata da autenticação baseada em certificados, e não de uma falha nos algoritmos de criptografia do TLS (Transport Layer Security), o protocolo que protege conexões HTTPS.
No calendário divulgado, as atualizações de segurança do Cloudflare One Client e do app WARP saíram em 20 de outubro às 2h UTC (exceto o agente One no iOS, ainda pendente de revisão na loja). O patch do cloudflared foi publicado às 9h15 UTC, e as mitigações no CDN e no Zero Trust do lado do servidor ficaram totalmente implantadas às 19h20 UTC.
A Cloudflare recomenda que clientes atualizem os apps e o tunnel para as versões indicadas no post, revisem lojas de confiança usadas em autenticação mútua TLS e verifiquem certificados de origem em modos de criptografia estritos. Desenvolvedores devem olhar além do kit de desenvolvimento de software (SDK): a verificação pode depender da biblioteca HTTP, do runtime da linguagem, do sistema operacional ou de uma configuração própria. Atualizar só o SDK pode não mudar a política de confiança. A empresa alerta para não resolver erros de certificado desativando a verificação. Há listas de pacotes corrigidos reunidas de forma colaborativa por Dennis Jackson, da Mozilla, e um site de testes — um teste bem-sucedido no navegador não prova que um serviço em segundo plano esteja protegido.
O que isso pode mudar
O impacto tende a ser desigual. Mantenedores de navegadores puderam remediar o problema com rapidez, em muitos casos com mecanismos de revogação ágil, como os CRLSets do Chrome. Na Cloudflare, parte dos produtos já usa abordagem semelhante. A empresa sugere que, daqui para frente, lojas de confiança deixem de ser listas estáticas de autoridades raiz e passem a incorporar, com mais agilidade, revogações e chaves de transparência de certificados — caminhos como o projeto upki apontam nessa direção.
Para empresas e equipes de software, a crise pode acelerar a rotina de auditar dependências indiretas, reconstruir imagens e validar o caminho real de TLS de cada aplicação. Ainda há trabalho de remediação em andamento, e alguns clientes precisarão agir em servidores de origem e configurações que operam por conta própria. Em tese, a velocidade com que o ecossistema WebPKI — a infraestrutura pública de chaves que sustenta o HTTPS — conseguir propagar desconfiança desses intermediários pode definir quanto tempo um atacante ainda teria janela para abusar das chaves fracas.
Fontes: Cloudflare Blog – 8 eMudhra certificates are compromised
Leia mais em: mundodosnegocio.com.br