Clientes Ethereum corrigem falha que poderia redirecionar recompensas de ETH
Atualizações do Teku e Besu destacam a importância da segurança da infraestrutura externa
Os clientes de consenso Ethereum Teku e de execução Besu lançaram atualizações de segurança no final de outubro de 2026 para corrigir uma vulnerabilidade relacionada a chaves de autoridade de certificado comprometidas da empresa indiana eMudhra. A falha poderia ter permitido que atacantes que interceptassem certas conexões HTTPS se passassem por serviços externos usados por validadores e redirecionassem recompensas de bloco ou obtivessem assinaturas sensíveis. Pesquisadores descobriram que oito autoridades de certificado intermediárias da eMudhra tinham chaves privadas geradas com aleatoriedade insuficiente, tornando essas chaves recuperáveis a partir dos próprios certificados públicos. Como os ambientes Java usados por ambos os clientes não verificam a revogação de certificados por padrão, algumas imagens Docker e instalações continuaram confiando nas cadeias afetadas mesmo após navegadores e principais sistemas operacionais bloqueá-las. Configurações padrão do mainnet Teku que evitavam endpoints HTTPS não foram afetadas, e desenvolvedores relataram nenhuma exploração confirmada.
Os patches removem a confiança nas raízes envolvidas das imagens Docker atualizadas, enquanto os operadores que executam binários independentes devem tratar separadamente seus armazenamentos de confiança Java locais. Este episódio destaca como dependências de infraestrutura externa podem criar riscos estreitos, mas de alto impacto, para operações de staking, mesmo quando o protocolo principal permanece seguro. A resposta rápida do Teku e do Besu demonstra que a diversidade de clientes do Ethereum e as práticas proativas de segurança podem conter ameaças relacionadas a certificados antes que afetem os recompensas dos validadores em larga escala, desde que os operadores apliquem as atualizações disponíveis e revisem suas configurações de conexão externa.
Aleatoriedade fraca nas chaves intermediárias da eMudhra gerou material privado recuperável
Pesquisadores identificaram o problema em 17 de outubro de 2026, quando determinaram que as chaves privadas por trás de oito autoridades certificadoras intermediárias da eMudhra haviam sido geradas com muito pouca entropia. As chaves eram efetivamente recuperáveis a partir dos certificados públicos, uma condição que existia desde sua criação em uma cerimônia de geração de chaves em abril de 2025. Seis das intermediárias suportavam conexões TLS, enquanto duas estavam relacionadas à assinatura de código. Uma vez que o material privado se tornou conhecido, um atacante poderia emitir certificados fraudulentos que software ainda confiando nas autoridades afetadas aceitaria como válidos. A eMudhra revogou as intermediárias em 18 de outubro. Principais plataformas responderam rapidamente: navegadores e sistemas operacionais começaram a bloquear os certificados entre 17 e 20 de outubro, e a Microsoft emitiu atualizações adicionais do Windows e do Edge em 26 e 27 de outubro que removeram as raízes associadas de suas listas de confiança. A falha criptográfica em si não foi um problema do protocolo Ethereum, mas importou porque Teku e Besu dependem da validação de certificados Java para quaisquer conexões HTTPS que seus nodes façam. O comportamento padrão do Java de pular verificações de revogação deixou certas instalações expostas por mais tempo do que ambientes de navegador. O incidente, portanto, ilustra como um erro operacional de uma única autoridade certificadora pode se propagar para infraestruturas especializadas que dependem de repositórios padrão de confiança TLS.
A recuperação das chaves não exigiu criptoanálise sofisticada; a aleatoriedade insuficiente tornou a derivação direta após a análise dos certificados públicos. O aviso da Microsoft de 26 de outubro confirmou que as chaves poderiam ser usadas para criar certificados que parecessem originar-se de uma autoridade confiável, potencialmente permitindo a imitação de sites ou serviços. Para operadores de Ethereum, a consequência prática foi que qualquer configuração de validador que dependesse de endpoints HTTPS, nodes de beacon remotos, signers externos, construtores de blocos ou relés poderia aceitar um certificado falsificado se a execução Java subjacente ainda confiasse na cadeia comprometida. A rede ponto a ponto usada pelos clientes de Ethereum permaneceu inalterada, pois não depende dessas autoridades de certificação. A combinação de chaves recuperáveis e validação Java que não revogava criou uma janela na qual um atacante em posição de homem-no-meio na rota da rede poderia apresentar uma identidade plausível ao software cliente. As equipes de clientes responderam removendo as raízes relevantes de suas imagens Docker em vez de esperar apenas atualizações da Java base, garantindo que operadores que puxarem imagens recém-criadas recebam um armazenamento de confiança reforçado. Essa resposta em camadas — revogação na CA, bloqueios na plataforma e atualizações específicas de imagem do cliente — limitou a superfície de ataque prática para a maioria das configurações de staking.
Como certificados forjados poderiam alterar o comportamento da proposta de bloco e do receptor de taxas
O aviso de segurança do Teku detalhou caminhos de ataque concretos que se tornam possíveis assim que um atacante consegue apresentar um certificado falsificado aceito pelo cliente. Um cenário envolve se passar por um node de beacon remoto usado por um validador para coordenação. Se a conexão for interceptada e o certificado falsificado for aceito, o validador poderá receber informações manipuladas sobre o bloco que está prestes a propor. Nesse caso, o cliente pode construir e assinar um bloco cujo endereço do destinatário das taxas aponta para uma conta controlada pelo atacante, em vez do endereço designado pelo operador. As taxas de transação e quaisquer dicas de prioridade incluídas no bloco fluirão então para o atacante. O aviso também mostrou serviços de assinatura externa, que armazenam chaves de validador separadamente e retornam assinaturas sob solicitação. Um atacante capaz de se passar por tal assinador poderia obter assinaturas usadas para operações sensíveis, incluindo alterações que afetam para onde os recompensas são direcionadas. O Teku classificou o caso do assinante externo entre as configurações mais graves, embora a autenticação TLS mútua em algumas configurações limitasse o impacto a negação de serviço em vez de comprometimento de assinatura.
Os tipos de conexão expostos adicionais incluem clientes de execução, construtores de blocos, relés e serviços que fornecem dados de configuração de validadores. Em cada caso, o risco central é o mesmo: o software cliente trata o certificado forjado como legítimo e, portanto, aceita dados ou instruções que alteram o conteúdo de um bloco proposto ou a manipulação de chaves. A vulnerabilidade não concede acesso direto à chave de assinatura do validador durante o funcionamento normal; em vez disso, compromete a integridade dos serviços externos consultados pelo validador. Como as recompensas e taxas do bloco Ethereum são pagas de acordo com os endereços incorporados no bloco proposto, uma manipulação bem-sucedida no momento da proposta pode desviar valor sem a necessidade de mover fundos já ganhos. Nenhuma exploração desses caminhos foi relatada, e instalações padrão do Teku em mainnet que não contêm URLs HTTPS em sua configuração permanecem fora do conjunto afetado. Os cenários detalhados, no entanto, deixam claro por que as equipes de clientes trataram o problema como exigindo atualizações imediatas nas imagens Docker, mesmo que os protocolos subjacentes e as camadas ponto a ponto permanecessem inalterados.
Teku 26.10.3 Remove raízes comprometidas dos repositórios de confiança do Docker
Teku lançou a versão 26.10.3 em 27 de outubro de 2026, especificamente para abordar a exposição relacionada à eMudhra. As notas de lançamento afirmam que as imagens Docker não confiam mais nas raízes emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 ou AAA Certificate Services. Essas raízes haviam sido removidas pelo OpenJDK após a compromissão das autoridades intermediárias; as imagens base Eclipse Temurin usadas pelo Teku ainda não tinham incorporado a correção correspondente no momento do lançamento do cliente. Ao disponibilizar imagens atualizadas, a equipe do Teku garantiu que operadores que puxarem as novas tags recebam um ambiente Java cujo armazenamento de confiança exclui o material comprometido. O aviso que acompanha o lançamento enfatiza que um node mainnet padrão sem URLs HTTPS configuradas não requer nenhuma ação. A exposição está limitada a configurações que se conectam deliberadamente a endpoints HTTPS remotos para coordenação de beacon, assinatura externa, builders ou serviços semelhantes.
Operadores que utilizam imagens Docker mais antigas, incluindo aquelas marcadas até 26.10.2, continuam a fornecer um runtime que confia nas raízes afetadas. Atualizar a instalação Java do host não atualiza automaticamente o runtime dentro de um contêiner existente, portanto é necessário realizar um novo pull da imagem. O Teku também observou que o Java 26 atingiu o fim da vida útil e não receberá uma versão corrigida; operadores ainda nessa versão são aconselhados a migrar para a versão atual de suporte de longo prazo, Java 25, e utilizar as respectivas tags de imagem -jdk25. O lançamento, portanto, combina a remoção das raízes de certificado com orientações sobre gerenciamento da versão do runtime. Como a mudança está limitada aos armazenamentos de confiança das imagens Docker, o comportamento de consenso e o manejo das chaves de validador permanecem inalterados. A atualização é apresentada como uma medida de segurança recomendada, e não como uma atualização de consenso de emergência, refletindo o escopo restrito das configurações afetadas.
Besu 26.10.2 Aplica Ajustes Paralelos de Confiança de Certificados
Besu, o cliente da camada de execução mantido pelo mesmo ecossistema mais amplo, lançou a versão 26.10.2 em 26 de outubro de 2026, implementando as mesmas remoções de raiz em suas imagens Docker. O alinhamento temporal e os alvos idênticos de certificados indicam consciência coordenada do incidente eMudhra na pilha de clientes Ethereum baseados em Java. Clientes de execução interagem com clientes de consenso e serviços externos para construção de carga útil e inclusão de transações; quaisquer caminhos de comunicação HTTPS que mantenham estão sujeitos às mesmas regras de validação de certificados que afetam o Teku. Ao remover a confiança nas autoridades comprometidas de suas imagens, o Besu fecha a superfície de ataque correspondente para operadores que dependem de suas distribuições Docker.
Assim como no Teku, a atualização do Besu não corrige automaticamente instalações binárias independentes que utilizam um ambiente Java gerenciado separadamente. Operadores nessa categoria devem inspecionar e atualizar seus repositórios de confiança locais ou versões do Java independentemente. Os lançamentos duplos dos clientes demonstram que tanto o lado de consenso quanto o lado de execução da pilha de software do nó Ethereum reconheceram a dependência compartilhada no tratamento de certificados Java. Como muitos validadores em produção executam tanto um cliente de consenso, como o Teku, quanto um cliente de execução, como o Besu, atualizações simultâneas reduzem a chance de que a confiança residual nas raízes comprometidas persista em qualquer um dos lados do par de nós. A ausência de exploração relatada antes dos lançamentos sugere que a janela prática foi limitada, mas as correções coordenadas ainda representam um endurecimento prudente contra uma falha criptográfica conhecida fora do próprio protocolo Ethereum.
Falta padrão do Java na verificação de revogação prolonga a exposição
Um detalhe técnico central é que a validação de certificados Java não verifica o status de revogação por padrão. Mesmo após a eMudhra revogar os certificados intermediários e após grandes plataformas os bloquearem, qualquer runtime Java que ainda contivesse as raízes ou intermediários correspondentes em seu armazenamento de confiança continuaria a aceitar certificados que encadeassem a essas autoridades. O OpenJDK lançou correções que primeiro bloquearam os intermediários comprometidos e posteriormente removeram quatro raízes associadas. No entanto, imagens Docker que incluíam versões mais antigas do Temurin ou OpenJDK não receberam automaticamente essas correções. Essa lacuna entre a revogação ao nível da plataforma e o comportamento dos runtimes Java incorporados é o que tornou necessárias atualizações específicas de imagem para clientes.
Para operadores de Ethereum, a implicação é operacional, não teórica. Um validador cuja configuração inclui endpoints HTTPS para serviços remotos herda as decisões de confiança do ambiente de execução Java que utiliza. Se esse ambiente de execução não foi atualizado ou substituído por uma imagem corrigida, o cliente continua disposto a aceitar um certificado falsificado. TLS mútuo ou certificados fixados podem mitigar o risco em configurações cuidadosamente projetadas, mas muitas configurações de produção dependem da validação padrão do armazenamento de confiança. As versões do Teku e Besu servem, portanto, como um lembrete prático de que o software de node contenerizado possui seu próprio armazenamento de certificados, independente do sistema hospedeiro. Operadores que tratam imagens Docker como caixas pretas opacas podem ignorar esse detalhe até que um incidente externo force uma atualização. O episódio também destaca o valor de monitorar avisos de segurança Java de origem ao executar clientes Ethereum baseados em Java.
Configurações padrão do mainnet evitaram a superfície de ataque principal
O aviso do Teku é explícito de que um node mainnet padrão que não contém URLs HTTPS em sua configuração não é afetado e não requer nenhuma ação. A maioria dos validadores que executam clientes de consenso e execução localmente co-localizados, sem assinatura remota ou endpoints de beacon remotos, enquadram-se nessa categoria. Os protocolos de descoberta ponto a ponto e gossip usados pelo Ethereum não dependem das autoridades certificadoras eMudhra, isolando ainda mais configurações padrão. O risco está concentrado entre operadores que introduziram deliberadamente dependências externas de HTTPS por conveniência operacional, distribuição geográfica de chaves de assinatura ou integração com serviços de construção de blocos de terceiros. Essa distinção é importante para avaliar o impacto geral na rede. Como a maioria dos validadores mainnet opera com configurações que nunca entraram em contato com as cadeias de certificados vulneráveis, a superfície de ataque teórica permaneceu limitada mesmo antes dos patches.
A decisão das equipes de cliente de implantar imagens atualizadas, mesmo assim, protege o subconjunto de operadores que utilizam serviços remotos e garante que futuras extrações de imagens partam de uma base reforçada. Configurações de testnet que baixam o estado inicial por HTTPS foram sinalizadas como potencialmente expostas, ilustrando que a mesma lógica de certificado se aplica fora do mainnet. Operadores de qualquer rede que dependam de bootstrap por HTTPS ou endpoints remotos devem tratar as versões de outubro de 2026 como obrigatórias para seus ambientes. A clara separação entre configurações padrão e não padrão permitiu que o aviso fosse ao mesmo tempo preciso e tranquilizador para a grande maioria do conjunto de validadores.
Assinadores externos e nós de sinalização remotos representam os caminhos de maior risco
Entre os cenários enumerados pelo Teku, os serviços de assinatura externa apresentaram gravidade elevada. Esses serviços armazenam as chaves privadas do validador offline ou em hardware especializado e respondem a solicitações de assinatura por meio de uma conexão de rede. Se um atacante conseguir se passar pelo assinante apresentando um certificado falsificado, o cliente do validador pode aceitar assinaturas que autorizem operações que o operador nunca intencionou, incluindo aquelas que alteram as configurações do destinatário de taxas ou iniciam saídas. Configurações que exigem autenticação TLS mútua reduzem o impacto a negação de serviço, pois o atacante não consegue completar a troca de mão autenticada. Quando a autenticação mútua está ausente, o risco de obter assinaturas utilizáveis é maior. Nós de beacon remotos apresentam uma preocupação relacionada, mas distinta.
Um validador que delega certas funções de coordenação a um ponto de extremidade de sinalização remota confia nesse ponto para informações sobre deveres, conteúdo de blocos e estado da rede. Uma imitação bem-sucedida pode, portanto, influenciar o bloco que o validador propõe finalmente, incluindo o endereço do destinatário de taxas incorporado nesse bloco. Construtores de blocos e relés introduzem ainda outras superfícies HTTPS por meio das quais cargas úteis manipuladas podem ser injetadas. Em cada caso, o atacante deve primeiro obter uma posição de rede que permita a interceptação e, em seguida, apresentar um certificado aceito pelo ambiente Java sem correção. A combinação de requisitos reduz o conjunto de adversários realistas, mas o potencial retorno — taxas redirecionadas de uma proposta bem-sucedida — justifica as correções defensivas. Operadores que mantêm assinadores externos ou infraestrutura remota devem priorizar tanto as atualizações do cliente quanto uma revisão dos mecanismos de autenticação nesses links.
Operadores que executam binários independentes enfrentam obrigações separadas de atualização do Java
Usuários do Docker podem corrigir o problema fazendo o pull das novas imagens do Teku 26.10.3 ou Besu 26.10.2. Operadores que instalam os clientes como binários ou pacotes independentes dependem do ambiente de execução Java presente no sistema host. Para essas instalações, as versões dos clientes não alteram o armazenamento de confiança do host. Os operadores devem, portanto, verificar se a versão do Java instalada inclui as correções do OpenJDK que removem as raízes comprometidas, ou ajustar manualmente o armazenamento de certificados. O Teku alertou especificamente que o Java 26 está em fim de vida e não receberá uma versão corrigida; a migração para o Java 25 é necessária para manter o suporte e as atualizações de segurança. Essa divisão entre implantações containerizadas e bare-metal é comum na infraestrutura do ethereum e cria um item prático de verificação para operadores de nodes.
Inventário das versões do Java, confirmação do conteúdo do trust-store e validação de que nenhum ponto final HTTPS permanece apontado para serviços não confiáveis formam a higiene mínima pós-patch. Como a falha criptográfica subjacente ocorreu fora do Ethereum, as mesmas obrigações de atualização do Java se aplicam a qualquer outra ferramenta baseada em Java que um operador possa executar. Os avisos dos clientes, portanto, servem como uma correção específica para Teku e Besu, bem como um alerta mais amplo para auditar o tratamento de certificados em toda a pilha do operador. Não resolver o ambiente Java do host mantém abertas as rotas de ataque teóricas, mesmo após a atualização do software cliente.
Nenhuma exploração confirmada ocorreu antes da aplicação dos patches
Tanto o aviso do Teku quanto os relatos contemporâneos afirmam que nenhuma exploração da vulnerabilidade foi observada. A ausência de incidentes conhecidos é consistente com o conjunto restrito de condições necessárias para um ataque bem-sucedido: um ambiente Java não atualizado, uma conexão HTTPS para um serviço externo e um atacante capaz de interceptar essa conexão específica enquanto apresenta um certificado falsificado. A maioria dos validadores nunca atendeu simultaneamente às duas primeiras condições. O curto intervalo entre a divulgação pública das chaves recuperáveis em 17 de outubro e o lançamento das imagens do cliente comprimiu ainda mais a janela prática.
A ausência de ataques observados não diminui o valor dos patches. Vulnerabilidades relacionadas a certificados podem permanecer dormentes até que um adversário oportunista apareça. Ao remover as raízes comprometidas dos repositórios de confiança do Docker, as equipes de cliente eliminaram a aceitação de certificados falsificados para operadores que atualizam. O episódio também proporcionou uma demonstração ao vivo de como falhas criptográficas externas podem interagir com a infraestrutura de staking do Ethereum, incentivando os operadores a examinarem seus próprios gráficos de dependência. Incidentes futuros envolvendo autoridades de certificação ou runtimes de linguagens provavelmente serão enfrentados com respostas semelhantes no nível do cliente, reforçando o padrão de mitigação rápida e direcionada.
Como os riscos de segurança de certificados se estendem pelas redes blockchain
O incidente da eMudhra não é exclusivo do Ethereum; qualquer software que dependa de armazenamentos de confiança TLS padrão herda a postura de segurança das autoridades certificadoras que confia. Clientes de blockchain que incorporam ambientes de execução de linguagens, como Java, Go ou outros, devem acompanhar atualizações de certificados upstream com a mesma diligência que aplicam às mudanças de consenso. O fato de a configuração padrão do Java omitir a verificação de revogação amplificou o impacto e forçou as equipes de clientes a implementar suas próprias modificações no armazenamento de confiança. Outros ecossistemas que empacotam ambientes de execução de longa duração dentro de contêineres enfrentam riscos análogos.
Para a comunidade de Ethereum staking, a lição prática é que a segurança operacional vai além do gerenciamento de chaves e versões de clientes, incluindo o comportamento de validação de certificados de cada componente conectado à rede. Operadores que adotam assinatura remota, nodes de beacon distribuídos ou relés de terceiros introduzem fronteiras de confiança adicionais que devem ser monitoradas. A contenção bem-sucedida desta falha específica, por meio da revogação da CA, bloqueios na plataforma e atualizações de imagens de clientes, mostra que defesas em camadas podem funcionar quando cada camada responde prontamente. A diversidade contínua de clientes permanece valiosa, pois diferentes implementações podem detectar ou mitigar dependências externas em velocidades diferentes, reduzindo a chance de que uma única falha de certificado afete todo o conjunto de validadores simultaneamente.
Preocupações recentes com a infraestrutura de validadores destacam a necessidade contínua de vigilância
Os certificados de outubro de 2026 chegaram contra um cenário de outra atenção à segurança relacionada a validadores. Divulgações anteriores envolvendo infraestrutura de serviço de staking e manipulação de destinatários de taxas já haviam provocado saídas voluntárias em larga escala e aumento da monitorização dos fluxos de recompensas. Separadamente, desenvolvedores corrigiram um problema de roteamento de depósitos nas regras preliminares para a próxima atualização Glamsterdam, que poderia ter atribuído incorretamente depósitos de staking sob certas colisões de chaves públicas; essa correção foi integrada às especificações de consenso após revisão adicional. Esses eventos simultâneos ilustram que a economia dos validadores e a segurança operacional permanecem áreas ativas de escrutínio, mesmo enquanto o protocolo principal continua a evoluir.
A falha no certificado diferiu em origem; surgiu de uma CA externa, e não de um bug na especificação do Ethereum ou no consenso do cliente, mas tocou a mesma superfície econômica: o destino das taxas e recompensas ganhas pelos propositores. A rápida resposta do cliente, portanto, encaixa-se em um padrão mais amplo de tratar qualquer caminho realista para desvio de recompensas como alta prioridade. Operadores que mantêm configurações de clientes diversificadas, monitoram endereços de destinatários de taxas na cadeia e mantêm ambos os softwares de consenso e execução atualizados estão melhor posicionados para absorver tais choques externos. A ausência de perdas no caso eMudhra reforça que a correção oportuna e a disciplina de configuração permanecem defesas eficazes.
O que os operadores de nós do ethereum precisam fazer após as atualizações de outubro
Validadores e operadores de nodes devem confirmar que estão executando o Teku 26.10.3 ou posterior e o Besu 26.10.2 ou posterior ao usar Docker, ou o ambiente de execução Java correspondente corrigido ao usar binários. As configurações devem ser revisadas quanto a quaisquer endpoints HTTPS; quando tais endpoints forem necessários, o TLS mútuo ou o certificate pinning oferecem proteção adicional. Operadores ainda utilizando Java 26 devem migrar para uma versão suportada. A monitorização de blocos propostos em busca de endereços inesperados de destinatários de taxas permanece um método de detecção de baixo custo mesmo após as atualizações do trust-store. Como as chaves subjacentes foram recuperáveis por um período prolongado antes da descoberta, uma auditoria única das conexões históricas e dos logs de aceitação de certificados pode fornecer garantia adicional, embora nenhuma exploração tenha sido relatada.
Essas etapas são incrementais, e não transformadoras, para a maioria dos operadores. A maioria dos validadores do mainnet nunca entrou em contato com as cadeias de certificados vulneráveis e, portanto, experimentam o incidente apenas como um lembrete para manter imagens de contêiner e runtimes Java atualizados. Para aqueles que dependem de serviços externos, os patches fecham um caminho específico e anteriormente subapreciado. Manter a consciência sobre avisos de certificados e runtimes upstream reduzirá a probabilidade de que falhas externas semelhantes criem janelas comparáveis no futuro. A ação coordenada das equipes Teku e Besu fornece tanto a correção imediata quanto um modelo para lidar com o próximo incidente criptográfico externo que interage com o software de cliente Ethereum.
Perguntas frequentes
O que exatamente estava errado com os certificados da eMudhra?
Oito autoridades certificadoras intermediárias operadas pela eMudhra tiveram chaves privadas geradas com aleatoriedade insuficiente durante uma cerimônia de chaves em 2025. As chaves eram recuperáveis a partir dos certificados públicos, permitindo que qualquer pessoa que as obtivesse emitisse certificados fraudulentos que os softwares ainda confiariam que essas autoridades aceitassem. Seis das intermediárias foram usadas para TLS e duas para assinatura de código. A eMudhra as revogou após a descoberta em 17 de outubro de 2026, e grandes plataformas bloquearam posteriormente o material associado.
Alguns validadores perderam recompensas ETH devido a essa falha?
Nenhuma exploração confirmada ou perda de recompensas foi relatada. Os avisos aos clientes e as coberturas contemporâneas afirmam que nenhum ataque foi observado. A combinação de condições necessárias — um runtime Java não corrigido mais uma conexão HTTPS ativa com um serviço externo vulnerável — limitou a superfície de ataque realista, e a emissão rápida de imagens Docker corrigidas reduziu ainda mais a exposição.
Os nodes padrão da mainnet Ethereum são afetados?
As configurações padrão do mainnet Teku que não contêm URLs HTTPS não são afetadas e não exigem nenhuma ação. O mesmo princípio se aplica a configurações comparáveis do Besu. A exposição está limitada a operadores que configuram deliberadamente endpoints HTTPS remotos para nós de beacon, assinadores externos, construtores ou serviços semelhantes.
Por que os ambientes de execução Java permaneceram vulneráveis após a revogação dos certificados?
Java não verifica o status de revogação de certificados por padrão. Mesmo após os intermediários serem revogados e bloqueados por navegadores e sistemas operacionais, qualquer instalação do Java que ainda contivesse as raízes correspondentes em seu armazenamento de confiança continuava a aceitar certificados que encadeavam a elas. Imagens de cliente Docker que incluíam runtimes mais antigos, portanto, precisavam de remoções explícitas das raízes.
O que os operadores que usam imagens Docker devem fazer?
Faça o pull e execute a versão 26.10.3 ou posterior do Teku e a versão 26.10.2 ou posterior do Besu. Essas imagens não confiam mais nas raízes comprometidas. Atualizar apenas o sistema host não atualiza o ambiente de execução dentro de um contêiner existente; é necessário uma imagem nova.
E quanto aos operadores que executam os clientes como binários independentes?
Esses operadores devem atualizar ou reconfigurar a instalação Java do host para que incorpore as correções do OpenJDK, removendo as raízes afetadas. O Java 26 está em fim de vida e não receberá uma versão corrigida; recomenda-se a migração para o Java 25. As atualizações do software cliente em si não alteram o armazenamento de confiança do host.
Isenção de responsabilidade: Esta informação geral de mercado, possivelmente proveniente de fontes terceirizadas, comerciais ou patrocinadas, é fornecida apenas para referência e fins educacionais e não constitui aconselhamento financeiro ou de investimento, oferta, solicitação ou garantia. Renunciamos à responsabilidade por sua precisão, completude, confiabilidade e quaisquer perdas decorrentes. Investimentos/negociações envolvem riscos; desempenho passado não garante resultados futuros. Os usuários devem pesquisar, julgar com prudência e assumir total responsabilidade. Para mais detalhes, consulte os Termos de Uso e Divulgação de Risco da KuCoin.
Aviso legal: Esta página foi traduzida usando tecnologia de IA para sua conveniência. Para informações mais precisas, consulte a versão original em inglês.