Oggi, 21 settembre 2026, scade il termine fissato dalla Cybersecurity and Infrastructure Security Agency (CISA) per correggere tre vulnerabilità critiche del kernel Linux già sfruttate da attaccanti reali. L’agenzia statunitense le ha inserite nel Known Exploited Vulnerabilities Catalog (KEV) il 18 settembre 2026, lasciando alle agenzie federali americane appena tre giorni per applicare le correzioni. Per i team di sicurezza europei la finestra di reazione è stata identica: brevissima, e arrivata proprio mentre l’Unione Europea stringe i tempi su NIS2 e Cyber Resilience Act.
Le tre falle, identificate come CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964, toccano componenti del kernel presenti in praticamente ogni distribuzione server: il percorso di ricezione TLS, il sottosistema netfilter/ebtables e i socket crittografici AF_ALG. Non sono bug isolati in un prodotto di nicchia. Sono difetti nel cuore del sistema operativo che fa girare la maggior parte dei server cloud, delle appliance di rete e delle infrastrutture pubbliche in Italia e nel resto d’Europa.
Cosa ha annunciato CISA sul catalogo KEV
Il Known Exploited Vulnerabilities Catalog nasce nel 2021 come elenco pubblico delle vulnerabilità per cui esistono prove concrete di sfruttamento attivo, non semplici rischi teorici. Ogni voce del catalogo porta con sé un obbligo per le agenzie federali statunitensi, fissato dalla Binding Operational Directive 22-01 e aggiornato dalle direttive successive: patchare entro una scadenza precisa o giustificare formalmente il ritardo.
Il 18 settembre 2026 CISA ha aggiunto le tre CVE del kernel Linux con l’indicazione esplicita di sfruttamento in corso, fissando come termine di correzione il 21 settembre 2026, cioè oggi. Tre giorni netti tra pubblicazione e scadenza sono un intervallo compresso anche per gli standard KEV, e segnalano quanto CISA consideri urgente la situazione. Diversi ricercatori, tra cui il team di SecurityAffairs, hanno ripreso l’annuncio nelle stesse ore, sottolineando che si tratta di difetti già presenti nelle build di produzione di molte distribuzioni.
Le aziende europee non sono formalmente vincolate dalla direttiva CISA, ma il catalogo KEV è diventato negli ultimi anni un riferimento de facto anche per i CERT nazionali e per gli obblighi di gestione del rischio previsti da NIS2. Ignorare una voce KEV attiva, in un’ispezione ACN o di un altro CSIRT europeo, difficilmente verrebbe considerato un comportamento diligente.
CVE-2025-39682: la falla da 9,8 nel percorso TLS del kernel
La vulnerabilità più severa del gruppo riguarda il percorso di ricezione TLS del kernel (kernel TLS, o kTLS), la funzione che permette al sistema operativo di gestire lo scambio dati cifrato senza passare ogni pacchetto attraverso lo spazio utente. Il difetto nasce da un controllo mancante su condizioni eccezionali: un record TLS di lunghezza zero proveniente dalla coda rx_list può bypassare la gestione normale dei tipi di record in recvmsg(), rompendo le assunzioni su cui si basa la logica zero-copy del kernel.
Il risultato pratico è duplice: un utente locale autenticato può innescare una divulgazione di memoria (leggendo dati che non dovrebbe vedere) oppure una negazione del servizio, mandando in crash il sistema. Con un punteggio CVSS di 9,8, la falla rientra nella fascia critica più alta. Le versioni corrette del kernel includono, tra le altre, la 5.10.245, la 5.15.194, la 6.1.154, la 6.6.108, la 6.12.49 e la 6.16.9: chiunque gestisca server con kernel-TLS attivo su versioni precedenti resta esposto.
Va precisato un dettaglio che spesso sfugge nella lettura veloce dei bollettini: lo sfruttamento richiede un accesso locale autenticato, non un attaccante remoto anonimo. Questo abbassa il rischio diretto verso internet, ma lo alza parecchio negli ambienti multi-tenant, nei container condivisi e nei sistemi con più utenti, cioè esattamente il tipo di infrastruttura che gira nei data center cloud europei.
CVE-2026-53266: privilege escalation da 8,8 in ebtables e netfilter
La seconda falla, con CVSS 8,8, colpisce il sottosistema netfilter bridge, in particolare il target ebtables SNAT usato per riscrivere l’indirizzo hardware Ethernet nei pacchetti ARP. Il codice manteneva la riscrittura dietro una chiamata a skb_ensure_writable(skb, 0), ma su alcune configurazioni questo controllo si è rivelato insufficiente: il kernel finiva per scrivere su frammenti di buffer di rete non resi effettivamente scrivibili, generando una scrittura fuori limite (out-of-bounds write) in memoria del kernel.
Il tracker di sicurezza Debian ha documentato la correzione risalente a una modifica upstream nel codice netfilter bridge, descritta come la funzione che rende scrivibile la riscrittura ARP di ebt_snat. In pratica, un attaccante con accesso locale e la possibilità di configurare o innescare traffico su un bridge protetto da ebtables può inviare pacchetti ARP appositamente costruiti e ottenere una corruzione di memoria che, nello scenario peggiore, porta a un’escalation di privilegi fino a root.
È un difetto particolarmente insidioso per chi gestisce infrastrutture di virtualizzazione e cloud privato, dove bridge di rete ed ebtables vengono usati di routine per isolare il traffico tra macchine virtuali e container. Un tenant malevolo, o un servizio compromesso all’interno di un ambiente condiviso, potrebbe sfruttare la falla per uscire dal proprio perimetro di privilegi.
CVE-2025-39964: race condition negli AF_ALG socket
La terza vulnerabilità, con CVSS 7,8, è una race condition (classificata come CWE-362) nei socket AF_ALG, l’interfaccia che il kernel Linux espone per delegare operazioni crittografiche allo spazio utente. Quando più thread o processi scrivono in modo concorrente sullo stesso socket AF_ALG senza sincronizzazione adeguata, lo stato interno del socket può diventare incoerente, corrompendo i buffer usati per le operazioni crittografiche.
Le conseguenze vanno dal crash del sistema alla corruzione dei risultati di operazioni crittografiche, un problema che tocca sia la disponibilità sia, potenzialmente, l’integrità dei dati cifrati elaborati tramite questa interfaccia. Le versioni kernel corrette coincidono con quelle già citate per CVE-2025-39682: 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49 e 6.16.9. Chi utilizza AF_ALG per offload crittografico, comune in appliance di rete e sistemi embedded ad alte prestazioni, dovrebbe considerare questa patch prioritaria quanto le altre due.
Le tre CVE a confronto
| CVE | CVSS | Tipo di vulnerabilità | Componente kernel | Versioni corrette |
|---|---|---|---|---|
| CVE-2025-39682 | 9,8 | Divulgazione memoria / DoS | Percorso di ricezione TLS (kTLS) | 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 |
| CVE-2026-53266 | 8,8 | Scrittura fuori limite | netfilter bridge / ebtables SNAT | Fix upstream nel codice netfilter bridge |
| CVE-2025-39964 | 7,8 | Race condition (CWE-362) | Socket AF_ALG (crypto userspace) | 5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 |
Chi sta sfruttando le falle: quello che sappiamo e quello che non sappiamo
Qui arriva la parte più scomoda della vicenda. CISA e i ricercatori che hanno ripreso la notizia confermano lo sfruttamento attivo, ma nessuna fonte pubblica al momento attribuisce gli attacchi a un gruppo APT, a una famiglia di ransomware o a una botnet specifica. Non è chiaro nemmeno se le tre CVE vengano sfruttate insieme, in catena, oppure separatamente da attori diversi con obiettivi diversi.
Alcuni report di threat intelligence indicano un interesse particolare verso carichi di lavoro governativi e cloud, ma senza numeri verificabili su quanti sistemi risultino già compromessi. Non esistono, al momento, stime pubbliche affidabili sul numero di server Linux vulnerabili a livello globale, europeo o italiano: chiunque citi una cifra precisa in questa fase la sta inventando. È corretto dire che l’esposizione potenziale è ampia, dato che i tre componenti (kTLS, netfilter bridge, AF_ALG) sono presenti nei kernel general-purpose di quasi tutte le distribuzioni server, ma tradurre questo in un numero preciso di macchine a rischio non è oggi possibile con i dati disponibili.
Questa incertezza non è un dettaglio secondario. Significa che i team di sicurezza non possono affidarsi a un elenco di indicatori di compromissione noti. Devono trattare la finestra attuale come un rischio generico di sfruttamento opportunistico, non come una campagna mirata e già mappata.
Il contesto storico: perché il kernel Linux finisce sempre più spesso nel mirino KEV
Il Catalogo KEV ha aggiunto negli ultimi anni un numero crescente di voci legate a componenti open source di base, e il kernel Linux non fa eccezione. Il motivo è semplice: la superficie di attacco locale del kernel, privilege escalation, corruzione di memoria, race condition, è diventata un obiettivo primario per chi ha già ottenuto un primo accesso a un sistema, tramite phishing, credenziali rubate o una vulnerabilità applicativa, e cerca di trasformarlo in un controllo completo della macchina.
Negli ultimi dodici mesi il catalogo ha visto entrare falle critiche in prodotti molto diversi tra loro: appliance di rete, piattaforme DevOps, strumenti di gestione remota, sistemi di backup. Il kernel Linux rappresenta però un caso particolare, perché non è un prodotto nel senso tradizionale: è la base comune su cui girano migliaia di prodotti diversi, dalle distribuzioni server alle appliance embedded. Una falla nel kernel non richiede che un singolo vendor rilasci una patch. Richiede che ogni distribuzione, ogni immagine cloud e ogni dispositivo che la utilizza venga aggiornato separatamente, un processo molto più lento e frammentato rispetto a un singolo prodotto commerciale.
Questo spiega anche perché CISA abbia scelto una finestra di soli tre giorni. Più il tempo passa, più cresce il numero di sistemi che restano esposti semplicemente perché nessuno ha ancora ricompilato o distribuito il kernel aggiornato per quella specifica variante.
Confronto con le altre falle critiche aggiunte al catalogo KEV nel 2026
Le tre CVE del kernel Linux non sono un caso isolato nel calendario 2026 del Catalogo KEV. Nello stesso periodo CISA ha aggiunto vulnerabilità critiche in prodotti molto usati anche in Europa: una falla di bypass dell’autenticazione in JFrog Artifactory, una vulnerabilità di path traversal in GitLab con punteggio CVSS massimo, un accesso non autorizzato al pannello di gestione remota di ConnectWise ScreenConnect e una falla di esecuzione di codice arbitrario in VMware vCenter Server. Il quadro che emerge è quello di un 2026 particolarmente denso per il catalogo KEV, con voci che toccano infrastrutture DevOps, virtualizzazione e ora anche il kernel del sistema operativo.
| Prodotto | CVE | CVSS | Tipo di impatto principale |
|---|---|---|---|
| Kernel Linux (kTLS) | CVE-2025-39682 | 9,8 | Divulgazione di memoria / DoS |
| GitLab | CVE-2026-85706 | 10,0 | Path traversal, esecuzione da remoto |
| ConnectWise ScreenConnect | CVE-2026-84869 | 9,9 | Accesso non autorizzato al pannello remoto |
| JFrog Artifactory | CVE-2026-82329 | 9,8 | Bypass dell’autenticazione |
| VMware vCenter Server | CVE-2026-59310 | 9,8 | Esecuzione di codice arbitrario da remoto |
Rispetto a queste altre voci, le tre CVE del kernel Linux hanno una caratteristica che le rende più difficili da gestire operativamente: richiedono un riavvio del sistema per applicare la correzione, non un semplice aggiornamento di pacchetto a caldo. Per infrastrutture con vincoli di uptime stringenti, questo significa pianificare finestre di manutenzione, spesso incompatibili con una scadenza di soli tre giorni.
L’impatto su NIS2 e Cyber Resilience Act per le aziende europee
Per le aziende italiane ed europee la scadenza CISA non ha valore legale diretto, ma si intreccia con obblighi molto concreti. La direttiva NIS2 impone ai soggetti essenziali e importanti misure di gestione del rischio che includono esplicitamente la gestione delle vulnerabilità e degli aggiornamenti di sicurezza. Una falla inserita nel Catalogo KEV, con conferma di sfruttamento attivo, rientra a pieno titolo tra i rischi che un’organizzazione soggetta a NIS2 deve trattare con priorità alta, e la mancata remediation in tempi ragionevoli può pesare in sede di verifica da parte dell’ACN o degli altri CSIRT nazionali.
Il Cyber Resilience Act aggiunge un ulteriore livello di responsabilità per i produttori di dispositivi con componenti digitali, inclusi quelli basati su Linux: appliance industriali, dispositivi IoT, sistemi embedded. Chi produce o distribuisce hardware con un kernel Linux al suo interno deve dimostrare un processo di gestione delle vulnerabilità e fornire aggiornamenti di sicurezza tempestivi ai clienti finali, non semplicemente rilasciare una patch quando conviene commercialmente.
La combinazione di questi due regolamenti sposta progressivamente il problema da buona pratica tecnica a obbligo normativo verificabile, con sanzioni che per NIS2 possono arrivare fino a 10 milioni di euro o al 2% del fatturato globale per i soggetti essenziali. Una falla KEV ignorata per mesi, in un’ispezione, difficilmente passa inosservata.
Come verificare se i propri server sono vulnerabili
Il primo passo pratico per qualsiasi team IT è identificare la versione del kernel effettivamente in esecuzione su ogni server, non quella indicata nella documentazione interna, che spesso non corrisponde alla realtà dopo mesi di aggiornamenti parziali. Un controllo rapido su sistemi Linux si esegue così:
# Verifica la versione del kernel in esecuzione
uname -r
# Confronta con le versioni corrette note
# 5.10.245 | 5.15.194 | 6.1.154 | 6.6.108 | 6.12.49 | 6.16.9
# Su distribuzioni Debian/Ubuntu, verifica gli aggiornamenti kernel disponibili
apt list --upgradable 2>/dev/null | grep -i linux-image
# Su distribuzioni RHEL/CentOS/Fedora
dnf check-update kernel
# Verifica se il modulo kernel-TLS è caricato
lsmod | grep tlsDopo aver mappato le versioni in uso, il passo successivo è pianificare l’aggiornamento partendo dai sistemi più esposti: server multi-tenant, host di virtualizzazione con bridge di rete configurati tramite ebtables, e appliance che utilizzano offload crittografico via AF_ALG. Su ambienti dove il riavvio immediato non è possibile, vale la pena valutare mitigazioni temporanee, come la restrizione dell’accesso locale non necessario e la revisione delle regole ebtables/SNAT esistenti, in attesa della finestra di manutenzione.
La checklist di remediation per i team IT italiani
- Inventariare tutti i sistemi Linux in produzione e la relativa versione del kernel
- Dare priorità ai sistemi multi-tenant, ai container host e alle appliance con bridge di rete
- Applicare gli aggiornamenti kernel alle versioni corrette (5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 o successive)
- Pianificare le finestre di riavvio necessarie, dato che la correzione non è applicabile a caldo
- Rafforzare i controlli di accesso locale sui sistemi non ancora aggiornati
- Rivedere le configurazioni ebtables/SNAT esistenti come mitigazione temporanea per CVE-2026-53266
- Documentare il processo di remediation ai fini della conformità NIS2
- Monitorare i log per crash kernel anomali, attività insolite su bridge di rete o uso anomalo di socket AF_ALG
Le reazioni del settore: vendor e ricercatori di sicurezza
Il tracker di sicurezza di Debian ha documentato pubblicamente la correzione upstream per CVE-2026-53266, confermando la natura del bug nel codice netfilter bridge e la disponibilità del fix nelle release corrette. SecurityAffairs ha ripreso l’annuncio CISA descrivendo le tre falle come critiche per la sicurezza dei server Linux e raccomandando un patching rapido, in linea con la prassi consolidata quando una vulnerabilità entra nel Catalogo KEV. Diversi analisti indipendenti hanno inoltre sottolineato che l’inclusione nel catalogo, di per sé, è un segnale che va oltre la teoria: significa che qualcuno, da qualche parte, sta già usando queste falle in attacchi reali, non solo in ambienti di ricerca.
Va detto con chiarezza che, al momento della pubblicazione di questo articolo, non risultano dichiarazioni pubbliche verificabili di CrowdStrike, Tenable, Qualys o Rapid7 specificamente dedicate a queste tre CVE. Le fonti disponibili si concentrano sulla conferma tecnica del bug e sulla sua presenza nel Catalogo KEV, più che su analisi di threat intelligence dettagliate legate a campagne specifiche.
Previsioni: cosa aspettarsi nei prossimi mesi
Guardando ai prossimi mesi, alcuni scenari appaiono più probabili di altri, sulla base dell’andamento del Catalogo KEV negli ultimi due anni e delle scadenze normative già fissate in Europa.
Primo, è probabile che altre vulnerabilità del kernel Linux entrino nel Catalogo KEV entro fine 2026, dato l’aumento dello scrutinio sui sottosistemi di rete e crittografia, componenti storicamente meno controllati rispetto al resto del kernel. Secondo, le principali distribuzioni enterprise, Red Hat, Canonical, SUSE, verranno probabilmente sotto pressione per accorciare i tempi tra la disponibilità di una patch upstream e il rilascio di un pacchetto kernel aggiornato per i propri clienti, un processo che oggi richiede spesso diverse settimane.
Terzo, con l’entrata a regime delle ispezioni ACN legate a NIS2 in Italia, è plausibile che le prime sanzioni collegate esplicitamente a una vulnerabilità KEV ignorata arrivino nel corso del 2027, trasformando quella che oggi è una raccomandazione tecnica in un precedente normativo concreto. Quarto, cresce la possibilità che bug di privilege escalation locale come CVE-2026-53266 vengano incatenati con vulnerabilità di container escape già note, un pattern di attacco sempre più comune negli ambienti cloud multi-tenant. Quinto, è ragionevole aspettarsi che entro poche settimane compaiano i primi exploit proof-of-concept pubblici per almeno una delle tre CVE, con conseguente aumento della scansione opportunistica da parte di attori meno sofisticati.
Perché questa vicenda riguarda anche chi non gestisce server Linux direttamente
Molte aziende italiane pensano di non essere toccate da un annuncio come questo perché non gestiscono direttamente infrastrutture Linux. La realtà è diversa: la stragrande maggioranza dei servizi cloud, delle piattaforme SaaS e persino di molti dispositivi di rete aziendali gira su Linux sotto il cofano, anche quando l’interfaccia utente finale non lo rende evidente. Un fornitore di hosting, una piattaforma di posta elettronica gestita, un servizio di backup cloud: tutti questi strati intermedi possono essere esposti alle stesse tre CVE, e la responsabilità di verificarlo ricade in parte anche sul cliente finale, soprattutto se soggetto a obblighi NIS2 come fornitore critico della propria filiera.
Per questo motivo, oltre alla verifica tecnica interna, molte organizzazioni dovrebbero contattare i propri fornitori cloud e di hosting per chiedere conferma esplicita dello stato di patching rispetto a queste tre CVE, invece di assumere che il problema riguardi solo chi amministra server fisici o virtuali in prima persona.
Domande frequenti
Cos’è il Catalogo KEV di CISA?
È l’elenco pubblico mantenuto dalla Cybersecurity and Infrastructure Security Agency statunitense che raccoglie le vulnerabilità per cui esistono prove concrete di sfruttamento attivo da parte di attaccanti, non semplici rischi teorici o ipotetici.
Quali sono le tre CVE del kernel Linux aggiunte a settembre 2026?
Sono CVE-2025-39682 (CVSS 9,8, falla nel percorso TLS del kernel), CVE-2026-53266 (CVSS 8,8, scrittura fuori limite in netfilter/ebtables) e CVE-2025-39964 (CVSS 7,8, race condition nei socket AF_ALG).
Qual è la scadenza per applicare le patch?
CISA ha fissato il termine al 21 settembre 2026 per le agenzie federali statunitensi, con inserimento nel catalogo avvenuto il 18 settembre 2026.
Le vulnerabilità colpiscono anche i server europei e italiani?
Sì, in linea di principio: i componenti coinvolti (kTLS, netfilter bridge, AF_ALG) sono presenti nei kernel general-purpose usati da distribuzioni server comuni in tutto il mondo, Italia inclusa. Non esistono però al momento stime pubbliche affidabili sul numero esatto di sistemi europei esposti.
Come faccio a sapere se il mio server Linux è vulnerabile?
Verifica la versione del kernel in esecuzione con il comando uname -r e confrontala con le versioni corrette (5.10.245, 5.15.194, 6.1.154, 6.6.108, 6.12.49, 6.16.9 o successive). Se il tuo kernel è precedente, il sistema è potenzialmente vulnerabile.
Le vulnerabilità richiedono accesso locale o possono essere sfruttate da remoto?
Tutte e tre richiedono un accesso locale autenticato al sistema, non uno sfruttamento remoto anonimo diretto da internet. Questo le rende particolarmente rilevanti per ambienti multi-tenant, cloud condivisi e sistemi con più utenti.
Cosa prevedono NIS2 e Cyber Resilience Act in casi come questo?
NIS2 impone ai soggetti essenziali e importanti la gestione prioritaria delle vulnerabilità note e sfruttate attivamente, con sanzioni fino a 10 milioni di euro o al 2% del fatturato globale. Il Cyber Resilience Act impone ai produttori di dispositivi con componenti Linux di garantire aggiornamenti di sicurezza tempestivi ai clienti.
Chi sta sfruttando attivamente queste falle?
Al momento non esistono attribuzioni pubbliche verificabili a un gruppo APT, una famiglia ransomware o una botnet specifica. CISA e i ricercatori confermano lo sfruttamento attivo ma senza dettagli sull’identità degli attaccanti.
