TL;DR
- Teku 26.10.3 e Besu 26.10.2 removem a confiança nas raízes de certificados vinculadas à eMudhra após chaves intermediárias comprometidas exporem algumas configurações de validador baseadas em HTTPS ao risco de imitação.
- Os nós padrão do Teku mainnet não foram afetados, e nenhuma exploração foi relatada, enquanto o risco dependia dos validadores que se conectavam a serviços externos por HTTPS.
- Usuários do Docker devem atualizar as imagens do cliente, enquanto operadores independentes devem aplicar patches separadamente no Java; usuários do Java 26 precisam migrar para builds suportadas do Java 25.
Teku e Besu lançaram atualizações de segurança após chaves da autoridade certificadora eMudhra comprometidas exporem configurações de nodes da Ethereum a conexões HTTPS falsificadas. Teku’s release notes recomendam a versão 26.10.3, que remove a confiança em quatro raízes de certificado afetadas das imagens Docker, enquanto a Besu lançou a versão 26.10.2. As atualizações abordam a confiança de certificados na camada de distribuição de software, e não uma falha nas regras de consenso da Ethereum. Nodes padrão da mainnet da Teku não foram afetados, mantendo o incidente distinto de vulnerabilidades no protocolo Ethereum.
Chaves de certificado comprometidas criaram risco de imitação
Pesquisadores descobriram que chaves privadas para oito autoridades de certificado intermediárias da eMudhra puderam ser recuperadas porque foram geradas com aleatoriedade insuficiente. Embora os certificados tenham sido revogados, o Java não verifica a revogação por padrão, deixando ambientes de execução capazes de aceitar certificados falsificados. Um atacante posicionado entre um node e um serviço HTTPS poderia, portanto, se passar por esse endpoint em configurações vulneráveis. O episódio reforça por que Ethereum client diversity and operational security vão além do código de consenso.
Os cenários de maior risco envolviam validadores se conectando a serviços externos por meio de HTTPS. Um endpoint falsificado poderia manipular informações de construção de blocos, redirecionar destinatários de taxas ou obter assinaturas por meio de um assinante externo imitado. O Teku afirmou que um atacante poderia causar um cliente validador que usa um nó de beacon remoto a propor um bloco pagando taxas para o endereço do atacante. O risco dependia da posição na rede e das configurações do serviço remoto, não apenas em executar Teku ou Besu. Nenhuma exploração foi relatada.
O Teku 26.10.3 remove a confiança para emSign ECC Root CA G3, emSign Root CA G1, emSign Root CA G2 e AAA Certificate Services nas imagens Docker. A atualização do Besu aplica a mesma abordagem. Operadores que executam binários diretamente devem atualizar o Java separadamente, pois as atualizações dos clientes não substituem o repositório de certificados do ambiente de execução do host. Portanto, implantações Docker e autônomas exigem caminhos de correção diferentes. Essa distinção é relevante após os incidentes na infraestrutura de validador Ethereum mostrarem como dependências fora do protocolo podem afetar operações de staking.
O Java 26 cria uma complicação porque atingiu o fim da vida útil e não receberá a compilação corrigida necessária, o que significa que os operadores afetados precisam migrar para o Java 25. A rede peer-to-peer do ethereum não foi exposta porque não depende dessas autoridades certificadoras. As correções reduzem o risco de armazenamento de confiança de terceiros sem corrigir uma exploração ativa no mainnet nem alterar o protocolo do ethereum. O episódio segue outros trabalhos de segurança, incluindo a correção do encaminhamento de depósitos Glamsterdam, destacando como a segurança dos validadores depende do código do protocolo e da infraestrutura de suporte.