Certificati eMudhra compromessi: chiavi CA da 4 a 237, Obol corregge Charon, bot e server crypto da aggiornare

Aggiornamento del 22 ottobre 2026, 05:30 UTC: Obol, blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il cui software Charon fa funzionare validatori distribuiti su Ethereum, ha pubblicato Charon v1.11.2 il 21 ottobre verso le 15:10 UTC e la definisce una versione obbligatoria per tutti gli operatori. La patch porta Charon a Go 1.27.3, che contiene la correzione per la CVE-2026-111943, l’identificativo del caso eMudhra, e toglie la fiducia alle radici emSign ECC Root CA – G3 e AAA Certificate Services nella sua immagine Docker. Le note di rilascio collegano la correzione ai certificati di eMudhra e non parlano di alcuna compromissione delle chiavi di Obol. Secondo Crypto Briefing e The Defiant i cluster di Obol sulla mainnet contengono 422.862 ETH nell’ultima rilevazione giornaliera di Obol, e Crypto Briefing scrive che nulla nell’annuncio indica fondi colpiti. I dettagli nella nuova sezione qui sotto.

Otto chiavi private usate dai certificati intermedi di eMudhra, società indiana che emette certificati web, erano numeri minuscoli: il più piccolo era 4, il più grande 237. Mozilla ha confermato la debolezza in un rapporto di incidente aperto il 18 ottobre e reso pubblico il 20 ottobre 2026, giorno in cui il ricercatore Scott Helme ha pubblicato i valori. Con queste chiavi chiunque poteva firmare un certificato HTTPS dall’aspetto affidabile per qualsiasi dominio. Firefox, Chrome, Safari ed Edge hanno bloccato le catene di certificati di eMudhra tra il 17 e il 20 ottobre. Il software che gira fuori dal browser, come curl, gli script Python e Node, i servizi Go e le app Electron, continua invece a fidarsi di quelle catene finché non viene aggiornato l’elenco delle autorità di certificazione.

Per chi usa le crypto conta soprattutto questo secondo gruppo. I bot di trading collegati agli exchange, i back-end dei wallet, gli strumenti per i nodi e i wallet desktop basati su Electron fanno tutti chiamate HTTPS senza passare da un browser. Non risultano attacchi che abbiano sfruttato le chiavi e non si conoscono perdite in crypto. Frasi seed, wallet hardware e chiavi secp256k1 che controllano bitcoin ed ether non c’entrano: è una storia di aggiornamenti software, non un hack del mondo crypto.

Certificati eMudhra compromessi: cosa si è rotto e cosa no

Un’autorità di certificazione (CA) garantisce che un sito sia davvero quello che dichiara di essere, e le CA radice delegano la firma quotidiana a certificati intermedi. Le otto chiavi compromesse appartengono a questi intermedi, non ai siti web. Ogni chiave sostiene due certificati di CA, uno sotto la radice di eMudhra e uno con firma incrociata di Sectigo, quindi 16 in tutto, secondo il bug di Mozilla e Helme. Sei servono per il TLS, due per la firma del codice. Nel bug Sectigo ha precisato che la sua radice, quella dietro le firme incrociate, era già uscita da tempo dagli archivi di Chrome e Mozilla, ma resta considerata affidabile da Microsoft e Apple.

La crittografia in sé non è mai stata debole. Cloudflare, che ha dovuto correggere il proprio software client, la mette così: «Questo intervento riguarda l’autenticazione basata sui certificati, non una debolezza degli algoritmi di cifratura di TLS.» Il rischio è l’impersonificazione. Chi possedesse una chiave potrebbe emettere un certificato per, ad esempio, l’API di un exchange, ma per usarlo dovrebbe comunque mettersi tra la vittima e il server vero: su un Wi-Fi ostile, su un router compromesso o su una rete falsa. È quindi uno strumento per attacchi man-in-the-middle, non un modo economico di mettere in piedi un sito di phishing che le persone raggiungono cliccando su un link.

Chiavi private tra 4 e 237, recuperate in meno di un secondo

Si tratta di chiavi a curva ellittica sulla curva NIST P-384. Su questa curva la chiave privata è un numero e la chiave pubblica è quel numero moltiplicato per un punto di partenza fisso. Una chiave P-384 generata correttamente viene estratta da uno spazio di circa 10¹¹⁵ valori. Dennis Jackson di Mozilla ha scritto nel bug che le chiavi di eMudhra erano «praticamente tutti zeri, tranne l’ultimo byte», il che lascia al massimo 255 candidati. A un attaccante basta calcolare 1 volta il punto, 2 volte, 3 volte, e confrontare ogni risultato con la chiave pubblica stampata nel certificato.

Helme ha fatto esattamente questo. «Le ho recuperate tutte dai loro certificati pubblici sul mio portatile, proprio adesso, e ci è voluto meno di un secondo», ha scritto nel suo articolo. Un aggiornamento dello stesso post aggiunge che «Claude è stato in grado di recuperare le chiavi private con un solo prompt». Jackson ha riferito qualcosa di simile nel bug: agenti di IA eseguiti in locale hanno recuperato una chiave al primo tentativo partendo da un prompt di una riga. Ecco i valori pubblicati da Helme:

eMudhra non ha pubblicato una dichiarazione propria: la sua versione si trova nei commenti al bug di Mozilla. La società attribuisce il problema a un difetto nello script della cerimonia di generazione delle chiavi, che ha creato nel modulo di sicurezza hardware (HSM) una seconda coppia di chiavi, più debole. Poiché le etichette delle chiavi erano simili, le chiavi deboli sono state usate per errore per le richieste di certificato. eMudhra afferma di essere ancora al lavoro sull’analisi del codice, quindi l’analisi della causa principale non è conclusa. Sostiene inoltre che le chiavi RSA create lo stesso giorno hanno seguito un percorso diverso e non sono interessate, e che le sue serie ECDSA A e A-1 sono state generate su HSM Entrust per un uso limitato all’India. Mozilla non ha confermato nessuna delle due affermazioni: Jackson ha scritto di non essere riuscito a violare le chiavi A e A-1 nonostante un impegno molto maggiore, e di non aver ancora iniziato con quelle RSA.

Da una cerimonia di aprile 2025 al blocco nei browser in meno di tre ore

Helme calcola una finestra di 17 mesi: «Sono 17 mesi di finestra e non c’è modo di sapere se qualcuno ne abbia approfittato.» Le date principali, in UTC, ricavate dal bug di Mozilla, dal blog di Mozilla, da Cloudflare e da Helme:

• Il 30 aprile 2025 gli intermedi interessati sono stati generati in un’unica cerimonia delle chiavi di eMudhra; Sectigo li ha firmati in modo incrociato a maggio 2025, secondo Helme.
• Sabato 17 ottobre 2026 un ricercatore ha segnalato la violazione ai produttori di browser e Mozilla ha ricevuto la segnalazione alle 20:06 UTC.
• Entro le 22:59 UTC della stessa sera Mozilla aveva spinto il blocco su Firefox tramite la lista OneCRL, «in meno di 3 ore dalla ricezione della segnalazione», come si legge nel suo blog sulla sicurezza; anche Chrome ha bloccato gli intermedi quella sera.
• Il 18 ottobre, tra le 09:24 e le 09:38 UTC, eMudhra ha revocato gli otto certificati, secondo il bug.
• Il 19 ottobre Sectigo ha completato la revoca delle sue firme incrociate, Apple ha bloccato le catene, Mozilla ha iniziato ad avvisare gli altri gestori di archivi di fiducia e Cloudflare è venuta a conoscenza del problema intorno alle 17:00 UTC.
• Il 20 ottobre Microsoft ha applicato il suo blocco, Mozilla ha rilasciato Firefox 158.0.1, Firefox ESR 115.43.1 e 153.5.1 e NSS 3.131.1, e il bug è diventato pubblico.

Il 20 ottobre Mozilla ha deciso anche la rimozione d’emergenza della radice che sta sopra gli intermedi, «emSign ECC Root CA – G3», e Chrome ha detto nel bug che seguirà una strada analoga. NSS 3.131.1 elimina quella radice dall’elenco delle autorità attendibili. eMudhra stima che circa 30.000 certificati dei clienti debbano ora passare a un’altra catena, circa il 97% dei quali emessi tramite il protocollo automatico ACME.

I browser controllano Certificate Transparency; curl, Python e Node no

Gli utenti dei browser erano protetti anche prima dei blocchi. Chrome, Firefox e Safari richiedono che i certificati compaiano nei registri pubblici di Certificate Transparency (CT), e da aprile 2025 nessun certificato di questi intermedi vi è apparso, osserva l’avviso di Jackson.

La maggior parte degli altri programmi funziona diversamente. Legge un insieme di certificati memorizzato su disco, controlla di rado la revoca e non guarda i registri CT. Il sito dell’avviso di Jackson lo dice chiaramente: «molti client al di fuori dell’ecosistema dei browser non impongono Certificate Transparency.»

Helme ha provato il varco con un server locale che presentava un certificato per api.stripe.com concatenato a uno degli intermedi compromessi. Con le impostazioni predefinite, curl ha risposto «SSL certificate verify ok», Python ha completato l’handshake e Node ha restituito «authorized: true». Il risultato è stato lo stesso su tutte le macchine Linux e macOS provate. Su Windows il sistema ha accettato la catena, a meno che fosse attivo il controllo di revoca.

La revoca non aiuta questi client. «Quindi il fatto che eMudhra e Sectigo abbiano revocato questi intermedi non li aiuta per niente», ha scritto Helme, perché molti programmi non chiedono mai se un certificato sia stato revocato. Solo un nuovo insieme di certificati, o una libreria che porta con sé un elenco aggiornato, elimina la fiducia. Cloudflare dichiara: «La nostra verifica di sicurezza non ha individuato uno sfruttamento attivo di questo problema sui servizi di Cloudflare.»

Perché bot crypto, back-end dei wallet e app Electron sono esposti

CoinDesk ha fatto il collegamento con le crypto il 21 ottobre: bot per gli exchange, script di trading e back-end dei wallet girano spesso su Python, Node o Go. In teoria, un certificato falso per l’API di un exchange permetterebbe a chi è sulla stessa rete di leggere o alterare il traffico di un bot. Helme fa notare che le chiamate API tra server trasportano segreti negli header; per un bot di trading, significa le chiavi API dell’exchange. È uno scenario, non un incidente. Mudit Gupta, direttore tecnico di Polygon Labs, ha detto a CoinDesk: «Non è un problema specifico delle crypto.» Lo ha definito un rischio generico di man-in-the-middle, rivolto soprattutto a chi usa software vecchio o non aggiornato, e ha aggiunto che chi tiene aggiornati wallet, strumenti di trading e dispositivi corre un rischio minore.

Le persone coinvolte sono quelle che fanno girare del codice: gestori di bot e di nodi, team con wallet o explorer in self-hosting e utenti di wallet desktop Electron, che includono una propria lista di fiducia. Non abbiamo trovato alcuna dichiarazione di un exchange o di un fornitore di wallet che dica di essere stato colpito, né una che dica di essere al sicuro. Un caso concreto arriva ora dallo staking: il 21 ottobre Obol ha rilasciato una versione obbligatoria di Charon per i suoi operatori di validatori distribuiti, descritta nella sezione seguente.

Nulla in questa storia ha a che fare con le chiavi che custodiscono le monete. La chiave privata di un indirizzo bitcoin o ether vive sulla curva secp256k1 ed è generata dal tuo wallet, e la tua frase seed non passa mai da un’autorità di certificazione. Nulla di tutto questo richiede di spostare fondi.

Charon v1.11.2 di Obol: cosa devono fare gli operatori di validatori distribuiti

Charon è il middleware che permette a più operatori di gestire insieme un unico validatore Ethereum, la cosiddetta tecnologia dei validatori distribuiti (DVT). Il changelog della v1.11.2 è una sola riga: passaggio a Go 1.27.3 e sfiducia verso le radici emSign e AAA nell’immagine. La modifica è stata unita al ramo principale il 21 ottobre alle 14:00 UTC (pull request n. 4796) e riportata sul ramo v1.11 alle 14:54 UTC (n. 4799), con il passaggio di Charon da Go 1.26.6 a 1.27.3 per la correzione di crypto/x509. La seconda parte è proprio il caso dei container descritto sopra: l’immagine di esecuzione, basata su Debian, segna le due radici come non affidabili nella sua configurazione dei certificati, per wget e gli altri strumenti non scritti in Go, finché il pacchetto ca-certificates di Debian non le rimuove.

La posta in gioco è alta. Crypto Briefing e The Defiant riportano 422.862 ETH nei saldi dei cluster di Obol sulla mainnet, citando l’ultima rilevazione giornaliera di Obol senza indicarne la data. Con l’ether vicino a 2.444 $ alle 04:37 UTC del 22 ottobre, sono circa 1,03 miliardi di dollari, secondo il nostro calcolo. È la somma in staking tramite i cluster di Obol, non una somma a rischio. Crypto Briefing scrive che nulla nell’annuncio indica fondi colpiti. Non sono stati segnalati slashing, interruzioni o perdite.

Obol non ha pubblicato avvisi di sicurezza né post sul blog; le note di rilascio sono la sua unica dichiarazione. Non spiegano come Charon usi le radici interessate né cosa potrebbe fare contro un cluster un attaccante con un certificato falso. Nei cluster di Obol le chiavi dei validatori sono divise tra gli operatori con una generazione distribuita delle chiavi e non hanno nulla a che fare con i certificati TLS, ma questo è il funzionamento generale del sistema, non una dichiarazione di Obol sul caso.

Cosa possono fare gli operatori, in base alla release e alle sue pull request:

• Aggiornare ogni nodo Charon del cluster alla v1.11.2 o successiva; Obol la indica come obbligatoria per tutti gli operatori e compatibile con Charon v1.0 e successive.
• Chi usa l’immagine Docker deve scaricare l’immagine v1.11.2 e ricreare il container, perché sia il binario Go sia l’archivio dei certificati stanno nell’immagine.
• Chi compila Charon da sé deve usare la toolchain Go 1.27.3 e controllare l’insieme di certificati della propria immagine di esecuzione.
• Un consiglio nostro, non di Obol: vanno aggiornati anche i container del beacon node, del validator client e del monitoraggio accanto a Charon, perché ognuno legge il proprio insieme di certificati.
• Va previsto l’aggiornamento successivo: la v1.11.2 non è pronta per Gloas, la parte di consenso di Glamsterdam. Su Hoodi tutti i nodi di un cluster devono usare la v2.0.0-rc2 o successiva, che contiene la stessa correzione di Go, prima del fork del 26 ottobre 2026 alle 17:42:48 UTC; sulla mainnet bisogna aspettare una v2.0.0 definitiva, secondo Obol.

La nostra pagina sull’aggiornamento Glamsterdam sulla testnet Hoodi segue questa scadenza.

Cosa aggiornare oggi e un test con curl in una riga

L’avviso di Jackson contiene una tabella delle versioni corrette. Le principali, come elencate il 21 ottobre, più il client per tunnel di Cloudflare tratto dal post di Cloudflare e Charon di Obol tratto dalle sue note di rilascio:

I passaggi pratici per chi gestisce bot o infrastrutture crypto:

• Aggiorna il pacchetto ca-certificates del sistema operativo su ogni server, VPS e portatile che esegue i tuoi script.
• Aggiorna certifi in ogni ambiente virtuale Python, perché requests e molti SDK degli exchange leggono certifi e non l’archivio di sistema.
• Ricostruisci le immagini dei container, che congelano l’insieme dei certificati al momento della build, e ridistribuiscile.
• Aggiorna i wallet desktop e gli strumenti basati su Electron appena i loro autori rilasciano una versione costruita su un Electron corretto.
• Non «risolvere» mai un errore di certificato disattivando la verifica; Cloudflare mette in guardia proprio da questo.

Poi fai la prova. Jackson gestisce host che presentano certificati delle catene compromesse. Dalla macchina e dall’ambiente che il tuo bot usa davvero, esegui:

curl https://dv-g3b-emudhra.we-have-a-problem.com/

Un errore di certificato è il risultato che vuoi: significa che il client non si fida più degli intermedi compromessi. Un secondo host, dv-g3b-aaa-emudhra.we-have-a-problem.com, verifica il percorso con firma incrociata di Sectigo. Se curl carica la pagina, l’insieme di certificati che legge è ancora vecchio. Attenzione, utenti Mac: secondo Jackson macOS blocca da sé gli intermedi, ma il curl integrato /usr/bin/curl verifica rispetto a /etc/ssl/cert.pem, che non è stato aggiornato. Cloudflare aggiunge un’avvertenza: controlla passando dal percorso TLS dell’applicazione stessa, perché un’app Node o Electron potrebbe non usare lo stesso insieme di certificati di curl.

Non è lo stesso problema della storia sui seed delle curve NIST

Quattro giorni fa abbiamo raccontato che Claude ha ricondotto i seed pubblicati delle curve NIST a un orologio del 1997, una vicenda che coinvolgeva anch’essa la P-384. I due casi non sono collegati. Quell’articolo riguardava il modo in cui erano stati scelti i parametri della curva, e Bitcoin ed Ethereum usano secp256k1, che non ha un seed del genere. Nel caso eMudhra la curva funziona come previsto; è la società ad aver scelto chiavi private che erano numeri minuscoli.

Spazi di chiavi minuscoli hanno già svuotato dei wallet crypto

Il paragone che segue è di Coindaro, non di Mozilla né di Helme, e nessuna fonte che abbiamo letto lo fa. eMudhra appartiene a una famiglia di errori che le crypto hanno già incontrato più volte: un segreto che sembra valido ma proviene da uno spazio abbastanza piccolo da poter essere esplorato per intero.

Nel caso Milk Sad, reso noto l’8 agosto 2023, il comando «bx seed» di Libbitcoin Explorer ricavava i seed dei wallet da circa 32 bit di entropia legata all’orologio, e il furto principale del 12 luglio 2023 ha portato via circa 29,65 BTC (il team di Libbitcoin contesta che si trattasse di un bug). A settembre 2022 1inch ha mostrato che lo strumento per indirizzi personalizzati Profanity generava le chiavi Ethereum a partire da un valore a 32 bit, circa 4 miliardi di punti di partenza; esperti citati da The Block hanno collegato a un indirizzo Profanity la perdita di 160 milioni di dollari di Wintermute di quel mese, che il CEO di Wintermute ha attribuito a un errore umano interno.

Il 19 ottobre, il giorno prima che il bug di eMudhra diventasse pubblico, abbiamo raccontato che Qubic ha fermato la sua catena dopo che seed deboli hanno permesso a un attaccante di svuotare 1.404 wallet. La differenza sta nell’esito. In quei casi le monete sono state sottratte. Con eMudhra i segreti deboli proteggevano certificati e non si conoscono furti.

Cosa non sappiamo ancora

Se qualcuno abbia usato le chiavi nei 17 mesi non si può stabilire, perché i client che saltano i controlli CT non lasciano tracce. Se sia mai stato emesso un vero certificato di sito web dagli intermedi compromessi dipende dalla parola di eMudhra. La società ha detto nel bug che solo uno di essi, EM DV TLS CA – G3C, è stato messo in produzione e che non ha emesso certificati per utenti finali; nessuno lo ha verificato in modo indipendente.

L’analisi della causa principale di eMudhra è ancora aperta e Mozilla non ha verificato quanto la società afferma sulle altre serie. Le prossime cose da seguire sono le versioni di Node.js e Bun con l’elenco di fiducia aggiornato, il pacchetto FreeBSD e la migrazione dei circa 30.000 certificati dalla radice emSign rimossa.