CISA ha inserito nel catalogo Known Exploited Vulnerabilities due vulnerabilità del Linux Kernel per le quali esistono prove di sfruttamento attivo: CVE-2025-39964 e CVE-2026-53266. Per le aziende non è un invito ad aggiornare “Linux” in modo indiscriminato, ma a identificare con precisione kernel, distribuzione e pacchetti effettivamente in uso, verificare gli advisory del fornitore e pianificare il riavvio necessario a rendere operativo il nuovo kernel.
Il punto più importante è la priorità: una CVE presente nel catalogo KEV merita un trattamento diverso da una vulnerabilità soltanto teorica. Il punteggio CVSS resta utile, ma non sostituisce l’evidenza di sfruttamento. Server, host di virtualizzazione, nodi container, appliance e sistemi embedded gestiti da un vendor possono tutti includere un kernel Linux, con modalità di aggiornamento molto diverse.
Che cosa ha comunicato CISA
Il 18 settembre 2026, la Cybersecurity and Infrastructure Security Agency statunitense ha aggiunto al catalogo KEV:
- CVE-2025-39964, descritta da CISA come una race condition nel Linux Kernel;
- CVE-2026-53266, descritta come una scrittura fuori dai limiti nel Linux Kernel.
Il catalogo KEV è vincolante per le agenzie civili federali statunitensi secondo le direttive applicabili, ma CISA raccomanda anche alle altre organizzazioni di usare l’elenco per definire le priorità di remediation. Per una PMI italiana il valore operativo è proprio questo: separare le vulnerabilità già sfruttate da quelle che possono essere gestite nel normale ciclo di manutenzione.
Non bisogna però tradurre l’avviso in una versione universale da installare. Il Linux Kernel viene distribuito attraverso pacchetti, backport e rami mantenuti dai singoli vendor. Due sistemi con lo stesso numero di versione principale possono avere uno stato di sicurezza differente.
Le due vulnerabilità, in breve
| Vulnerabilità | Componente | Problema | Verifica iniziale |
|---|---|---|---|
| CVE-2025-39964 | crypto / AF_ALG | Scritture concorrenti sullo stesso socket possono lasciare uno stato interno incoerente | Advisory della distribuzione e pacchetto kernel installato |
| CVE-2026-53266 | netfilter bridge / ebtables SNAT | Riscrittura ARP non resa scrivibile correttamente, con possibile out-of-bounds write | Uso di bridge, ebtables e immagini o appliance coinvolte |
CVE-2025-39964: race condition nel sottosistema crittografico
La descrizione pubblicata dal progetto CVE e ripresa dagli advisory dei vendor riguarda af_alg_sendmsg. Due scritture concorrenti sullo stesso socket AF_ALG possono interlecciare i dati e creare incoerenze nello stato interno. La correzione introduce un meccanismo di proprietà esclusiva durante la scrittura.
L’advisory Canonical classifica la vulnerabilità come locale, con privilegi bassi richiesti e senza interazione dell’utente. Soprattutto, mostra perché non conviene affidarsi a una lista generica di versioni: Ubuntu pubblica lo stato per release, variante del kernel e pacchetto, includendo build standard, low-latency, realtime, cloud e OEM. È questo livello di dettaglio che deve guidare la remediation.
CVE-2026-53266: ebtables, SNAT e riscrittura ARP
La seconda vulnerabilità riguarda il percorso ebt_snat di netfilter bridge. La descrizione ufficiale indica che la riscrittura ARP deve operare su memoria resa scrivibile; in caso contrario può verificarsi una scrittura fuori dai limiti. Amazon Linux riporta correzioni specifiche per diversi rami del kernel e uno stato distinto per ciascuna piattaforma.
La presenza di bridge Linux ed ebtables è comune in scenari di virtualizzazione, networking containerizzato e appliance. Questo non significa che ogni host sia automaticamente sfruttabile: configurazione, pacchetto, backport del vendor e superficie esposta vanno verificati insieme.
Perché il solo numero di kernel non basta
Il comando uname -r è un buon punto di partenza, non una diagnosi. Le distribuzioni enterprise mantengono spesso un ramo stabile applicando correzioni di sicurezza senza adottare immediatamente una nuova versione upstream. Il risultato è che un kernel con numero apparentemente “vecchio” può essere corretto, mentre un’immagine personalizzata o non più supportata può restare vulnerabile.
La verifica dovrebbe quindi correlare almeno cinque informazioni:
- distribuzione e release effettive;
- pacchetto kernel installato e kernel attualmente avviato;
- repository e canale di supporto configurati;
- advisory del vendor per quella specifica variante;
- necessità di riavvio dopo l’installazione.
Questo approccio è coerente con una gestione strutturata dei server Linux. Le aziende che stanno introducendo automazioni possono collegare inventario, patching e verifica post-riavvio alle pratiche già descritte nel nostro approfondimento sui RHEL System Roles per la gestione dei server Linux.
Dove cercare i sistemi coinvolti
Server e macchine virtuali
Partire dai server esposti a Internet e dai sistemi che ospitano servizi critici, poi estendere la verifica a macchine virtuali, bastion host, nodi di monitoraggio e server di backup. Un inventario incompleto è il primo ostacolo: host spenti, template di VM e immagini golden possono reintrodurre un kernel vulnerabile anche dopo il primo giro di aggiornamenti.
Container e nodi Kubernetes
I container condividono il kernel dell’host. Aggiornare un’immagine applicativa non corregge il kernel del nodo; viceversa, una patch del nodo richiede coordinamento per drain, riavvio e rientro nel cluster. Occorre includere worker node, control plane gestiti internamente e pool autoscalati basati su immagini non aggiornate.
Appliance, NAS, firewall e dispositivi embedded
Molti prodotti incorporano Linux ma non consentono l’installazione diretta dei pacchetti della distribuzione. In questi casi si deve attendere e applicare il firmware o l’aggiornamento del produttore. Installare manualmente un kernel generico può rendere l’appliance non supportata o non avviabile.
Checklist operativa per le aziende
- Cercare entrambe le CVE negli strumenti di vulnerability management, negli advisory delle distribuzioni e nei portali dei produttori di appliance.
- Esportare l’inventario con distribuzione, release, pacchetto kernel, kernel in esecuzione, ruolo del sistema e proprietario del servizio.
- Dare priorità ai sistemi esposti, multi-tenant, di virtualizzazione, container e networking, senza escludere host interni critici.
- Verificare il fix del vendor, evitando di dedurre lo stato soltanto dal numero upstream o dal CVSS.
- Testare driver, moduli DKMS, agent di sicurezza, software di backup e dipendenze di rete su un gruppo pilota.
- Installare gli aggiornamenti tramite i repository supportati o il firmware ufficiale.
- Riavviare in finestra di manutenzione quando richiesto: un pacchetto installato non cambia il kernel già caricato in memoria.
- Confermare il kernel avviato e rieseguire la scansione; documentare eccezioni e sistemi in attesa del vendor.
- Aggiornare template e immagini per evitare che nuovi server o nodi nascano già vulnerabili.
Per organizzare la priorità senza rincorrere ogni bollettino, è utile integrare il catalogo KEV nel processo di vulnerability management, come spiegato anche nell’analisi su vulnerability management e automazione della difesa. La stessa disciplina si applica ai sistemi isolati: il nostro articolo su Ubuntu Enterprise Store nelle reti isolate affronta il problema della distribuzione controllata degli aggiornamenti.
Come ridurre il rischio durante il patching
Il kernel è un componente ad alto impatto operativo. Il piano deve prevedere snapshot o backup coerenti, console fuori banda, verifica del bootloader, spazio sufficiente in /boot e una procedura di rollback. Nei cluster è preferibile aggiornare un nodo alla volta, drenando i carichi e verificando salute e connettività prima di procedere.
Se il vendor non ha ancora pubblicato una correzione, l’eccezione non dovrebbe trasformarsi in attesa indefinita. Registrare il rischio, limitare privilegi e accessi locali, segmentare il sistema, ridurre le funzioni non necessarie e chiedere al produttore una data di rilascio. Le mitigazioni compensative devono essere considerate temporanee: l’obiettivo resta installare una build supportata che includa la correzione.
Domande frequenti
Essere nel catalogo CISA KEV significa che ogni sistema Linux è compromesso?
No. Significa che esistono prove di sfruttamento della vulnerabilità. Occorre verificare se lo specifico kernel o prodotto è interessato e cercare indicatori di compromissione secondo le indicazioni del proprio vendor e del team di sicurezza.
È sufficiente aggiornare i pacchetti senza riavviare?
Normalmente no: il kernel in esecuzione resta caricato finché il sistema non viene riavviato, salvo tecnologie di live patching supportate e applicabili alla specifica correzione. Dopo l’intervento va confermata la versione realmente avviata.
Il CVSS più basso può essere ignorato?
No. Il CVSS descrive caratteristiche tecniche, mentre il catalogo KEV aggiunge l’evidenza di sfruttamento. La priorità aziendale deve considerare entrambi, insieme a esposizione, criticità del servizio e controlli presenti.
I container devono essere ricostruiti?
La correzione del kernel si applica ai nodi host. Tuttavia vanno aggiornate anche immagini di nodo, template e autoscaling configuration; le immagini applicative devono seguire il proprio ciclo di manutenzione, ma non sostituiscono il patching dell’host.
Come ci si comporta con un’appliance che usa Linux?
Si verifica l’advisory del produttore e si applica il firmware ufficiale. Se lo stato non è pubblicato, è opportuno aprire un ticket indicando le due CVE e chiedere versione corretta, mitigazioni e tempi di rilascio.
Conclusione
Le due vulnerabilità Linux Kernel aggiunte da CISA al KEV richiedono un controllo rapido, ma preciso. Inventario, advisory del vendor, test, riavvio e verifica finale sono più affidabili di una corsa al numero di versione più recente. Per le aziende con molti server o appliance, questo evento è anche un test della maturità del processo: se non è possibile sapere in poche ore quali kernel sono in uso, il problema da correggere non è soltanto la singola CVE.
EP Consulting può supportare inventario, valutazione degli advisory, pianificazione delle finestre di manutenzione e verifica post-aggiornamento su infrastrutture Linux, virtuali e containerizzate.