eMudhra: a falha que quase permitiu desviar recompensas de validadores do Ethereum

Uma falha em certificados digitais emitidos pela autoridade certificadora indiana eMudhra quase permitiu que atacantes desviassem recompensas de validadores do Ethereum. Os clientes Teku e Besu lançaram correções de emergência em 26 e 27 de outubro. A vulnerabilidade nunca foi explorada, segundo os desenvolvedores.

O que quebrou na eMudhra

Oito autoridades certificadoras intermediárias operadas pela eMudhra geraram suas chaves privadas com aleatoriedade insuficiente. Isso permitia recalcular essas chaves a partir de dados públicos nos certificados, basicamente recriando credenciais que deveriam ser secretas, segundo o crypto.news.

A Microsoft identificou que seis dos certificados afetados protegiam conexões de internet e dois estavam associados à assinatura de código. Quatro raízes específicas foram sinalizadas como comprometidas: emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 e AAA Certificate Services.

Como isso chegaria a um validador do Ethereum

Teku e Besu rodam sobre ambientes Java, que não verifica revogação de certificado por padrão. Na prática, isso significa que, mesmo depois de navegadores e outros sistemas pararem de confiar nos certificados da eMudhra, o Java continuaria aceitando-os como válidos.

Com uma chave privada recalculada, um atacante poderia forjar um certificado e posicionar-se entre o validador e um serviço externo (ataque man-in-the-middle). Isso permitiria manipular o bloco que o validador estava preparando para propor, desviando as taxas de transação para um endereço controlado pelo invasor, segundo o crypto.news e a KuCoin News.

O que foi corrigido e quando

As equipes de desenvolvimento lançaram as versões corrigidas em sequência:

• Besu 26.10.2, em 26 de outubro de 2026
• Teku 26.10.3, em 27 de outubro de 2026

Ambas as atualizações removem a confiança nas quatro raízes de certificado comprometidas das imagens Docker oficiais dos clientes.

Nós padrão não foram afetados, mas há uma pegadinha para quem opera sozinho

Os desenvolvedores do Teku confirmaram que um nó padrão na mainnet não foi afetado e não precisa de nenhuma ação, segundo a KuCoin News. Também não há registro de nenhuma exploração real da falha até o momento.

O alerta é para operadores de instalações isoladas, com ambientes Java gerenciados separadamente dos contêineres oficiais. Nesses casos, instalar a versão mais recente do Teku ou do Besu não remove automaticamente os certificados comprometidos do armazém de certificados Java da máquina, segundo a Analytics Insight. É preciso atualizar esse armazém manualmente. Quem ainda usa Java 26, que já chegou ao fim do suporte, precisa migrar para uma versão mais recente da linguagem antes mesmo de lidar com os certificados.

Por que isso importa para quem faz staking no Brasil

Validadores de Ethereum, inclusive os operados por brasileiros em casa ou em provedores de infraestrutura, dependem de uma cadeia de confiança que vai além do código da blockchain: sistema operacional, ambiente de execução (Java, no caso) e certificados de terceiros usados para autenticar conexões. Uma falha numa autoridade certificadora na Índia conseguiu, em tese, criar uma rota para desviar recompensas de blocos em validadores no mundo todo, incluindo operações brasileiras.

Para quem roda nó próprio fora de configurações padrão de provedores de cloud ou de serviços de staking delegado, o episódio reforça um ponto prático: manter o cliente de validação atualizado não basta quando o ambiente Java é gerenciado separadamente. Vale checar a versão instalada do Teku ou Besu e, se a operação for isolada, confirmar que o armazém de certificados do sistema também foi atualizado.