eMudhra tem chaves privadas de oito CAs intermediárias comprometidas

Oito certificados de CAs intermediárias da eMudhra tiveram suas chaves privadas comprometidas. Seis eram usados para TLS e aceitos pelos programas de raízes da Apple, Chrome, Microsoft e Mozilla; os outros dois eram destinados à assinatura de código e confiados pela Microsoft.

O risco não se limita à eMudhra. Uma chave intermediária comprometida permite criar certificados falsos que parecem legítimos para qualquer sistema cuja cadeia de confiança ainda aceite a raiz correspondente. Navegadores reagiram com listas de bloqueio, mas aplicações, runtimes e dispositivos sem atualização podem continuar vulneráveis.

Chaves quase sem entropia

Segundo a apuração da InfoQ, não há evidência de invasão aos sistemas da eMudhra. O problema identificado está no mecanismo de geração das chaves privadas: em vez de números aleatórios grandes, elas eram compostas por zeros, exceto pelo último byte.

Os valores finais encontrados foram 4, 56, 66, 115, 155, 156, 230 e 237. Esse espaço reduzido torna trivial enumerar as possibilidades, derivar as chaves públicas correspondentes e compará-las com certificados de CAs em uso.

Fato apurado: as chaves devem ser consideradas comprometidas porque podiam ser reconstruídas, não porque tenha sido comprovado um vazamento ou ataque à infraestrutura da empresa.

Leitura editorial: esse detalhe muda a investigação de causa. Rotacionar credenciais é necessário, mas não basta se o processo que gera, valida ou provisiona as chaves continuar aceitando material criptográfico previsível.

Por que a cadeia continua confiável

Uma CA intermediária herda confiança de uma raiz instalada no sistema. Enquanto essa raiz e a cadeia relacionada permanecerem aceitas, um certificado forjado pode passar pela validação criptográfica convencional.

Isso abre espaço para personificação de sites e serviços em ataques man-in-the-middle. O certificado falso ainda precisa ser apresentado à vítima, mas sistemas desatualizados não conseguem distingui-lo apenas verificando assinatura, validade e encadeamento.

Os navegadores possuem listas de bloqueio atualizadas em segundo plano e conseguiram rejeitar especificamente as intermediárias afetadas. Grande parte do restante do ecossistema não oferece mecanismo equivalente para filtrar CAs intermediárias rapidamente.

Projetos passaram então a remover a raiz emSign ECC Root CA - G3 de seus trust stores. A medida bloqueia as cadeias comprometidas, porém também invalida certificados legítimos anteriormente emitidos por outras CAs encadeadas à mesma raiz. É um trade-off entre reduzir imediatamente a superfície de fraude e preservar compatibilidade.

Atualização precisa alcançar aplicações

Pacotes de certificados de Arch, Debian, Gentoo, Fedora e Ubuntu foram atualizados. Electron, Go, pip, Python certifi, rustls-webpki, Rust webpki-roots e uv também aparecem entre os projetos que reagiram, conforme o relato da InfoQ.

No ecossistema Python, Simon Willison registra as versões uv 0.13.4, pip 26.2.2 e certifi 2026.10.19 com listas atualizadas. Instalar uma dessas versões, contudo, não garante que todos os processos em produção estejam usando o trust store corrigido.

Recomendação prática: o inventário deve separar aplicações que usam certificados do sistema, bibliotecas que empacotam sua própria lista e arquivos de CAs copiados para imagens ou artefatos. Também é necessário verificar workloads já implantados, não apenas dependências declaradas no repositório.

Essa distinção importa porque uma atualização do sistema operacional não substitui automaticamente um arquivo de certificados incorporado à aplicação. Por outro lado, runtimes que delegam confiança ao sistema podem receber a correção sem alteração no código. Dart, por exemplo, deixou de embutir seu arquivo de CAs a partir da versão 3.13.

mTLS amplia o impacto

O cenário mais direto não é necessariamente um ataque contra HTTPS público. Aplicações que usam raízes da Web PKI para autenticação de clientes em mTLS podem aceitar um certificado forjado como identidade válida.

Nesse caso, o invasor não precisa interceptar tráfego: basta apresentar ao endpoint uma credencial encadeada a uma intermediária ainda confiável. O risco é maior quando o verificador de mTLS desconhece a revogação ou aceita usos de chave inadequados como substitutos.

Recomendação prática: equipes devem identificar endpoints que autorizam clientes apenas com base em uma cadeia pública. A validação precisa incluir a origem esperada do certificado, suas extensões de uso e, quando aplicável, uma lista de autoridades restrita ao domínio interno.

Registros DNS CAA não resolvem esse incidente. Eles orientam CAs legítimas sobre quais autoridades podem emitir para um domínio, mas quem já possui uma chave comprometida pode simplesmente ignorar a consulta. Certificate Transparency também só ajuda clientes que consultem ou exijam evidência dos registros.

Quando agir e quais são os limites

A prioridade é alta para serviços com trust stores próprios, imagens antigas, sistemas fora de suporte, dispositivos sem atualização automática e autenticação mTLS baseada na Web PKI. Além de atualizar pacotes, faz sentido testar novamente as cadeias legítimas, porque a remoção da raiz pode causar indisponibilidade.

Não é possível concluir, com o material disponível, que certificados falsos tenham sido usados em ataques ou que a eMudhra tenha sofrido invasão. Também não basta confirmar que o navegador está protegido: isso não demonstra que CLIs, agentes, runtimes, containers e serviços de backend usam a mesma política.

A correção faz sentido mesmo com possível quebra de compatibilidade quando a aplicação ainda confia na cadeia afetada. O que não faz sentido é tratar a atualização do navegador ou do host como evidência suficiente sem mapear de onde cada componente realmente carrega suas autoridades confiáveis.