Vulnerabilità critica del kernel Linux CVE-2026-98432: come controllare e aggiornare il tuo VPS

Nell'ottobre del 2026, è stata scoperta una vulnerabilità critica, CVE-2026-98432 , nel kernel Linux, classificata con un punteggio di 9.8 su 10 sulla scala CVSS. Essa influisce sulla gestione delle connessioni TCP IPv4 in entrata e, in determinate condizioni, consente a un utente malintenzionato di ottenere l'accesso root a un server da remoto, senza password e senza che sia richiesto alcun intervento da parte dell'amministratore.

Di seguito sono riportati i nomi delle persone interessate, come controllare il server e come proteggerlo. Tutti i comandi vengono eseguiti come root o con sudo.

La vulnerabilità in breve

• Che cosa è: Un bug di tipo use-after-free nel codice che gestisce le connessioni TCP IPv4, causato da una condizione di gara (race condition). L'attaccante invia pacchetti appositamente creati a qualsiasi porta TCP aperta.
• Nuclei interessati: ogni versione a partire da Linux 4.4, il che significa praticamente ogni distribuzione attuale.
• IPv6 non è interessato dal bug principale.
• Quanto è reale la minaccia: I ricercatori di Anthropic hanno dimostrato una catena di exploit funzionante che ha permesso di ottenere l'accesso root su un server con Multipath TCP (MPTCP) abilitato in circa 53 minuti. Il codice dell'exploit non è stato pubblicato.
• Attacchi in natura: Al 1° novembre 2026, non è stato segnalato alcun caso di sfruttamento delle vulnerabilità. Questo è un motivo per aggiornare con calma, non per rimandare.

I servizi Go comportano un rischio a parte. Dalla versione 1.24 di Go, i programmi server su Linux si mettono in ascolto sulle porte tramite MPTCP per impostazione predefinita, quando il kernel lo consente. Un amministratore potrebbe persino non sapere che il proprio server accetta tali connessioni. Tra i programmi più diffusi, Xray funziona in questo modo: i suoi sviluppatori hanno già rilasciato una versione di emergenza, la v26.10.31, che disabilita MPTCP per impostazione predefinita.

Ogni VPS esegue il proprio kernel, quindi è necessario aggiornare manualmente il kernel all'interno del server. Noi ci occupiamo dell'aggiornamento dei nodi di virtualizzazione.

Esiste una soluzione per il tuo sistema?

Situazione al 1° novembre 2026. Gli aggiornamenti vengono rilasciati quasi quotidianamente: consultate i link alla fine di questo articolo per conoscere lo stato attuale.

Passaggio 1. Verifica quale kernel stai eseguendo

Scopri la versione del kernel in esecuzione:

uname -r

Il solo numero di versione non fornisce alcuna informazione utile: le distribuzioni integrano le correzioni nei propri kernel senza modificare la versione di base. È più affidabile controllare il registro delle modifiche del pacchetto del kernel: se menziona il numero CVE, la correzione è già installata.

Debian e Ubuntu:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep CVE-2026-98432

Su Debian, il uname -v Il comando mostra anche la versione completa del pacchetto del kernel in esecuzione: confrontala con la tabella sopra.

AlmaLinux, Rocky Linux, RHEL, Oracle Linux:

rpm -q --changelog kernel-core-$(uname -r) | grep CVE-2026-98432

Se il comando non stampa nulla, il kernel in esecuzione è vulnerabile.

Successivamente, verifica quali servizi accettano connessioni tramite MPTCP. Server come questi sono stati presi di mira nell'attacco dimostrato:

ss -lnMp

Un output vuoto significa che non ci sono listener MPTCP.

Passaggio 2. Installa il kernel corretto

Prima di aggiornare il kernel, esegui un backup o uno snapshot del tuo server.

Debian 12 e 13

I kernel corretti si trovano nel repository di sicurezza. Assicurati che sia abilitato:

grep -r security.debian.org /etc/apt/sources.list /etc/apt/sources.list.d/

Se non viene trovato nulla, aggiungi il security.debian.org repository per la tua release. Quindi aggiorna il sistema:

apt update
apt full-upgrade
reboot

Ubuntu

I kernel corretti non sono ancora stati rilasciati. Verifica la presenza di aggiornamenti:

apt update
apt list --upgradable | grep linux-image

Se il tuo server è collegato a Ubuntu Pro, puoi consultare il piano di riparazione:

pro fix CVE-2026-98432 --dry-run

Una volta rilasciato l'aggiornamento, installatelo e riavviate il computer:

apt update
apt full-upgrade
reboot

Nel frattempo, assicurati di applicare la protezione temporanea descritta al punto 3.

AlmaLinux 8, 9, 10

I kernel corretti sono attualmente disponibili solo nel repository di test. Installateli se vi sentite a vostro agio a farlo su un server di produzione e assicuratevi di creare uno snapshot prima dell'aggiornamento:

dnf install -y almalinux-release-testing
dnf update 'kernel*' --enablerepo=almalinux-testing
dnf config-manager --disable almalinux-testing
reboot

Dopo il riavvio, confronta uname -r con le versioni indicate nella tabella sopra. Se preferisci non installare i pacchetti di test, applica la protezione temporanea e attendi che la correzione raggiunga il repository principale.

Rocky Linux e altri sistemi basati su RHEL

Non è ancora disponibile una soluzione. Puoi rimanere aggiornato seguendo questi passaggi:

dnf --refresh updateinfo info --all --cves CVE-2026-98432

Una volta rilasciata la correzione:

dnf update kernel
reboot

Dopo l'aggiornamento: è necessario riavviare il sistema.

Il nuovo kernel avrà effetto solo dopo un riavvio. Per verificare se è necessario un riavvio:

# Debian and Ubuntu
[ -f /var/run/reboot-required ] && echo "Reboot required"

# AlmaLinux, Rocky, RHEL
needs-restarting -r

Dopo il riavvio, ripetere il controllo a partire dal passaggio 1.

Fase 3. Protezione temporanea fino alla disponibilità di un kernel corretto.

Queste misure riducono il rischio ma non sostituiscono un aggiornamento del kernel.

Blocca i pacchetti di attivazione

L'attacco utilizza pacchetti TCP con opzioni IP nell'intestazione IPv4. Questi pacchetti non compaiono praticamente mai nel traffico normale e la RFC 7126 raccomanda già di bloccarli. La regola nftables riportata di seguito blocca tutti i pacchetti TCP IPv4 in entrata con opzioni e non influisce su IPv6, UDP o ICMP. Funziona in combinazione con ufw e firewalld.

Installa nftables se non è già installato:

# Debian and Ubuntu
apt install -y nftables

# AlmaLinux, Rocky, RHEL
dnf install -y nftables

Crea il file delle regole:

cat > /etc/cve-2026-98432.nft <<'EOF'
table ip cve_2026_98432 {
    chain pre {
        type filter hook prerouting priority -300; policy accept;
        meta l4proto tcp ip hdrlength gt 5 counter drop
    }
}
EOF

Per ripristinare la regola dopo ogni riavvio, crea un servizio systemd:

cat > /etc/systemd/system/cve-2026-98432.service <<'EOF'
[Unit]
Description=Mitigation for CVE-2026-98432
After=network-pre.target nftables.service firewalld.service ufw.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStartPre=-/usr/sbin/nft delete table ip cve_2026_98432
ExecStart=/usr/sbin/nft -f /etc/cve-2026-98432.nft
ExecStop=/usr/sbin/nft delete table ip cve_2026_98432

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now cve-2026-98432.service

Verifica che la regola sia stata caricata:

nft list table ip cve_2026_98432

Se si riavvia il servizio nftables con un comando globale flush ruleset regola, esegui systemctl restart cve-2026-98432 successivamente.

Importante: non applicare questa regola alle reti che utilizzano etichette CIPSO (SELinux o Smack NetLabel), dove normalmente vengono utilizzate le opzioni IP. Se il server instrada il traffico per altre macchine, la regola bloccherà anche i loro pacchetti TCP con opzioni IP.

Disattiva MPTCP se non ti serve

sysctl -w net.mptcp.enabled=0
echo "net.mptcp.enabled = 0" > /etc/sysctl.d/99-disable-mptcp.conf

Questa impostazione impedisce soltanto new Impedire la creazione di socket MPTCP. I servizi già in esecuzione continueranno ad ascoltare tramite MPTCP, quindi riavviare ogni servizio elencato da ss -lnMp e assicurati che il suo output sia ora vuoto.

Su AlmaLinux, MPTCP è disabilitato per impostazione predefinita, a meno che non lo si abiliti manualmente.

Disabilitare MPTCP nei programmi Go

Per i servizi creati con Go 1.24 o versioni successive, è possibile disabilitare MPTCP tramite una variabile d'ambiente. Ad esempio, per un servizio chiamato myservice:

systemctl edit myservice

Aggiungi quanto segue al file che si apre:

[Service]
Environment=GODEBUG=multipathtcp=0

Quindi riavviare il servizio:

systemctl restart myservice

Aggiornamento radiografia

Se il tuo server utilizza Xray, aggiornalo alla versione 26.10.31 o successiva. La versione precedente, la 26.10.29, è stata ritirata dagli sviluppatori. Questo aggiornamento disabilita MPTCP ma non corregge il kernel, quindi è comunque necessario un aggiornamento del kernel.

Controlla un'altra impostazione

Una seconda via di sfruttamento, più specifica, richiede che la migrazione delle richieste sia abilitata. È disattivata per impostazione predefinita: assicurati che lo sia.

sysctl net.ipv4.tcp_migrate_req

Il comando dovrebbe stampare 0.

Limita l'accesso ai tuoi servizi

Chiudi tutte le porte del firewall che non devono essere raggiungibili da Internet. Ove possibile, apri i servizi amministrativi (SSH, pannelli di controllo, database) solo agli indirizzi IP attendibili.

Passaggio 4. Dopo aver installato il kernel corretto

1. Riavvia il server e utilizza i comandi del passaggio 1 per verificare che il kernel corretto sia in esecuzione.
2. È possibile rimuovere la regola temporanea:
   

   systemctl disable --now cve-2026-98432.service
   rm /etc/systemd/system/cve-2026-98432.service /etc/cve-2026-98432.nft
   systemctl daemon-reload

   
   
3. Se hai bisogno di MPTCP, ripristina l'impostazione: elimina /etc/sysctl.d/99-disable-mptcp.conf e corri sysctl -w net.mptcp.enabled=1.

Se qualcosa va storto

Se il server non si avvia dopo l'aggiornamento del kernel, connettiti tramite la console VNC nel pannello di controllo e seleziona il kernel precedente nel menu di avvio. Se non sei sicuro di poterlo fare autonomamente o hai bisogno di assistenza per l'aggiornamento, contatta il nostro team di supporto.