Otto certificati intermedi emessi dalla autorità di certificazione indiana eMudhra, nota con il marchio emSign, sono risultati generati con una debolezza crittografica tale da permettere a chiunque di ricostruirne la chiave privata partendo da quella pubblica. Nel giro di poche ore, tra il 17 e il 21 ottobre 2026, i principali produttori di browser e sistemi operativi hanno dovuto bloccare quei certificati per proteggere centinaia di milioni di utenti, in quella che gli esperti descrivono come una delle risposte coordinate più rapide mai viste nella storia del sistema di fiducia del web.
Che cosa è stato scoperto
Il problema riguarda otto certificati intermedi (le cosiddette "intermediate CA", gli anelli della catena di fiducia tra una radice e i certificati dei singoli siti) collegati a eMudhra: sei destinati a proteggere connessioni TLS nelle varianti Domain Validation, Organization Validation ed Extended Validation, e due usati per la firma del codice software. Chi possiede la chiave privata di un intermedio TLS può emettere certificati validi per qualsiasi dominio al mondo, facendoli accettare da tutti i browser come se fossero autentici: è il peggior scenario possibile per la sicurezza del web, perché mina alla radice il meccanismo che permette a un utente di fidarsi del lucchetto nella barra degli indirizzi.
Secondo quanto ricostruito dai ricercatori e riportato da eMudhra stessa, non si è trattato di un furto. Le chiavi sono state generate con un livello di casualità insufficiente durante una cerimonia di generazione risalente all'aprile 2025: un difetto nel processo ha prodotto una seconda serie di chiavi matematicamente deboli, che sono state comunque pubblicate nei registri dei root program dei browser. Una volta individuato il problema, un ricercatore di sicurezza è riuscito a calcolare le chiavi private partendo dai soli certificati pubblici, dimostrando che chiunque disponesse delle competenze adeguate avrebbe potuto fare lo stesso.
Una corsa contro il tempo tra i produttori di software
La tempistica della risposta è il dato più significativo di questa vicenda. Il problema è stato segnalato ai root program dei browser il 17 ottobre alle 18:05 UTC. Google Chrome ha bloccato i sei intermedi TLS tramite il proprio sistema di revoca rapida (CRLSet) entro le 19:45 dello stesso giorno, in meno di due ore. Mozilla ha completato il blocco equivalente per Firefox tramite OneCRL alle 22:59 UTC. Nei giorni successivi sono arrivati gli interventi di Apple e di Google Play Services per Android il 19 ottobre, e quelli di Microsoft e del linguaggio Go il 20 ottobre.
Alla correzione hanno dovuto lavorare anche gli ecosistemi open source che gestiscono le liste di certificati fidati: Mozilla NSS ha rimosso la radice "emSign ECC Root CA - G3" dai propri bundle, il linguaggio Go ha rilasciato le versioni 1.27.3 e 1.26.10 che rifiutano le catene contenenti le otto chiavi compromesse (la falla ha ricevuto l'identificativo CVE-2026-111943, mentre le versioni di Go precedenti alla 1.26 non riceveranno più alcuna patch), e sono seguiti aggiornamenti di emergenza per Node.js, per il pacchetto Python "certifi", per webpki-roots in Rust, per Homebrew e per il bundle di certificati di Composer in PHP. Anche le distribuzioni Ubuntu e Debian hanno pubblicato advisory dedicati (USN-8944 e DSA-6572-1), mentre Red Hat ha indicato un workaround temporaneo in attesa dei pacchetti definitivi per RHEL. Cloudflare ha aggiornato WARP, il servizio DNS 1.1.1.1 e il client cloudflared.
Che cosa cambia per siti web e aziende
Per chi naviga con un browser aggiornato la protezione è già attiva in automatico, senza bisogno di alcuna azione: Chrome e Firefox rifiutano silenziosamente le connessioni che si appoggiano ai certificati compromessi. Il problema si sposta però sul lato di chi gestisce infrastrutture: programmi che non controllano le liste di revoca in tempo reale, pacchetti di sistema non aggiornati, container con bundle di certificati datati o client applicativi con il proprio trust store incorporato restano potenzialmente esposti finché non vengono patchati.
Il punto più delicato riguarda però la radice "emSign ECC Root CA - G3", che Chrome ha annunciato di voler rimuovere definitivamente dal proprio elenco di autorità fidate con la versione 43 del Chrome Root Store, un'operazione attesa per il 27 ottobre 2026. Chi gestisce siti o servizi con certificati emessi sotto quella gerarchia, anche se perfettamente legittimi e non collegati alla falla, dovrà sostituirli con certificati di un'altra catena prima di quella data per evitare interruzioni di servizio. Si tratta quindi di un problema che travalica la singola vulnerabilità e costringe amministratori di sistema e responsabili IT a una verifica puntuale dei propri trust store, dei server mTLS e delle pipeline di distribuzione del software.
Al momento non risultano prove di uno sfruttamento malevolo della falla: lo conferma anche CERT-In, l'organismo indiano equivalente alla nostra Agenzia per la Cybersicurezza Nazionale, che ha pubblicato l'avviso CIAD-2026-0050. L'unico strumento di verifica a disposizione dei ricercatori sono i log pubblici di Certificate Transparency, che però coprono solo i certificati effettivamente registrati e non permettono di escludere con certezza un abuso avvenuto in altro modo. Sul piano societario, il titolo eMudhra ha perso circa il 20% alla Borsa di Mumbai il 21 ottobre, e il ministero indiano per l'Elettronica e le Tecnologie dell'Informazione ha aperto un approfondimento.
Il commento di PINET
Per l'Italia la vicenda è un promemoria più che un'emergenza diretta: eMudhra ha una base clienti concentrata soprattutto in India e nel code-signing, quindi l'esposizione diretta di siti e aziende italiane dovrebbe essere limitata, ma il principio resta universale, perché qualunque amministratore di sistema può trovarsi con un fornitore di certificati coinvolto in un incidente analogo. La lezione pratica riguarda la capacità di reagire: le organizzazioni che si affidano a un solo fornitore di certificati TLS, senza un piano di sostituzione rapida o strumenti di monitoraggio della scadenza e della revoca, rischiano interruzioni impreviste quando un root program decide di rimuovere una radice. Per le piccole e medie imprese italiane, spesso prive di un team di sicurezza dedicato, questo tipo di episodio dovrebbe spingere a verificare chi emette i propri certificati e con quale frequenza vengono rinnovati, piuttosto che considerare la questione un problema solo per gli addetti ai lavori. Non ci sono al momento evidenze di un impatto diretto su infrastrutture pubbliche o private italiane, e va evitato ogni allarmismo: la risposta dei browser è stata rapida ed efficace, a conferma che il sistema di fiducia del web, pur con i suoi limiti, ha meccanismi di correzione che hanno funzionato.
