Falha na eMudhra expõe HTTPS e exige correções em apps
Neste artigo
- Falha na eMudhra deixou oito chaves fáceis de recuperar
- Chrome e Firefox distribuíram bloqueios em outubro
- Correções também alcançam Go e aplicativos da Cloudflare
- Medidas para corrigir a confiança no Windows
- Como interpretar testes e erros de certificado
- Limites do que se sabe sobre exploração
- eMudhra oferece substituição e deixa o mercado SSL/TLS
- Fontes
- Perguntas frequentes
A falha na eMudhra permite que um invasor falsifique certificados HTTPS e se passe por sites diante de aplicativos que ainda confiem nas chaves comprometidas. O ataque exige interceptar a conexão, mas seu alcance vai além dos clientes da certificadora: navegadores, sistemas e programas precisam receber os bloqueios para rejeitar certificados fraudulentos, segundo o Google.
Falha na eMudhra deixou oito chaves fáceis de recuperar
O incidente envolve oito autoridades certificadoras intermediárias: seis ligadas a TLS, usado nas conexões HTTPS, e duas à assinatura de código. Nesse segundo grupo, as chaves poderiam fazer conteúdo malicioso parecer assinado por uma entidade confiável, de acordo com a Microsoft.
Uma autoridade intermediária assina certificados que os aplicativos aceitam por confiarem em sua cadeia de certificação. Quem obtém sua chave privada pode tentar emitir certificados para domínios de terceiros, mesmo quando esses sites usam outra certificadora, como explica a equipe de segurança do Go.
As chaves afetadas usavam a curva P-384, mas seus valores privados eram inferiores a 256. O CERT-In confirmou que isso tornava a recuperação quase instantânea: o defeito estava na geração das chaves.
O pesquisador Scott Helme recuperou as oito em menos de um segundo no próprio computador, usando os certificados públicos. Segundo a eMudhra, os intermediários foram criados em 30 de abril de 2025, e a hierarquia entrou nas listas de confiança dos navegadores em meados daquele ano.
Chrome e Firefox distribuíram bloqueios em outubro
O Chrome recebeu o relato em 17 de outubro de 2026, às 18h05 UTC, e incorporou o bloqueio às 19h45 UTC. O mecanismo CRLSet passou a rejeitar as chaves pelos identificadores SPKI, alcançando certificados que compartilhassem aquelas mesmas chaves, sem exigir atualização ou reinicialização do navegador, conforme o Google.
A Mozilla recebeu a notificação às 20h06 UTC do mesmo dia. A distribuição pelo OneCRL terminou às 22h59 UTC para usuários do Firefox com configurações padrão.
Em 20 de outubro, chegaram Firefox 158.0.1, ESR 115.43.1 e ESR 153.5.1 para alcançar configurações que não recebessem o OneCRL. A biblioteca NSS 3.131.1 removeu a raiz correspondente, segundo a Mozilla.
No Android, o Firefox 158.0.2, lançado em 21 de outubro, corrigiu um problema que impedia alguns clientes de aplicar imediatamente a lista incorporada após a inicialização. Para a proteção distribuída pelo Google Play Services, o Google informa que reiniciar o aparelho pode acionar a atualização correspondente.
Correções também alcançam Go e aplicativos da Cloudflare
Atualizar o navegador não encerra a tarefa para quem mantém serviços ou usa aplicativos com componentes próprios de TLS. Programas podem incorporar certificados e bibliotecas que seguem um ciclo de atualização separado, incluindo aplicações baseadas em Electron, conforme a divulgação técnica do incidente.
O Go iniciou uma resposta emergencial em 19 de outubro e publicou as versões 1.27.3 e 1.26.10 com bloqueio dos intermediários. Foi o primeiro uso da modalidade de lançamento de segurança URGENT, com resposta em aproximadamente sete horas e meia após a notificação.
A distinção entre plataformas importa: Windows e macOS normalmente delegam a verificação às APIs do sistema; no Linux, o Go usa sua própria implementação. Por isso, a equipe adicionou proteção ao runtime, detalha o comunicado do Go.
A Cloudflare indicou estas versões como referências de correção do incidente:
- Cloudflare One Client: 2.5.7 no Android e 1.12.7 no iOS.
- Aplicativo 1.1.1.1: 6.38.11 no Android e 6.31.8 no iOS.
- Cliente desktop: 2026.8.2115.0 para Windows, macOS e Linux.
- cloudflared: 2026.10.2.
Esses números identificam versões corrigidas, sem representar uma lista das versões mais recentes em 30 de outubro. No Cloudflare Tunnel executado em contêiner, a orientação inclui atualizar e reimplantar a imagem corrigida.
Medidas para corrigir a confiança no Windows
A Microsoft orienta combinar a distribuição dos bloqueios com a revisão dos certificados utilizados pelos serviços. Para quem administra máquinas e aplicações, as ações são:
- Permita a chegada das atualizações automáticas de confiança de certificados do Windows e dos componentes do Edge.
- Distribua a lista atualizada de certificados proibidos e as alterações de confiança aos dispositivos Windows desconectados, usando o processo de atualização adotado pela organização.
- Identifique os certificados que dependam das sete entradas removidas pela Microsoft.
- Obtenha certificados substitutos ou uma cadeia alternativa confiável para os serviços identificados.
As sete entradas citadas pela Microsoft correspondem às alterações em seu ecossistema; o incidente abrange oito chaves intermediárias.
A revisão das cadeias também precisa considerar assinaturas cruzadas. Os oito intermediários receberam assinaturas pela raiz AAA Certificate Services, da Sectigo, em maio de 2025, criando caminhos adicionais de confiança, segundo Scott Helme.
Como interpretar testes e erros de certificado
Um resultado aprovado no navegador não comprova a proteção de serviços em segundo plano ou de outros aplicativos. Eles podem consultar repositórios de confiança e verificadores diferentes, alerta a Cloudflare.
O verificador público do incidente também exige cuidado na leitura: uma conexão malsucedida pode indicar rejeição do certificado ou apenas um problema de rede. Em ambientes com proxy que intercepta TLS, o resultado pode refletir a confiança do próprio proxy, conforme a documentação técnica, que oferece cadeias para verificação offline e listas dos certificados envolvidos.
Após o bloqueio, serviços legítimos vinculados à hierarquia podem apresentar erros. Nessa situação, a orientação é revisar a cadeia e substituir os certificados dependentes; a Cloudflare recomenda não desativar a verificação de certificados para contornar a falha.
Limites do que se sabe sobre exploração
A avaliação do CERT-In de 21 de outubro de 2026 não estabelecia exploração maliciosa confirmada. Esse retrato tem data delimitada e não comprova ausência de ataques posteriores. Vítimas, exploração e serviços afetados especificamente no Brasil não foram confirmados.
O Google informou que não havia certificados TLS dos seis intermediários nos registros de Certificate Transparency antes do bloqueio. Isso sustenta a proteção dos clientes que exigiam esse registro, mas deixa desconhecido o histórico de exploração contra clientes sem essa exigência, conforme o Google e a divulgação técnica.
eMudhra oferece substituição e deixa o mercado SSL/TLS
Em 22 de outubro de 2026, a eMudhra anunciou sua saída voluntária do negócio global de certificados SSL/TLS, responsável por aproximadamente 1% de sua receita. Até a publicação desta matéria, a empresa havia anunciado substituição gratuita dos certificados afetados por certificados de parceiros, com manutenção dos serviços de revogação e consulta de status durante a transição, segundo o comunicado oficial.
A Sectigo está entre as opções oferecidas. Clientes do CertiNext podem solicitar a substituição pelo acesso ao serviço; os demais devem procurar o suporte oficial, conforme a orientação da eMudhra. A disponibilidade dessa substituição especificamente no Brasil não foi confirmada.
Para quem administra sites, a Let’s Encrypt também oferece emissão e renovação automatizada de certificados HTTPS, gratuitamente, sob operação do ISRG. Trocar o certificado do servidor resolve sua dependência da cadeia afetada; os aplicativos dos visitantes ainda precisam receber os bloqueios das chaves comprometidas.
Fontes
- Google: proteção de usuários do Chrome e Android
- Microsoft: resposta ao comprometimento das chaves
- Mozilla: bloqueios e versões corrigidas do Firefox
- Go: resposta emergencial ao incidente
- CERT-In: avaliação técnica
- Cloudflare: correções e orientações para aplicativos
- eMudhra: comunicado sobre o incidente
- Scott Helme: recuperação das oito chaves
- Divulgação técnica: verificadores e cadeias afetadas
Perguntas frequentes
Uma das chaves privadas era realmente o número 4?
Sim. O pesquisador Scott Helme identificou esse valor e também documentou chaves iguais a 56 e 115.
A falha comprometeu o algoritmo P-384?
O problema estava nos valores usados para gerar aquelas chaves. O CERT-In não identificou uma vulnerabilidade no algoritmo P-384.
O bloqueio do Firefox exigia reiniciar o navegador?
Nas configurações padrão, o OneCRL chegou automaticamente, sem reinicialização. A Mozilla também publicou versões para atender outras configurações e corrigir a aplicação da lista no Android.
As assinaturas digitais e o eSign indianos da eMudhra foram afetados?
Segundo o CERT-In, a infraestrutura indiana desses serviços era separada e permaneceu fora do incidente analisado.
Usar um certificado de outra empresa elimina o risco?
Para o visitante, a proteção exige que o aplicativo rejeite as chaves comprometidas. A certificadora escolhida pelo site verdadeiro, sozinha, não impede sua personificação diante de um cliente vulnerável.
