Falla critica CVE-2026-98432 in Linux: quali distro hanno le patch, il caso Ubuntu e come proteggere i server

Una vulnerabilità critica nel kernel Linux sta mettendo in allarme amministratori di sistema, provider cloud e responsabili della sicurezza. La falla, identificata come CVE-2026-98432 e valutata 9,8 su 10 secondo CVSS 3.1, può permettere a un aggressore remoto, senza autenticazione, di compromettere la memoria del kernel e, in determinate condizioni, eseguire comandi con privilegi root.

Secondo Marcus Hutchins, ci sarebbero oltre 2 milioni di server potenzialmente esposti e scansioni ripetute da parte degli aggressori sarebbero ormai all’ordine del giorno.

La vulnerabilità affonda le radici in una modifica introdotta nel kernel Linux 4.4, pubblicato a gennaio 2016. È rimasta quindi nel codice per oltre 10 anni, prima che le recenti attività di ricerca ne dimostrassero la pericolosità. Il 27 ottobre 2026, Anthropic ha descritto un exploit sviluppato con una versione sperimentale di Claude: una catena capace di ottenere una shell root attraverso la rete, senza alcuna interazione della vittima. Ne avevamo parlato nell’articolo dedicato a Claude e alla scoperta di vulnerabilità sfruttabili in Chrome, Windows e Linux.

Da allora la situazione si è evoluta rapidamente. Sono arrivate correzioni nel codice del kernel, bollettini dei principali produttori e aggiornamenti per numerose distribuzioni.

Il problema, al 5 novembre 2026, non riguarda più soltanto la scoperta della falla: occorre capire quali sistemi abbiano effettivamente ricevuto una versione corretta e quali continuino a utilizzare kernel vulnerabili.

Come funziona la falla CVE-2026-98432: una race condition durante le connessioni TCP

La vulnerabilità in questione interessa la gestione delle connessioni TCP su IPv4, in particolare una condizione di concorrenza durante la fase iniziale della comunicazione. Il normale handshake TCP prevede tre passaggi: il client invia SYN, il server risponde SYN-ACK e il client completa l’apertura della connessione con ACK.

Durante tale procedura, Linux conserva alcune informazioni in una struttura temporanea chiamata request_sock. Se il pacchetto SYN include opzioni nell’intestazione IPv4, il kernel deve mantenerle disponibili anche durante la generazione delle risposte.

Il problema nasce quando due CPU elaborano contemporaneamente operazioni riferite alla stessa richiesta: una può liberare la memoria che contiene le opzioni IPv4 mentre l’altra sta ancora accedendo a quelle informazioni per costruire un pacchetto SYN-ACK.

Si verifica così una condizione use-after-free con il kernel Linux che accede a memoria già rilasciata. A seconda delle circostanze, le conseguenze possono comprendere arresti anomali, divulgazione di informazioni presenti in memoria o corruzione di strutture interne. Un aggressore sufficientemente preparato può sfruttare tali condizioni per arrivare all’esecuzione di codice.

Quali versioni del kernel Linux contengono la patch

La vulnerabilità interessa i kernel a partire dalla versione 4.4, ma diverse famiglie più aggiornate hanno già ricevuto la correzione.

Secondo la ricostruzione di Akamai, le prime versioni corrette dei principali rami upstream sono Linux 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56 e 7.2.10. La correzione figura anche nella serie 7.3.

C’è un aspetto cruciale da sottolineare: Debian, Ubuntu, Red Hat e altre distribuzioni possono integrare le modifiche di sicurezza in kernel con numerazioni precedenti, mediante backport delle patch. Un sistema basato su Linux 5.14, per esempio, non è automaticamente vulnerabile se il produttore ha incorporato la correzione nel proprio pacchetto.

Il controllo deve quindi riguardare la versione esatta del kernel distribuita dal produttore e l’advisory corrispondente, non soltanto il numero della serie Linux.

Ubuntu: patch preparate, ma disponibilità ancora non uniforme

Il 2 novembre Canonical ha pubblicato una comunicazione ufficiale spiegando che i kernel corretti per Ubuntu 22.04 LTS e versioni successive si trovano, per diversi rami, nel repository -proposed, destinato alle verifiche prima del rilascio ordinario.

Per Ubuntu 26.04 LTS, Canonical indica il pacchetto 7.0.0-43.43; per Ubuntu 24.04 LTS il riferimento è 6.8.0-149.149, mentre Ubuntu 22.04 LTS utilizza 5.15.0-203.213. Il blog indica inoltre una correzione per Ubuntu 26.10 nella versione 7.3.0-10.10.

Esiste però una discrepanza da non ignorare. La scheda ufficiale della vulnerabilità, aggiornata il 4 novembre, continua a segnalare lavori in corso per vari pacchetti, compresi alcuni relativi a Ubuntu 26.10: non corrisponde al vero che tutte le installazioni di una determinata release risultano già protette. Canonical sta eseguendo verifiche su oltre 2.000 dispositivi e server certificati prima di promuovere gli aggiornamenti nei canali ordinari.

Le correzioni per Ubuntu 20.04 LTS e release precedenti ancora supportate seguono invece le rispettive modalità di manutenzione, comprese quelle previste da Ubuntu Pro ed Extended Security Maintenance.

Chi gestisce sistemi Ubuntu in produzione dovrebbe evitare di abilitare tutto il repository -proposed soltanto per ottenere il nuovo kernel. È preferibile verificare lo specifico metapacchetto, le dipendenze e le istruzioni Canonical, quindi applicare la correzione dopo averne valutato la compatibilità con il server.

Debian, Red Hat, AlmaLinux, Rocky Linux e Amazon Linux: dove sono disponibili gli aggiornamenti

Per Debian la situazione appare più definita. Il Debian Security Tracker conferma la disponibilità dei pacchetti corretti nei repository di sicurezza: Debian 12 Bookworm dispone della versione 6.1.190-1 e Debian 13 Trixie della 6.12.115-2. Anche i rami Forky e Sid riportano versioni corrette.

AlmaLinux ha distribuito le patch nei repository di produzione il 2 novembre. Il comunicato ufficiale indica come prime versioni corrette 4.18.0-553.182.1.el8_10 per AlmaLinux 8, 5.14.0-687.64.1.el9_8 per AlmaLinux 9 e 6.12.0-211.72.1.el10_2 per AlmaLinux 10.

Red Hat ha pubblicato diversi aggiornamenti per RHEL 8, 9 e 10, con disponibilità variabile secondo versione, kernel e ramo di manutenzione. L’elenco ufficiale degli errata permette di verificare le correzioni distribuite; alcuni componenti di OpenShift risultano ancora interessati. Anche Rocky Linux ha pubblicato advisory specifici, tra cui RLSA-2026:93414.

Amazon conferma la disponibilità delle correzioni per Amazon Linux 2 e Amazon Linux 2023. Nel secondo caso, le istanze vincolate a una release specifica devono utilizzare almeno la 2023.12.20261102 per ricevere i kernel aggiornati. SUSE ha pubblicato numerosi advisory per le proprie distribuzioni, ma la disponibilità varia tra prodotti, Service Pack e pacchetti kernel: conviene consultare la scheda CVE SUSE.

Come controllare se il proprio server Linux è protetto

La prima verifica consiste nell’identificare distribuzione e kernel in esecuzione. Da terminale basta impartire i seguenti due comandi:

cat /etc/os-release

uname -r

Su Debian e Ubuntu si possono verificare gli aggiornamenti disponibili con sudo apt update e apt list --upgradable. Sulle distribuzioni basate su Red Hat, invece, è possibile utilizzare sudo dnf updateinfo list security per consultare gli aggiornamenti di sicurezza segnalati nei repository configurati.

Una volta accertata la disponibilità del kernel corretto, su Debian e Ubuntu si può procedere con sudo apt full-upgrade, mentre sulle distribuzioni che utilizzano DNF il comando ordinario è sudo dnf upgrade.

In entrambi i casi, dopo l’installazione del nuovo kernel, bisogna riavviare il sistema e ripetere uname -r per verificare quale versione sia effettivamente in esecuzione. Nel caso di server di produzione si può programmare il riavvio, verificare la disponibilità della console di emergenza e controllare il corretto ripristino dei servizi.

Come proteggere Linux quando la patch non è ancora disponibile: nftables

Per i sistemi sui quali non è ancora possibile installare un kernel corretto, Red Hat propone una mitigazione temporanea particolarmente interessante: bloccare i pacchetti TCP IPv4 che contengono opzioni nell’intestazione IP.

Con nftables si può creare una regola che intercetta il traffico interessato prima che raggiunga il normale percorso di elaborazione dei pacchetti destinati al sistema:

table inet cve_2026_98432 {
chain input {
type filter hook input priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 counter drop
}
}

Salvando il contenuto in un file chiamato cve-2026-98432.nft, si può controllarne la sintassi con sudo nft --check --file cve-2026-98432.nft e applicarlo con sudo nft --file cve-2026-98432.nft. Per verificare che la regola sia attiva basta eseguire sudo nft list table inet cve_2026_98432.

Il controllo ip hdrlength > 5 individua le intestazioni IPv4 più lunghe dei normali 20 byte, caratteristica che indica la presenza di opzioni IP. La regola scarta quindi i pacchetti TCP IPv4 che trasportano tali informazioni, riducendo l’esposizione al meccanismo di attacco documentato.

Il filtro può interferire con applicazioni che utilizzano legittimamente le opzioni IPv4 e deve essere applicato nel punto di ingresso corretto del traffico. Occorre valutare attentamente configurazioni con container, namespace di rete, firewall esterni e servizi distribuiti su più macchine.

Prima di intervenire su un server remoto è opportuno predisporre un accesso alternativo. La regola, inoltre, non diventa automaticamente persistente dopo il riavvio: bisogna integrarla nella configurazione firewall esistente. Quando il kernel corretto è operativo, si può eliminare la tabella temporanea con sudo nft delete table inet cve_2026_98432.

Disabilitare MPTCP non basta: la differenza tra ridurre il rischio e correggere la falla

Alcune indicazioni circolate online suggeriscono di disabilitare MPTCP (Multipath TCP), un’estensione del protocollo TCP che permette di utilizzare più connessioni di rete contemporaneamente per trasferire gli stessi dati. Per esempio, un dispositivo può sfruttare sia WiFi sia rete mobile, migliorando la continuità della comunicazione se uno dei collegamenti si interrompe. Disabilitare MPTCP mediante sudo sysctl -w net.mptcp.enabled=0 può ostacolare l’exploit dimostrato da Anthropic, ma non elimina la vulnerabilità, che interessa anche il normale funzionamento di TCP su IPv4.

Come chiariscono Canonical e Red Hat, la race condition interessa il codice TCP IPv4 anche al di fuori di MPTCP. Red Hat segnala espressamente che RHEL risulta vulnerabile nonostante MPTCP sia disabilitato per impostazione predefinita.

Si possono controllare i parametri con sysctl net.mptcp.enabled e sysctl net.ipv4.tcp_migrate_req, oppure esaminare i listener MPTCP tramite sudo ss -M -l -n -p -e.

Sono verifiche utili a comprendere la configurazione, non test capaci di certificare l’assenza della vulnerabilità. Inoltre, modificare un parametro sysctl non garantisce che i socket già creati cambino immediatamente comportamento.

Una vulnerabilità critica, ma non tutti i server Linux sono esposti

La CVE-2026-98432 evidenzia un problema concreto nella gestione delle vulnerabilità del kernel: una modifica risalente a oltre 10 anni fa può diventare il punto di partenza per un attacco remoto molto sofisticato. L’impiego di Claude dimostra inoltre come l’analisi automatizzata del codice possa contribuire a individuare e concatenare condizioni di sfruttamento particolarmente difficili da riconoscere.

L’exploit di Anthropic funziona nelle condizioni descritte dai ricercatori; ciò non significa che tutti i server Linux esposti a Internet possano essere compromessi con la stessa facilità, né che le scansioni riportate online abbiano già prodotto accessi root.

Per chi amministra Linux la priorità consiste nel verificare gli aggiornamenti del kernel, installare la correzione fornita dal produttore e riavviare i sistemi interessati. Dove la patch non fosse ancora disponibile, il filtraggio delle opzioni IPv4 costituisce una misura temporanea documentata, purché compatibile con i servizi utilizzati.

Il caso Ubuntu merita particolare attenzione per la distanza ancora esistente, su alcuni rami, tra la disponibilità delle correzioni nei repository di prova e la loro distribuzione ordinaria. Non serve allarmismo, ma neppure attendere che compaia un exploit pubblico prima di intervenire.

Quando una vulnerabilità consente potenzialmente l’esecuzione di codice nel kernel senza autenticazione, la finestra tra scoperta e aggiornamento diventa una questione concreta di sicurezza operativa.