CVE-2026-98432 è una falla nel modo in cui il kernel Linux accetta le richieste di connessione TCP. Permette a un aggressore remoto, senza password, di mandare in crash il server o di corrompere la memoria del kernel. Il team CVE del kernel Linux le assegna 9,8 su 10, e Anthropic afferma che il suo modello Claude ha scritto un exploit che dà a un aggressore i privilegi di root sui server che accettano connessioni MPTCP. La correzione è nel kernel ufficiale e Debian l'ha già distribuita, ma al 30 ottobre 2026 Ubuntu la segnala come "work in progress" (in lavorazione) per 22.04, 24.04 e 26.04, e Red Hat indica RHEL 8, 9 e 10 come interessati e senza aggiornamento. Finché non arriva l'aggiornamento: disattiva MPTCP se non ti serve, blocca i pacchetti IPv4 che contengono opzioni IP, limita chi può raggiungere i tuoi server e pianifica il riavvio.

Che cos'è CVE-2026-98432 e perché riguarda la tua azienda?

Secondo il record CVE ufficiale, la falla si trova nel momento in cui si completa un handshake TCP su IPv4: il kernel passa alla nuova connessione le opzioni IP salvate con la richiesta di connessione senza copiarle, mentre un'altra CPU può, in quello stesso istante, elaborare una richiesta duplicata e costruire una risposta a partire da quelle opzioni. Se il kernel libera prima quella memoria, poi la legge dopo averla liberata, un errore noto come use-after-free. La falla esiste dal kernel 4.4. Il team CVE del kernel l'ha pubblicata il 15 ottobre 2026 e le ha dato 9,8 su 10 perché è raggiungibile dalla rete, durante l'handshake e prima di qualsiasi login, senza alcuna interazione dell'utente.

In un post del 27 ottobre, Anthropic ha scritto che Claude ha realizzato un exploit che consente a un aggressore remoto senza credenziali di eseguire comandi come root sui server Linux che accettano connessioni MPTCP, cioè TCP multipath. Nel suo test l'exploit ha impiegato 48 minuti per far trapelare un indirizzo dalla memoria del kernel, poi 5 minuti per arrivare all'esecuzione di comandi. Peggio ancora, un tentativo fallito non manda in crash il server; fallisce solo quella connessione, quindi un aggressore può continuare a riprovare senza che nessuno se ne accorga. Anthropic non ha pubblicato l'exploit vero e proprio.

Red Hat descrive l'impatto principale come crash del server e denial of service, con possibile corruzione della memoria. Nell'edizione del 30 ottobre del catalogo delle vulnerabilità note sfruttate della CISA, la falla non era ancora stata inserita.

L'aggiornamento è già arrivato alla tua distribuzione?

Questo è lo stato riportato dalla pagina ufficiale di ogni distribuzione il 30 ottobre 2026:

DistribuzioneStato
Ubuntu 22.04, 24.04, 26.04 e 26.10Vulnerabile, correzione "work in progress" (in lavorazione); per la 24.04 nel kernel 6.8.0-149 (pagina di Ubuntu)
Ubuntu 16.04, 18.04 e 20.04Vulnerabile
Red Hat Enterprise Linux 8, 9 e 10Interessato, nessun aggiornamento rilasciato (pagina di Red Hat)
Red Hat Enterprise Linux 6 e 7Non interessato
Debian 12 e 13Corretto in 6.1.190-1 e 6.12.113-1 (tracker di Debian)

Nel kernel ufficiale, la correzione è arrivata con le versioni 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3. Ma la maggior parte dei server usa il kernel della propria distribuzione, quindi quello che conta è la pagina della tua distribuzione, non il numero di versione ufficiale.

Come capire se un server è esposto?

Esegui questi comandi su ogni server Linux che accetta connessioni da internet:

uname -r
cat /proc/sys/net/mptcp/enabled
ss -Mln
cat /proc/sys/net/ipv4/tcp_migrate_req
  • Il primo mostra la versione del kernel; confrontala con la pagina della tua distribuzione. Su Ubuntu 24.04, per esempio, tutte le versioni disponibili oggi sono ancora senza correzione.
  • Un valore 1 nel secondo significa che MPTCP è attivo, che è l'impostazione predefinita secondo la documentazione del kernel.
  • Il terzo elenca i servizi che accettano connessioni MPTCP. Qualsiasi servizio compaia è il tipo di bersaglio che Anthropic ha sfruttato. Attenzione ai programmi scritti in Go: secondo le note di rilascio di Go 1.24, i loro listener ora usano MPTCP per impostazione predefinita dove è supportato.
  • Il quarto dovrebbe restituire 0; secondo il record CVE, il secondo percorso della falla funziona solo quando il valore è 1.

La soluzione temporanea finché non arriva l'aggiornamento: 5 passi

  1. Se la tua distribuzione ha già la correzione, installala subito e riavvia. Su Debian 12 e 13, per esempio: 
    sudo apt update && sudo apt upgrade
sudo reboot
    Il nuovo kernel non ti protegge finché il server non lo sta effettivamente usando.
  2. Disattiva MPTCP se nessun servizio ne ha bisogno. Così chiudi il tipo di bersaglio che Anthropic ha sfruttato: 
    sudo sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" | sudo tee /etc/sysctl.d/99-disable-mptcp.conf
    Il primo comando applica subito l'impostazione; il secondo la mantiene dopo un riavvio. La documentazione del kernel precisa che l'impostazione vale per singolo namespace di rete, quindi applicala anche all'interno dei container. I programmi in Go tornano automaticamente al TCP normale quando MPTCP non è disponibile. Ma né Anthropic né alcuna distribuzione dice che disattivarlo elimini la falla in sé, quindi riduce il rischio invece di curarlo.
  3. Blocca i pacchetti TCP che contengono opzioni IPv4. Lo scenario di valutazione del record CVE presuppone un aggressore che invia una richiesta di connessione con l'opzione IPv4 Record Route o Timestamp, e il normale traffico web, email e SSH non ha bisogno di quelle opzioni. Chiedi al tuo amministratore di rete una regola firewall che scarti i pacchetti TCP in entrata con un'intestazione IPv4 più lunga di 20 byte, e provala prima su un solo server. Nessuna distribuzione dice che questo blocchi la falla, ma elimina la condizione su cui si basa la valutazione.
  4. Limita chi può raggiungere i tuoi server. La falla ha bisogno di una porta TCP aperta che accetti connessioni, quindi chiudi ogni porta che non ti serve e rendi SSH e i pannelli di amministrazione raggiungibili solo da indirizzi IP specifici o tramite VPN. Se il sito sta dietro un intermediario come una CDN, fai accettare al server di origine solo le connessioni provenienti dagli indirizzi di quel servizio.
  5. Prepara l'aggiornamento prima che arrivi. Segui le pagine di Ubuntu e Red Hat dedicate a questa CVE, approva in anticipo l'aggiornamento del kernel e fissa una finestra di riavvio, così la correzione viene installata il giorno stesso in cui esce. Tieni d'occhio il log del kernel per individuare crash che citano ip_options_build: 
    sudo journalctl -k | grep -i ip_options_build
    Un log tranquillo però non significa sicurezza, perché un tentativo fallito non manda in crash il server.

E se i tuoi server sono presso un fornitore di hosting?

Con l'hosting condiviso e i servizi gestiti, il kernel appartiene al fornitore, non a te. Fagli tre domande: quale distribuzione e quale versione del kernel usano i suoi server, quando installerà la correzione e cosa sta facendo nel frattempo per ridurre il rischio. Un server privato virtuale (VPS) di solito lascia il kernel nelle tue mani, quindi applica tu stesso i passi indicati sopra.

Il punto di vista di Origami

Come nel nostro articolo sulle vulnerabilità di PHP, quando l'aggiornamento ufficiale tarda, sono i passi temporanei a proteggere i server nei primi giorni. Riducono però soltanto il rischio; l'unica cura è il kernel corretto dopo un riavvio. In Origami possiamo controllare i tuoi server Linux, applicare i passi temporanei senza interrompere i tuoi servizi e installare la correzione appena esce. Contattaci.

In sintesi

  • CVE-2026-98432 è una falla del kernel Linux valutata 9,8 su 10 dal team del kernel, che attacca il server da remoto durante l'handshake TCP, prima di qualsiasi login.
  • Debian ha distribuito la correzione; Ubuntu e Red Hat non l'avevano ancora fatto al 30 ottobre 2026.
  • Nel frattempo: disattiva MPTCP se non ti serve, blocca i pacchetti TCP con opzioni IPv4 e chiudi le porte che non usi.
  • Installa il kernel corretto appena esce e riavvia; i passi temporanei non lo sostituiscono.

Fonti