- Consensys identifica risco de assinatura ligado a certificados eMudhra em deploys do Web3Signer
- Instalações com configuração padrão não estão expostas, segundo as equipes de segurança
- Operadores com trust store Java customizada precisam revisar controle de acesso imediatamente
A Consensys emitiu um alerta técnico para operadores de infraestrutura de Ethereum que utilizam o Web3Signer, serviço remoto de assinatura usado por validadores, custodiantes e mesas institucionais. O aviso trata de risco associado a certificados emitidos pela autoridade certificadora indiana eMudhra e à forma como determinadas instalações confiam neles.
Segundo as equipes envolvidas na análise, deployments que rodam com os parâmetros padrão do Web3Signer não estão afetados. O problema aparece em ambientes onde operadores modificaram a trust store Java — o repositório de certificados raiz que o aplicativo aceita como confiáveis — e acabaram incluindo cadeias de certificação que não deveriam ter poder sobre o canal de assinatura.
O Web3Signer funciona como intermediário entre a chave privada do validador e o cliente de consenso. Ele recebe requisições, verifica e devolve assinaturas. Em arquiteturas institucionais, esse componente costuma ficar isolado em rede separada, com autenticação mútua via TLS.
É aí que a trust store entra. Se ela aceita certificados de uma autoridade ampla demais, o modelo de confiança do canal fica mais frouxo do que o operador imagina. Na prática, a camada que deveria autorizar apenas clientes específicos passa a validar qualquer certificado emitido por aquela CA.
A Consensys recomenda revisão imediata de controle de acesso nesses casos. A orientação é restringir a trust store a certificados próprios da operação, não a raízes públicas genéricas. Documentação e detalhes de configuração estão disponíveis no repositório oficial do Web3Signer.
Risco é operacional, não de protocolo
Vale separar as coisas. Nenhuma vulnerabilidade foi encontrada na camada de consenso do Ethereum, nem em clientes como Besu, Teku, Lighthouse ou Prysm. O vetor descrito depende de uma decisão de configuração feita pelo próprio operador.
Esse tipo de incidente tem se repetido. Em outubro, o Ethereum adiou o Glamsterdam na testnet após alerta de auditoria, mostrando que boa parte dos riscos atuais da rede está em infraestrutura periférica, não no núcleo. Semanas antes, a carteira Electrum corrigiu falha crítica em lógica de transações — outro caso de software de borda, não de blockchain.
Historicamente, autoridades certificadoras já foram o elo fraco de sistemas críticos. O colapso da holandesa DigiNotar, em 2011, após emissão fraudulenta de certificados, levou navegadores a removerem a CA inteira de suas listas de confiança. O episódio virou referência sobre o perigo de depender de raízes externas em infraestrutura sensível.
A empresa não divulgou janela de correção obrigatória nem indicou exploração ativa do vetor. A comunicação tem caráter preventivo: mapear deploys afetados, revisar trust stores customizadas e endurecer controle de acesso ao endpoint de assinatura.
Operadores que nunca tocaram na configuração padrão podem seguir normalmente. Os demais têm trabalho pela frente — e é um trabalho de auditoria interna, não de atualização automática de software.
