eMudhra: 8 CA compromesse, Qualys rilascia strumenti di detection operativa

Secondo un'analisi esclusiva di Qualys, unica fonte primaria disponibile al momento, otto intermediate CA di eMudhra sono stati compromessi da una flaw nel processo di key generation che ha ridotto l'entropia effettiva delle chiavi P-384 a 3-8 bit. Qualys ha rilasciato il 23 ottobre 2026 query QQL e QID specifici per identificare i certificati compromessi nelle infrastrutture enterprise.

La flaw nel key generation: come chiavi P-384 nominalmente sicure sono diventate deboli

La compromissione non deriva da un attacco esterno, ma da un errore nel processo interno di generazione delle chiavi di eMudhra. Durante una ceremony del 30 aprile 2025, una flaw nel passaggio di wrap/unwrap ha prodotto una seconda serie di chiavi P-384 deboli che sono state poi erroneamente utilizzate per otto intermediate CA certificate.

"reduced the effective entropy of the affected P-384 keys to an estimated 3 to 8 bits, making private-key recovery trivial to compute" — Qualys Product Tech Blog

L'entropia nominale per chiavi P-384 resta di 384 bit. A 3-8 bit effettivi, la chiave privata può essere ricostruita con risorse computazionali minimali, rendendo la firma di certificati fraudolenti tecnicamente banale per chiunque abbia accesso alla chiave pubblica. Questo è il cuore del rischio: non la compromissione di un server, ma la possibilità che un attore malintenzionato possa emettere certificati apparentemente validi per qualsiasi dominio o software.

Chrome, Mozilla, Apple e Microsoft: chi ha bloccato cosa

Le risposte dei vendor sono state differenziate per tipologia di certificato. Chrome, Mozilla e Apple hanno bloccato i sei intermediate CA TLS, impedendo che i browser trustino siti serviti da catene che li contengono. Microsoft ha agito sui due intermediate CA code-signing. Google ha rimosso specificamente emSign ECC Root CA – G3 dallo Chrome Root Store, mentre Mozilla ha revocato il trust nel root firmante.

eMudhra ha revocato gli otto certificati e ha fermato l'emissione sotto il root G3. Secondo la fonte, l'azienda afferma che solo uno degli otto intermedi compromessi era effettivamente utilizzato in produzione e che nessun certificato è stato emesso a siti web o utenti finali. Questa affermazione rimane non verificabile da fonti indipendenti nel set disponibile.

Perché i trust store enterprise rimangono il punto debole

Il blocco nei browser consumer è solo metà della partita. I trust store enterprise, i sistemi di build che verificano la firma del software, i dispositivi IoT con root store statici e le applicazioni compilate con Go non aggiornato possono continuare a considerare validi i certificati emessi dagli intermedi compromessi. Go 1.27.3 e 1.26.10 bloccano esplicitamente le certificate chain contenenti le otto chiavi compromesse attraverso CVE-2026-111943, ma le versioni precedenti non lo fanno.

Questo crea uno scenario di exposure persistente e potenzialmente invisibile: un certificato compromesso può rimanere funzionale in ambienti che non ricevono aggiornamenti automatici dei root store o che eseguono runtime Go legacy, senza generare allarmi nelle detection tradizionali.

Cosa fare adesso

Le squadre di sicurezza devono verificare la presenza dei certificati compromessi nella propria infrastruttura con tre azioni concrete. Prima: eseguire in Qualys Certificate View le query QQL pubblicate il 23 ottobre 2026 per cercare i certificati TLS per fingerprint SHA-256 o serial number degli otto intermedi compromessi. Seconda: lanciare in VMDR o Cloud Agent lo scan con QID 5019897 per identificare le versioni Go vulnerabili (pre-1.27.3/1.26.10) e QID 48395 per enumerare le certificate chain complete che presentano ancora gli intermedi eMudhra. Terza: isolare i sistemi che eseguono Go non aggiornato e pianificare l'upgrade a 1.27.3 o 1.26.10, che bloccano le catene contenenti le chiavi compromesse.

L'impatto potenziale è duplice: rischio di man-in-the-middle per i certificati TLS ancora presenti in trust store non aggiornati, e rischio di esecuzione di software firmato fraudolentemente per i certificati code-signing. La fonte non specifica la natura dei dati esposti né fornisce una timeline di remediation obbligatoria per le organizzazioni.

Che cosa non è chiaro

Rimangono zone grigie nel dossier pubblico. Il CVSS score non è riportato nel testo fornito dalla fonte primaria. Non è specificato se CVE-2026-111943 e CVE-2026-111944 rappresentino due aspetti distinti dello stesso incidente o varianti tecniche separate: il testo menziona entrambe senza delimitarne chiaramente lo scope. Non è nemmeno documentato se altri vendor di sicurezza abbiano rilasciato strumenti di detection analoghi a quelli di Qualys.

La scoperta originaria della flaw è attribuita a un ricercatore non nominato nella fonte. Non è chiaro se Qualys abbia sviluppato la detection in modo indipendente o in coordinamento con la divulgazione iniziale.

FAQ

Qualys ha scoperto la vulnerabilità?

No. La scoperta originaria è attribuita a un ricercatore non nominato nella fonte. Qualys ha rilasciato strumenti di detection e query operative per la propria piattaforma.

Tutti i certificati eMudhra sono compromessi?

No. Solo otto intermediate CA specifici sono affetti. I root CA e gli altri intermedi non sono coinvolti.

È stato confermato un attacco reale?

No. eMudhra afferma che nessun certificato fraudolento è stato emesso, ma questa affermazione non è verificabile indipendentemente nel set di fonti disponibile.

Perché il rischio persiste dopo la revoca?

Perché i trust store statici, i sistemi isolati e le applicazioni Go legacy non aggiornate possono continuare a considerare validi i certificati compromessi senza generare allarmi visibili.

Fonti

• blog.qualys.com