A Cloudflare publicou uma atualização sobre a exploração e a correção de oito chaves privadas intermediárias da eMudhra que poderiam ser recuperadas a partir de certificados públicos. As chaves incluíam valores como 4, 56, 66 e 115, tornando possível que qualquer pessoa derivasse as chaves de assinatura correspondentes e criasse certificados que clientes vulneráveis poderiam aceitar.
A empresa afirma que todos os sistemas de alta prioridade da Cloudflare já foram corrigidos. Seus proxies voltados às origens dos clientes, que administram a maioria das conexões de saída, foram atualizados poucas horas depois de o problema ser identificado, em 19 de outubro de 2026. Em seguida, a Cloudflare usou uma revisão de seu código-fonte assistida por IA para localizar outros sistemas que confiavam nas chaves fracas e atribuiu o trabalho de correção com base em seu possível impacto.
Para monitorar possíveis abusos, a Cloudflare adicionou registros ao seu serviço de saída Pingora. Durante a semana posterior à implementação dos registros, registrou cerca de 22.000 tentativas de handshakes TLS envolvendo certificados assinados com as chaves afetadas da eMudhra. Aproximadamente dois terços envolveram sites de teste, incluindo emudhra.we-have-a-problem.com. A maioria das tentativas restantes veio de origens que pareciam ter configurado certificados assinados pelo intermediário fraco.
Cerca de 160 handshakes envolveram certificados cujos Nomes Alternativos do Assunto se referiam a domínios não relacionados ao Server Name Indication solicitado. Alguns estavam associados a dispositivos de Internet das Coisas voltados ao consumidor. A Cloudflare afirmou que esses certificados pareciam ter sido criados depois que a vulnerabilidade se tornou pública, com pelo menos um datado de 20 de outubro, às 18:19 UTC, menos de uma hora depois da publicação do relatório da Mozilla.
No entanto, a empresa afirmou que as evidências atualmente não indicam que os certificados tenham sido usados para interceptar conexões da Cloudflare. Os certificados frequentemente pareciam ser os certificados padrão dos próprios servidores, usavam nomes que não teriam passado pela verificação do nome do host e, em vários casos, eram apresentados a partir de vários locais da Cloudflare. A Cloudflare também não relatou sinais indiretos de uma campanha de interceptação direcionada.
A empresa mediu separadamente quantos visitantes ainda confiavam na cadeia de certificados comprometida. Ela usou duas conexões de teste em uma parte de suas páginas de desafio: um endpoint fornecia um certificado assinado pela eMudhra e o outro inicialmente funcionava como controle, com um certificado assinado regularmente. Durante a semana seguinte, a Cloudflare coletou 50 milhões de testes, alertando que os resultados foram afetados por tráfego de bots e incluíam apenas clientes capazes de executar JavaScript.
As medições indicaram que os navegadores convencionais atuais estavam em grande parte corrigidos, enquanto navegadores antigos e navegadores incorporados continuavam mais expostos. A Cloudflare estimou que de 30% a 40% do tráfego do Android WebView ainda aceitava a cadeia afetada. Mais da metade dos testes de várias grandes redes continuava a aceitá-la, embora a empresa tenha observado que a composição do tráfego era fortemente influenciada por bots não confirmados e que os dados deveriam ser tratados como sugestivos, e não conclusivos.
A Cloudflare recomendou que usuários e desenvolvedores instalassem as atualizações relevantes, com atenção especial para desenvolvedores que usam macOS. A empresa também encaminhou os clientes a orientações para produtos como WARP e Tunnel. Olhando para o futuro, a Cloudflare afirmou que deseja mecanismos mais rápidos para atualizar decisões de confiança, incluindo o uso mais amplo de sistemas capazes de distribuir informações de revogação e de Transparência de Certificados sem depender de armazenamentos de confiança estáticos.
Fontes: Cloudflare Blog.