Segui Un grave incidente di infrastruttura a chiave pubblica ha scatenato misure di sicurezza d’emergenza in browser, ecosistemi di linguaggi di programmazione, archivi di certificati e pacchetti software. Le chiavi private associate a otto certificati di autorità certificante intermedia eMudhra sono state compromesse, permettendo potenzialmente a parti non autorizzate di creare certificati che potrebbero sembrare affidabili per i client vulnerabili.
L’incidente riguarda sei intermedi TLS utilizzati per certificati con convalida di dominio, convalida di organizzazione e convalida estesa, insieme a due intermedi di firma del codice. Poiché un CA intermedio può emettere certificati al di sotto di una radice fidata, il possesso della sua chiave privata crea un rischio sostanzialmente diverso rispetto alla compromissione di un normale certificato di sito web. Un attaccante potrebbe potenzialmente creare certificati fraudolenti che ereditano fiducia dalla catena compromessa.
Il Progetto Go ha risposto introducendo CVE-2026-111943, che affronta i casi in cui le applicazioni Go potrebbero continuare a fidarsi di catene di certificati contenenti gli intermedi compromessi. Go 1.26.10 e 1.27.3 aggiungono una lista di esclusione a crypto/x509, facendo fallire la verifica del certificato quando una delle chiavi intermedie conosciute e non fidate appare in una catena.
I team di sicurezza alla ricerca di opportunità di rilevamento per CVE-2026-111943 dovrebbero guardare oltre la convenzionale telemetria dello sfruttamento delle vulnerabilità. Questo incidente riguarda fondamentalmente la fiducia dei certificati, quindi i difensori dovrebbero monitorare le catene di certificati TLS, gli emittenti di certificati inattesi, i fallimenti di convalida dei certificati, le sessioni crittografate sospette e il software che mantiene il proprio bundle di certificati piuttosto che fare affidamento sui meccanismi di revoca del browser aggiornati rapidamente.
La piattaforma di Intelligenza di Rilevamento AI-Nativa di SOC Prime permette ai team di sicurezza di rafforzare la loro visibilità sulle minacce emergenti sfruttando contenuti di rilevamento continuamente aggiornati attraverso diverse tecnologie SIEM, EDR e Data Lake. Clicca su Esplora Rilevamenti per accedere a contenuti di rilevamento pertinenti e logica di caccia per comportamenti di attacco emergenti.
I professionisti della sicurezza possono anche usare Prime Architect per trasformare nuove informazioni sulle minacce e indicatori in query di caccia e logiche di rilevamento, aiutando i team a rilevare l’esposizione legata a CVE-2026-111943 e a indagare sull’attività sospetta dei certificati nei loro ambienti.
Analisi CVE-2026-111943
L’incidente è iniziato il 17 ottobre 2026, quando un ricercatore di sicurezza ha identificato una debolezza crittografica che colpisce otto certificati intermedi gestiti da eMudhra nell’infrastruttura dell’autorità certificante emSign. Il ricercatore ha dimostrato il possesso delle corrispondenti chiavi private presentando attestazioni firmate valide per tutti e otto i certificati ai programmi root dei browser e eMudhra.
Mozilla ha successivamente confermato la compromissione e, soprattutto, ha riferito che i suoi ingegneri sono stati in grado di recuperare indipendentemente le chiavi private compromesse senza ricevere dettagli sul metodo del ricercatore. Mozilla ha concluso che il processo di generazione delle chiavi sottostante era difettoso e facile da sfruttare.
Le autorità certificanti interessate includevano:
- EM DV TLS CA – G3B
- EM DV TLS CA – G3C
- EM OV TLS CA – G3B
- EM OV TLS CA – G3C
- EM EV TLS CA – G3B
- EM EV TLS CA – G3C
- EM OV CS CA – G3B
- EM OV CS CA – G3C
I primi sei sono intermedi TLS in grado di partecipare alle catene di certificati utilizzate per autenticare i siti web. I restanti due sono intermedi di firma del codice. I certificati G3B erano associati a eMudhra BV nei Paesi Bassi, mentre i certificati G3C erano associati a eMudhra Inc. negli Stati Uniti.
Le implicazioni sulla sicurezza sono significative. Chiunque sia in grado di derivare o altrimenti ottenere una chiave privata CA intermedia potrebbe potenzialmente emettere certificati al di sotto di quell’intermedio senza passare attraverso il legittimo processo di emissione dell’autorità certificante. Nel contesto TLS, certificati fraudolenti potrebbero essere usati per impersonare domini se un attaccante fosse anche in grado di intercettare o reindirizzare la connessione di una vittima.
Mozilla ha notato che un tale attaccante potrebbe potenzialmente impersonare siti web e leggere o modificare il traffico quando posizionato per intercettare la connessione. Questo rende la questione particolarmente rilevante per scenari di avversario-in-mezzo, infrastrutture di rete compromesse, proxy malevoli o manipolazioni DNS e di instradamento.
Tuttavia, le prove disponibili non dimostrano un abuso diffuso di certificati TLS fraudolenti prima della risposta difensiva. Secondo i risultati del Chrome Root Program citati da The Hacker News, nessun certificato TLS concatenato ai sei intermedi di siti web compromessi era apparso nei registri di Certificate Transparency prima che Chrome bloccasse le chiavi. Poiché Chrome e altri browser che richiedono la registrazione CT normalmente rifiuterebbero un certificato pubblico non registrato, questo ha limitato significativamente le opportunità di abuso TLS pubblico non monitorato tramite quei client.
Chrome ha ricevuto il rapporto alle 18:05 UTC del 17 ottobre e ha distribuito un blocco CRLSet per i sei intermedi TLS alle 19:45 UTC. Mozilla ha ricevuto il rapporto più tardi quella sera e ha distribuito un blocco OneCRL alle configurazioni standard di Firefox entro le 22:59 UTC. Gli utenti di Firefox che ricevono Impostazioni Remote quindi hanno ottenuto protezione senza dover aggiornare o riavviare manualmente il browser.
La situazione del PoC CVE-2026-111943 è insolita perché non si tratta di una vulnerabilità convenzionale di corruzione della memoria o di esecuzione di codice remoto con codice di exploit. Invece, il ricercatore ha fornito la prova crittografica del controllo su tutte e otto le chiavi private, e Mozilla ha riprodotto indipendentemente il recupero delle chiavi, dimostrando efficacemente che il fallimento crittografico potrebbe essere sfruttato.
Il CVE stesso è stato assegnato dal Progetto Go. Descrive un problema più ristretto riguardante la convalida dei certificati nella libreria standard Go. Su molte piattaforme, Go si affida a archivi di certificati root di sistema. Ma i sistemi in cui la configurazione di fiducia pertinente non viene aggiornata tempestivamente potrebbero continuare ad accettare catene attraverso intermedi che non sono più affidabili.
Per colmare questa lacuna, il Progetto Go ha aggiunto una lista di esclusione esplicita a crypto/x509. La logica di verifica aggiornata restituisce un errore ogni qualvolta una catena di certificati contenga una delle chiavi pubbliche intermedie compromesse.
CVE-2026-111943 influenza le versioni della libreria standard Go precedenti alla 1.26.10 e al ramo Go 1.27 prima della versione 1.27.3. Le applicazioni costruite utilizzando versioni affette possono quindi richiedere la ricompilazione con una versione patchata di Go per ricevere la nuova protezione.
I dettagli per CVE-2026-111943 sono particolarmente importanti per i proprietari delle applicazioni perché la correzione del browser non protegge automaticamente ogni programma che esegue la convalida TLS. Molte applicazioni utilizzano archivi di certificati specifici del linguaggio o incorporati e potrebbero non utilizzare i sistemi di revoca del browser come Chrome CRLSet o Mozilla OneCRL.
The Hacker News riferisce che questa distinzione ha innescato aggiornamenti attraverso più ecosistemi. Go ha aggiunto un blocco esplicito, Mozilla ha aggiornato NSS, il pacchetto di certificati certifi di Python ha rimosso la radice interessata, e l’ecosistema webpki-roots di Rust ha emesso un aggiornamento. RustSec identifica separatamente la versione 1.0.10 o più recente come patchata per il pacchetto root PKI web colpito.
Gli IOCs di CVE-2026-111943 sono quindi principalmente orientati ai certificati piuttosto che agli indicatori tradizionali di malware come indirizzi IP, domini o hash di file. Le organizzazioni dovrebbero concentrarsi sugli otto identificatori di certificati intermedi colpiti e sugli hash delle chiavi pubbliche utilizzati da Go e altri fornitori per bloccare esplicitamente quelle chiavi. La telemetria delle catene di certificati che mostra uno di questi intermedi dovrebbe essere trattata come non affidabile e indagata.
Mitigazione CVE-2026-111943
Il rimedio più importante per gli ambienti Go è aggiornare a Go 1.26.10, Go 1.27.3 o una versione supportata successiva e ricompilare le applicazioni che dipendono dalla verifica dei certificati TLS di Go. Semplicemente aggiornare la toolchain Go su un server di sviluppo non cambia retroattivamente i binari già compilati; le applicazioni affette devono essere ricompilate e ridistribuite con la libreria standard patchata.
Le organizzazioni dovrebbero anche inventariare le applicazioni che mantengono archivi CA indipendenti o bundle di certificati. I browser come Chrome e Firefox hanno reagito rapidamente tramite meccanismi di revoca centralizzati, ma le utility da linea di comando, le applicazioni server, i container, gli agenti, i dispositivi incorporati e i runtime dei linguaggi possono dipendere da fonti di certificati diverse.
Gli utenti di Firefox con configurazioni normali hanno ricevuto automaticamente il blocco OneCRL il 17 ottobre. Mozilla ha inoltre rilasciato Firefox 158.0.1, Firefox ESR 115.43.1 e Firefox ESR 153.5.1 per fornire la lista di blocco aggiornata agli utenti le cui politiche o ambienti di rete impedivano il normale funzionamento delle Impostazioni Remote. Mozilla ha anche rilasciato NSS 3.131.1 con modifiche al set di certificati fidati.
I team di sicurezza dovrebbero:
- Aggiornare le applicazioni Go e ricompilare i binari affetti.
- Aggiornare i bundle CA di sistema e gli archivi di fiducia specifici del linguaggio.
- Assicurarsi che i meccanismi di revoca dei certificati del browser e del sistema operativo funzionino.
- Bloccare o sfiduciare le otto chiavi di certificati intermedi compromesse.
- Identificare le applicazioni interne con archivi di certificati incorporati o staticamente confezionati.
- Ispezionare la telemetria TLS per catene di certificati contenenti gli intermedi coinvolti.
- Riemettere certificati legittimi se i servizi esistenti dipendono da catene di certificati che ora sono state sfiduciate.
- Testare servizi critici dopo gli aggiornamenti degli archivi root perché la rimozione di una radice CA può anche interrompere servizi legittimi che in precedenza si collegavano attraverso di essa.
I team dovrebbero prestare particolare attenzione anche agli elettrodomestici software di lunga durata, ai container, agli strumenti per sviluppatori interni e al software non supportato. Questi sistemi potrebbero continuare a fidarsi di vecchi bundle di certificati molto tempo dopo che i browser principali hanno bloccato una CA compromessa.
Rimuovere un certificato root può avere conseguenze operative. I certificati legittimi concatenati attraverso quella radice possono anche smettere di validare anche se quei certificati individuali non sono mai stati compromessi. Per questo motivo, le organizzazioni dovrebbero combinare sfiducia rapida con scoperta delle dipendenze e sostituzione dei certificati piuttosto che assumere che la rimozione dall’archivio di fiducia non abbia impatto sulla disponibilità.
I team SOC possono rafforzare la loro postura difensiva correlando i fallimenti di convalida dei certificati, la telemetria di intercettazione TLS, l’attività DNS insolita, il comportamento del proxy inatteso e i cambiamenti degli emittenti dei certificati. Un attaccante richiederebbe generalmente un qualche meccanismo per dirigere o intercettare il traffico prima che un certificato TLS fraudolento diventi utile, quindi le anomalie dei certificati dovrebbero essere indagate assieme a prove a livello di rete.
FAQ
Cos’è il CVE-2026-111943 e come funziona?
CVE-2026-111943 è un problema di sicurezza tracciato dal Progetto Go nel pacchetto di verifica dei certificati crypto/x509 a seguito della compromissione di otto chiavi private intermedie CA eMudhra. Le chiavi compromesse potrebbero potenzialmente essere utilizzate per creare certificati concatenati attraverso intermedi colpiti. Le applicazioni Go che si affidano ad archivi di certificati che non avevano ancora rimosso o revocato quegli intermedi potrebbero continuare ad accettare tali catene. Go ha affrontato il rischio aggiungendo una lista di esclusione esplicita che fa fallire la verifica del certificato ogni qualvolta una delle chiavi intermedie compromesse conosciute viene incontrata.
Quando è stato scoperto per la prima volta il CVE-2026-111943?
La compromissione della chiave eMudhra sottostante è stata identificata il 17 ottobre 2026. Secondo la cronologia degli incidenti di Mozilla, il ricercatore Wayne ha scoperto la violazione crittografica quel pomeriggio e ha segnalato il problema, insieme alla prova del controllo delle chiavi private, ai programmi root dei browser e a eMudhra. Chrome e Mozilla hanno verificato le scoperte nel giro di poche ore e hanno iniziato a bloccare gli intermedi colpiti. CVE-2026-111943 è stato successivamente pubblicato dal Progetto Go come parte della sua risposta al rischio residuo di fiducia dei certificati.
Qual è l’impatto di CVE-2026-111943 sui sistemi?
Il principale rischio è la fiducia impropria nelle catene di certificati che coinvolgono chiavi CA intermedie compromesse. Per TLS, il possesso di una chiave privata CA intermedia potrebbe potenzialmente consentire l’emissione di certificati fraudolenti per siti web che un attaccante non controlla. Se l’attaccante può intercettare o reindirizzare il traffico di rete e il software della vittima continua a fidarsi della catena di certificati colpita, questo potrebbe facilitare l’impersonificazione di siti web e potenzialmente consentire che le comunicazioni crittografate vengano osservate o modificate. La compromissione ha anche incluso due chiavi intermedie di firma del codice, ampliando la preoccupazione oltre l’autenticazione del sito web agli ecosistemi di fiducia del software che accettano catene attraverso quegli intermedi.
CVE-2026-111943 può ancora interessarmi nel 2026?
Sì. L’esposizione rimane possibile per il software che non ha ricevuto informazioni aggiornate sulla sfiducia dei certificati. Le installazioni standard di Chrome e Firefox hanno ricevuto una protezione rapida, ma le applicazioni Go compilate con versioni della libreria standard vulnerabili, le applicazioni che utilizzano bundle CA indipendenti non aggiornati, il software non supportato, i sistemi incorporati o gli ambienti in cui i meccanismi di revoca dei certificati sono disabilitati, potrebbero continuare a fidarsi dei percorsi dei certificati compromessi. Le organizzazioni non dovrebbero quindi assumere che l’aggiornamento dei propri browser web elimini da solo il rischio.
Come posso proteggermi da CVE-2026-111943?
Aggiorna a Go 1.26.10, Go 1.27.3 o versioni successive e ricompila le applicazioni Go affette. Aggiorna gli archivi di fiducia del sistema operativo e delle applicazioni, le versioni dei browser, i bundle di certificati specifici del linguaggio, e altro software che esegue verifica TLS. Le organizzazioni dovrebbero anche verificare che gli otto intermedi compromessi non siano più fidati, ispezionare la telemetria delle catene di certificati per la loro presenza, e identificare le applicazioni che trasportano bundle CA statici o incorporati. Se i servizi legittimi attualmente dipendono da catene colpite dalle azioni di sfiducia d’emergenza, sostituisci quei certificati con catene ancorate ad autorità certificanti non colpite.
