News

eMudhra: chiavi private di 8 certificati intermedi TLS compromesse, cosa aggiornare

Chiavi private deboli su 8 intermedi TLS/code-signing di eMudhra: rischio di certificati falsi. Cloudflare ha già patchato WARP e cloudflared, tocca ai sistemisti controllare gli origin.

Redazione UptimeMag · 21 ottobre 2026 · 2 minuti di lettura

eMudhra: chiavi private di 8 certificati intermedi TLS compromesse, cosa aggiornare

Cloudflare ha reso noto il 20 ottobre 2026 di essere venuta a conoscenza, il giorno prima alle 17:00 UTC, della compromissione delle chiavi private di otto certificati intermedi emessi da eMudhra. Private keys associated with eight eMudhra intermediate certificate authority certificates were compromised, potentially allowing unauthorized parties to create certificates that could appear trustworthy to vulnerable clients. Per chi gestisce server, VPN, reverse proxy o pannelli con TLS verso l'esterno, la notizia riguarda direttamente la fiducia nei certificati usati ogni giorno.

Cosa è successo

A scoprire l'anomalia è stato un ricercatore indipendente. Il 17 ottobre 2026 i root program dei browser hanno ricevuto una segnalazione da un ricercatore indipendente di nome Wayne secondo cui le chiavi private di otto certificati intermedi eMudhra erano state compromesse. Il problema non era un furto, ma una generazione difettosa: le chiavi erano generate in modo scorretto, al punto che chiunque può recuperarle dai certificati stessi. Nel dettaglio, le otto chiavi private compromesse erano 4, 56, 66, 115, 155, 156, 230 e 237: una chiave privata su curva ellittica P-384 ha normalmente circa 384 bit di entropia, ma queste ne avevano tra 3 e 8.

eMudhra ha attribuito l'origine del difetto a un passaggio tecnico della cerimonia di generazione: gli otto intermedi erano stati creati sotto la sua root ECC in una cerimonia di generazione chiavi del 30 aprile 2025, usando moduli hardware certificati FIPS 140-2 Level 3, e un difetto in quella cerimonia ha riguardato un passaggio di wrap e unwrap della chiave.

La risposta di Cloudflare

Cloudflare ha aggiornato prima i servizi che si autenticano verso endpoint remoti tramite certificati pubblici, poi i trust store condivisi. In parallelo ha rilasciato patch per i client:

Prodotto Azione
Cloudflare One Client / WARP Aggiornare ad Android v2.5.7, iOS v1.12.7, Windows/macOS/Linux 2026.8.2115.0
App 1.1.1.1 Aggiornare ad Android v6.38.11, iOS v6.31.8, Windows/macOS/Linux 2026.8.2115.0
Cloudflare Tunnel (cloudflared) Aggiornare a 2026.10.2, ridistribuire le immagini container
Origin con Full (strict) o Strict Verificare i certificati origin custom
Containers/Sandboxes Controllare le immagini e abilitare l'egress HTTPS intercettato

La cronologia pubblicata da Cloudflare indica tre momenti: gli aggiornamenti di sicurezza per Cloudflare One Client e app WARP pubblicati su tutte le piattaforme il 20 ottobre alle 02:00 UTC, l'aggiornamento di cloudflared alle 09:15 UTC dello stesso giorno, e il completamento delle mitigazioni su CDN e Zero Trust lato server alle 19:20 UTC.

Cosa deve fare chi gestisce un server

Chi usa Cloudflare in modalità Full (strict) o Strict deve controllare i propri certificati origin e sostituirli se emessi dagli intermedi compromessi. Più in generale, su ogni stack che valida certificati TLS (librerie HTTP, runtime di linguaggio, sistema operativo) va verificata la versione dei trust store. Tra i pacchetti lato server toccati dall'incidente, secondo l'elenco raccolto da Mozilla e ripreso da più fornitori di sicurezza: Go 1.27.3 e 1.26.10, NSS 3.131.1, Python certifi 2026.10.19, Node.js 22.23.4/24.22.1/26.12.1, oltre ai pacchetti ca-certificates di Ubuntu, Debian e Alpine aggiornati tra il 16 e il 20 ottobre. Cloudflare avverte di non disabilitare la verifica dei certificati per aggirare errori comparsi dopo l'aggiornamento: toglierebbe proprio la protezione che la patch doveva ripristinare.

Testo redatto con il supporto dell'intelligenza artificiale e verificato dalla redazione (AI Act, art. 50).