Meteora Web

Cloudflare, le chiavi deboli di eMudhra sfruttate in poche ore e pochi client aggiornati

Cloudflare ha tracciato l'uso delle chiavi deboli di eMudhra. Certificati falsi in poche ore e oltre metà dei client ancora vulnerabili. Cosa fare.

Ing. Calogero Bono 5 min di lettura Read in English
Cloudflare, le chiavi deboli di eMudhra sfruttate in poche ore e pochi client aggiornati

Cloudflare ha pubblicato un'analisi di follow-up sulle otto chiavi crittografiche deboli della autorità di certificazione indiana eMudhra, scoperte il 19 ottobre 2026. Secondo l'azienda, i sistemi più critici sono già protetti e non risultano intercettazioni delle sue connessioni. Però i certificati falsi sono comparsi in poche ore, e molti browser, bot e app incorporate continuano ad accettare la catena compromessa. Per chi gestisce siti e servizi online il rischio non è teorico.

Qualche termine, prima di entrare nei fatti. CA (certificate authority) è l'ente che emette i certificati su cui si fonda il lucchetto HTTPS. Chiave intermedia è la chiave con cui la CA firma i certificati dei siti. CRL è l'elenco dei certificati revocati. Certificate Transparency è il registro pubblico dei certificati emessi, e gli SCT ne sono le ricevute. SAN e SNI indicano i nomi di dominio presenti nel certificato e quello richiesto dal client.

Zenithby Meteora Web Il sistema operativo della tua attività. Social, clienti, prenotazioni e fatture in un'unica piattaforma. Palestre, barber, professionisti. Scopri Zenith → Demo gratis · senza carta

Cosa è successo con le chiavi di eMudhra?

Secondo Cloudflare, eMudhra doveva scegliere un numero di 115 cifre per proteggere le sue chiavi e ha usato il numero 4. Le altre sette chiavi erano deboli allo stesso modo, con valori come 56, 66, 115, 155, 156, 230 e 237.

Cloudflare spiega che le chiavi intermedie si possono ricostruire quasi subito da chiunque, partendo dai certificati pubblici. Chiunque può quindi creare certificati per qualsiasi dominio, che un client non aggiornato e senza controllo di Certificate Transparency accetterebbe.

Per l'azienda il caso non ha precedenti. Incidenti come DigiNotar, TÜRKTRUST e TrustWave avevano dato il potere di emettere certificati falsi solo a pochi attori.

Come ha reagito Cloudflare?

Il 19 ottobre sono partite le patch sui sistemi ad alto impatto, a cominciare dai proxy Pingora rivolti ai server dei clienti, che gestiscono la maggior parte delle connessioni in uscita. In poche ore hanno cominciato a rifiutare le chiavi vulnerabili.

In parallelo, un'analisi del codice assistita dall'IA ha individuato in quattro ore gli altri sistemi che si fidavano di quelle chiavi. Per ognuno è stato aperto un ticket. Gli interventi urgenti andavano fatti subito, gli altri entro la fine della settimana scorsa. Al momento della pubblicazione restano da chiudere pochi ticket a basso impatto.

Le chiavi sono già state usate per falsificare certificati?

Sì, secondo Cloudflare. Dal 21 ottobre un log in Pingora registra i certificati firmati con le chiavi deboli. In circa una settimana ha contato circa 22.000 tentativi di handshake. Due terzi erano verso siti di prova, quasi tutto il resto verso server che sembrano essersi creati da soli un certificato con l'intermedio debole. Ogni handshake con verifica attiva è stato rifiutato.

Circa 160 casi erano anomali, con nomi di dominio di altre organizzazioni, alcuni legati a dispositivi IoT per i consumatori. Alcuni certificati erano validi oltre due anni, più di quanto una CA pubblica possa emettere. Uno risale al 20 ottobre alle 18:19 UTC, meno di un'ora dopo la pubblicazione della segnalazione di Mozilla.

Per Cloudflare però sembrano certificati predefiniti dei server, non tentativi di intercettazione. Il caso è simile ad altri in cui una vulnerabilità viene sondata subito, come quello di Oracle E-Business Suite.

Quanti visitatori sono ancora vulnerabili?

Cloudflare non può testare direttamente i visitatori senza interrompere le connessioni. Ha quindi aggiunto due sonde alle pagine di verifica, una con certificato eMudhra e una di controllo. In una settimana ha raccolto 50 milioni di sondaggi.

Il quadro che descrive è questo.

  • I browser moderni e aggiornati sono per lo più protetti.
  • Bot e vecchi browser no.
  • Le app con browser incorporato, come Android WebView, accettano ancora la catena nel 30-40% dei casi.
  • Nelle grandi reti, più della metà delle sonde accetta la catena compromessa.

Dopo qualche progresso nel primo fine settimana, la tendenza è piatta. Il traffico è però sbilanciato da bot non confermati e solo i client che eseguono JavaScript inviano sonde.

Limiti da conoscere

eMudhra dichiara un errore in uno script di generazione delle chiavi, ma non l'ha ancora condiviso. Restano da chiarire il ruolo di revisori e cross-signer e perché una CRL sia stata firmata prima con una chiave forse corretta e poi con quella debole. Cloudflare esclude intercettazioni solo in base ai segnali indiretti. Una intercettazione mirata non è esclusa. I dati dei visitatori sono inoltre distorti dai bot.

Cosa cambia per chi lavora con il digitale

Se gestisci siti, app o gestionali, controlla che server, librerie e client rifiutino le chiavi eMudhra. Contano anche i software che si collegano a servizi esterni, come app mobili con WebView e script automatici, perché spesso restano indietro. Chi sviluppa su macOS deve seguire con attenzione le istruzioni indicate da Cloudflare. Se hai un hosting con aggiornamenti di sicurezza gestiti, verifica con il fornitore lo stato della patch. Il tema tocca anche chi usa certificati per la firma digitale.

Il nostro parere

Il dato più allarmante non è il bug, ma la lentezza degli aggiornamenti. Una chiave ricostruibile da chiunque è un errore enorme, eppure il fatto che oltre metà delle sonde accetti ancora la catena mostra un problema più ampio, cioè il software che nessuno aggiorna. Il caso ricorda quanto pesino le chiavi crittografiche, come nel malware KeyDrift su Cisco SD-WAN. Resta poi un dubbio sul sistema di controllo, perché audit e cross-signing non hanno fermato nulla.

Domande frequenti

Cosa sono le chiavi deboli di eMudhra?

Sono otto chiavi intermedie di una CA, generate con numeri minuscoli come 4 o 56. Per questo chiunque può ricostruirle dai certificati pubblici e firmare certificati falsi.

Cloudflare è stata compromessa?

Secondo Cloudflare non ci sono prove di intercettazioni delle sue connessioni. I sistemi ad alta priorità sono stati aggiornati e restano pochi ticket a basso impatto.

Qual è il rischio per un sito o un'app?

Dipende dal client. Un client non aggiornato e senza controllo di Certificate Transparency può accettare certificati falsi per qualsiasi dominio, permettendo una possibile intercettazione.

Quali software restano più esposti?

Bot, vecchi browser e browser incorporati come Android WebView. In questi ultimi, secondo Cloudflare, il 30-40% accetta ancora la catena compromessa.

Cosa devo fare adesso?

Aggiorna i sistemi e segui le istruzioni nel sito curato da Dennis Jackson, citato da Cloudflare. Se sviluppi su macOS, dai priorità a quelle indicazioni.

Cosa guardare nelle prossime settimane sul caso eMudhra

Il caso è aperto su due fronti, le spiegazioni di eMudhra e il ritmo degli aggiornamenti. Conviene seguire entrambi.

  • Controlla se eMudhra pubblica lo script di generazione delle chiavi e le conclusioni su audit e cross-signer.
  • Segui gli aggiornamenti dei browser e dei runtime usati dalle tue app, in particolare le WebView.
  • Verifica nei log dei tuoi server eventuali certificati con nomi di dominio che non corrispondono a quelli richiesti.

Fonti

Zenithby Meteora Web Il sistema operativo della tua attività. Social, clienti, prenotazioni e fatture in un'unica piattaforma. Palestre, barber, professionisti. Scopri Zenith → Demo gratis · senza carta

Leggi anche

Dal blog

Ultimi articoli