Il 17 ottobre 2026, alle 20:06 UTC, Mozilla ha ricevuto la segnalazione che le chiavi private di otto certificati intermedi della autorità di certificazione indiana eMudhra (marchio emSign) erano state compromesse. Il 20 ottobre Mozilla e il programma radice di Chrome hanno confermato l'episodio. Chi possiede quelle chiavi può emettere certificati HTTPS validi per qualsiasi dominio e quindi intercettare o alterare il traffico di un utente che si trovi in posizione di attacco sulla rete. Nel frattempo i browser hanno già reagito, ma una parte del software che usiamo ogni giorno no: ed è qui che si gioca il rischio per le aziende.

Cosa è successo

Secondo la ricostruzione di Mozilla, Chrome e Firefox hanno bloccato gli otto certificati entro poche ore dalla segnalazione. Chrome ha attivato il blocco alle 19:45 UTC del 17 ottobre; Mozilla ha completato la distribuzione dell'aggiornamento OneCRL per le installazioni standard alle 22:59 UTC dello stesso giorno, meno di tre ore dopo la segnalazione. Apple ha bloccato i certificati il 19 ottobre, Microsoft il 20; eMudhra li ha revocati.

Sul come, The Register riferisce che le chiavi erano "troppo piccole e prevedibili": il ricercatore Scott Helme le avrebbe ricavate dai certificati pubblici in meno di un secondo. Una chiave corrisponderebbe al numero 4, altre a 56 e 115; altri ricercatori ne hanno trovate con valori analoghi. Per una chiave di tipo P-384 ci si aspetta un numero casuale a 384 bit, tra circa 10^115 possibilità: valori così bassi rendono il recupero banale. La causa tecnica del difetto di generazione non è stata spiegata, e Mozilla non specifica come le chiavi siano state compromesse. Non è noto da quanto tempo le chiavi fossero in queste condizioni, né se qualcuno oltre al ricercatore le abbia ricavate. Sempre secondo le ricostruzioni, nessun certificato TLS emesso tramite le sei intermedie per siti web risulta registrato nei log Certificate Transparency prima del blocco di Chrome, ma questo controllo copre solo i certificati registrati.

Le otto intermedie sono sei per TLS (varianti DV, OV ed EV, serie G3B e G3C) e due per la firma del codice. Sectigo aveva cross-firmato le chiavi: il blocco di Chrome, basato sulla chiave pubblica, copre anche queste copie. eMudhra dichiara di aver emesso oltre 60 milioni di certificati digitali, quindi l'ecosistema coinvolto non è piccolo.

Il punto delicato sono i software che non si aggiornano come i browser. Il blocco via OneCRL o CRLSet raggiunge Firefox e Chrome, ma molti programmi usano bundle di certificati statici senza controllo di revoca. Per questo sono arrivate correzioni di emergenza: Go (versioni 1.27.3 e 1.26.10, CVE-2026-111943, con ricompilazione dei programmi; Go 1.25 e precedenti non ricevono correzioni), NSS 3.131.1, Firefox 158.0.1 e le ESR 115.43.1 e 153.5.1, il pacchetto Python certifi 2026.10.19, webpki-roots 1.0.10 e il pacchetto ca-certificates di Homebrew, che rimuovono la radice emSign ECC Root CA G3. Al momento delle fonti consultate, le correzioni per Node.js e per il ca-bundle di Composer erano ancora in sospeso. Chrome rimuoverà la stessa radice nella versione 43 del proprio root store e valuta anche emSign Root CA G1.

Le correzioni hanno un costo: Mozilla avverte che la rimozione della radice può rendere alcuni server irraggiungibili per gli utenti non Firefox che adottano il suo trust store, finché i gestori dei siti non passano a nuove catene di certificati.

Cosa significa per le aziende italiane

La maggior parte delle aziende italiane non acquista certificati da eMudhra, e questo porta a sottovalutare l'episodio. Il rischio, però, non dipende da chi ha comprato il certificato: dipende da chi lo accetta. Un attaccante con una chiave di CA riconosciuta può impersonare un dominio qualsiasi, anche il vostro portale bancario, il vostro webmail o l'API di un fornitore, verso qualunque client che consideri valida quella radice. Il pericolo è concreto soprattutto per i client che non sono browser aggiornati: applicazioni interne scritte in Go, script Python con certifi datato, container costruiti mesi fa con bundle di certificati inclusi nell'immagine, agenti di backup, strumenti di monitoraggio, client di integrazione verso fornitori.

Per una PMI italiana, la lezione è la stessa che si ripete a ogni incidente di catena di fiducia: la sicurezza del canale cifrato dipende da componenti che nessuno inventaria. Chi gestisce container e pipeline di rilascio ha un punto debole specifico, perché un'immagine non ricostruita continua a includere il vecchio trust store. Un attacco richiede comunque una posizione di intermediazione sulla rete (reti Wi-Fi non fidate, provider compromessi, DNS manipolato), quindi non è un rischio uniforme: è più rilevante per dipendenti in mobilità, filiali con reti poco controllate e comunicazioni verso Paesi o provider dove l'intercettazione è più facile.

Sul piano normativo, per i soggetti NIS2 la gestione degli aggiornamenti dei componenti crittografici e la sicurezza della catena di fornitura rientrano tra le misure di base; per chi tratta dati personali, la protezione del trasporto è parte dell'art. 32 del GDPR. Se emergessero prove di intercettazione di dati personali, scatterebbe la valutazione sulla notifica al Garante entro 72 ore (art. 33). Al momento non risulta alcun abuso accertato: la pratica sensata è dimostrare di aver verificato, non di aver subito.

Cosa fare subito

  • Aggiornare i browser: Firefox 158.0.1 (o ESR 115.43.1 / 153.5.1) e le versioni correnti di Chrome ed Edge, in particolare sui portatili che escono dalla rete aziendale.
  • Ricompilare e ridistribuire i programmi scritti in Go con la versione 1.27.3 o 1.26.10; se si usa un ramo più vecchio, pianificare il passaggio a un ramo supportato.
  • Aggiornare i pacchetti con bundle propri: certifi (2026.10.19), webpki-roots (1.0.10), ca-certificates, e ricostruire le immagini dei container che includono un trust store.
  • Monitorare i rilasci di Node.js e Composer, ancora in sospeso nelle fonti consultate, e applicarli appena disponibili.
  • Dove il software lo consente, bloccare manualmente le otto intermedie; in alternativa, valutare la rimozione della fiducia nelle radici emSign, tenendo conto dei possibili disservizi verso siti che le usano ancora.
  • Verificare se i propri servizi o quelli dei fornitori usano certificati emessi da eMudhra/emSign, e pianificare la sostituzione con un'altra autorità: i certificati firmati con le chiavi compromesse risultano ancora in uso in alcuni ambienti.
  • Registrare nel registro interno delle vulnerabilità l'esito della verifica (inventario dei client, versioni, date di aggiornamento): è l'evidenza che un'autorità o un cliente potrebbero chiedere.

L'episodio dimostra ancora una volta che la revoca funziona bene dove c'è un browser moderno e funziona male ovunque altrove. Questo articolo sarà aggiornato se emergeranno prove di abusi o chiarimenti da parte di eMudhra.