Ethereum, Teku e Besu corretti: rischio sui reward dei validator

🛡️ Executive Summary

• Teku e Besu pubblicano nuove versioni che rimuovono dalle immagini Docker la fiducia verso quattro certificati radice collegati alla compromissione eMudhra.
• In specifiche configurazioni HTTPS, un attaccante capace di intercettare il traffico avrebbe potuto impersonare servizi esterni e provocare il reindirizzamento delle commissioni dei blocchi Ethereum.
• I nodi Teku mainnet predefiniti non risultano interessati e non sono stati segnalati sfruttamenti. Le installazioni non containerizzate richiedono un controllo separato del runtime Java.

Ethereum corregge un rischio di sicurezza che avrebbe potuto compromettere le ricompense di alcuni validator, attraverso gli aggiornamenti dei client Teku e Besu pubblicati dopo l’incidente crittografico dell’autorità di certificazione eMudhra. Le versioni Teku 26.10.3 e Besu 26.10.2 eliminano dalle immagini Docker la fiducia verso certificati radice collegati a una catena PKI nella quale otto chiavi private intermedie erano risultate recuperabili. Il problema non riguarda direttamente il protocollo Ethereum né tutti gli operatori di staking: richiede particolari configurazioni HTTPS e la possibilità di intercettare comunicazioni verso servizi esterni. Non risultano sfruttamenti confermati, ma l’episodio mostra come una vulnerabilità nella fiducia TLS possa arrivare a minacciare le operazioni economiche di una blockchain.

Le chiavi eMudhra compromesse raggiungono l’infrastruttura Ethereum

L’origine della vulnerabilità è l’incidente eMudhra emerso il 17 ottobre 2026, quando un ricercatore ha dimostrato che otto chiavi private appartenenti a certificate authority intermedie erano state generate con entropia insufficiente. Nel resoconto ufficiale dell’incidente, l’azienda ha riconosciuto un errore nello script utilizzato durante la generazione delle chiavi, confermando che queste potevano essere ricostruite a partire dalle informazioni pubbliche. La revoca degli intermedi interessati è arrivata il giorno successivo, seguita dalla rimozione della fiducia da parte dei principali produttori di browser e di diversi fornitori software. Il problema tecnico, già documentato con la scoperta delle otto chiavi eMudhra prevedibili e delle conseguenze per HTTPS, assume ora una dimensione specifica per Ethereum. Teku e Besu sono sviluppati in Java e possono utilizzare archivi di certificati che non coincidono con quelli aggiornati dal sistema operativo. Inoltre, Java non verifica per impostazione predefinita la revoca dei certificati durante ogni connessione TLS. Alcune installazioni potevano quindi continuare ad accettare catene crittografiche non più considerate affidabili dai browser, anche dopo gli interventi effettuati sulla PKI pubblica. La compromissione di una chiave intermedia non equivale al furto di chiavi private dei validator Ethereum. Consente invece, in determinate condizioni, di creare certificati apparentemente attendibili per impersonare un servizio remoto. È questo passaggio, dalla falsa identità TLS alla relazione di fiducia tra i componenti del nodo, a determinare il rischio.

Teku 26.10.3 e Besu 26.10.2 rimuovono quattro certificati radice

La release ufficiale Teku 26.10.3, pubblicata il 27 ottobre, introduce una correzione raccomandata per gli operatori che utilizzano le immagini Docker del client. L’aggiornamento rimuove quattro radici considerate non più affidabili: emSign ECC Root CA – G3, emSign Root CA – G1, emSign Root CA – G2 e AAA Certificate Services. Il progetto precisa che i certificati erano già stati esclusi da OpenJDK, mentre le immagini basate su Eclipse Temurin non incorporavano ancora automaticamente la stessa correzione. Anche Besu 26.10.2, rilasciato il 26 ottobre, applica una modifica equivalente alle proprie immagini container. La distinzione tra immagini Docker e distribuzioni eseguite direttamente sul sistema è fondamentale: aggiornare Teku o Besu non significa necessariamente aggiornare il Java Runtime Environment installato sull’host. Chi utilizza archivi binari, installazioni personalizzate o JDK forniti da altri produttori deve verificare separatamente la presenza delle radici interessate nel trust store effettivamente utilizzato dal processo. Il caso mostra la complessità della gestione dei certificati nelle infrastrutture applicative. La rimozione delle CA compromesse dai browser non produce automaticamente lo stesso risultato per container, runtime, librerie e servizi che gestiscono autonomamente gli archivi di fiducia. La decisione di eMudhra di uscire dal mercato dei certificati SSL/TLS rappresenta un precedente industriale importante, ma non sostituisce gli interventi necessari sui software che continuano a utilizzare le vecchie catene.

Come un servizio HTTPS falsificato avrebbe potuto deviare le ricompense

Il rischio descritto dagli sviluppatori coinvolge i validator che comunicano via HTTPS con componenti esterni, come beacon node remoti, servizi di firma, builder o relay. Un attaccante in grado di intercettare il traffico e presentare un certificato apparentemente valido avrebbe potuto impersonare il servizio atteso, inducendo il client a utilizzare informazioni o risposte provenienti da una sorgente non autentica. Uno degli scenari riguarda il fee recipient, l’indirizzo destinato a ricevere le commissioni associate alla proposta di un blocco. Se un validator si fidasse di informazioni manipolate provenienti da un servizio remoto falsificato, potrebbe proporre un blocco che attribuisce le commissioni all’indirizzo controllato dall’attaccante. Il caso degli external signer è particolarmente delicato perché questi servizi custodiscono o utilizzano materiale crittografico per firmare operazioni autorizzate, e la loro impersonificazione potrebbe alterare il comportamento del validator. Si tratta di scenari di sfruttamento potenziale, non di furti accertati. Le indicazioni del progetto Teku precisano che un nodo mainnet con configurazione predefinita, privo di URL HTTPS verso questi servizi, non è interessato dalla vulnerabilità e non richiede interventi specifici per questo problema. Anche le connessioni peer-to-peer basate sui protocolli propri di Ethereum non dipendono dalle CA TLS coinvolte. La minaccia riguarda quindi l’infrastruttura di servizio che circonda alcuni nodi, non una compromissione generalizzata del consenso blockchain.

Leggi anche: MetaMask esce dai validator, Bitget perde 387,5 milioni: il rischio è la supply chain crypto

Gli operatori devono controllare Java, container e servizi di firma

Le indicazioni operative cambiano in funzione della modalità di distribuzione. Per le installazioni Docker interessate, gli sviluppatori raccomandano l’aggiornamento alle immagini Teku 26.10.3 o Besu 26.10.2, o versioni successive che includano la correzione. Per gli operatori che eseguono i client direttamente sul sistema, è invece necessario verificare e aggiornare il runtime Java e il relativo archivio dei certificati. L’aggiornamento di Java sull’host non modifica automaticamente il runtime incorporato in un container, così come il download di una nuova release applicativa non corregge un JDK gestito separatamente. Un’ulteriore criticità riguarda Java 26, indicato nelle raccomandazioni Teku come versione fuori supporto e priva di una correzione disponibile per il problema. Per questi ambienti viene raccomandato il passaggio a Java 25, verificando la compatibilità della configurazione utilizzata. Le organizzazioni che gestiscono servizi di staking dovrebbero inoltre identificare tutte le connessioni HTTPS esterne, controllare le CA effettivamente attendibili e verificare la configurazione degli indirizzi di destinazione delle commissioni e dei servizi di firma. La correzione evidenzia una debolezza strutturale delle infrastrutture blockchain: il consenso crittografico della rete può rimanere integro mentre un errore nell’autenticazione di un servizio esterno mette a rischio le operazioni dei validator. L’assenza di sfruttamenti segnalati limita l’impatto accertato dell’incidente, ma non elimina la necessità di correggere le configurazioni vulnerabili. Nel caso di Ethereum, la sicurezza dello staking dipende anche dalla capacità di mantenere aggiornati componenti apparentemente lontani dal protocollo, come i trust store Java utilizzati per le connessioni TLS.