Gestisco server Debian in produzione da anni. Ogni volta che esce una CVE sul kernel mi fermo a leggere i dettagli. Poi decido se aggiornare subito o aspettare. Questa volta la storia è più intricata del solito: c’è una vulnerabilità kernel Linux nel TCP IPv4, un punteggio CVSS conteso tra vendor, e persino un presunto exploit root costruito da un’intelligenza artificiale. Partiamo da una domanda che sembra laterale, ma non lo è: cos’è MPTCP, e perché conta anche se non lo usi.
Cos’è MPTCP e perché riguarda anche chi non lo usa
Multipath TCP (MPTCP) è lo standard RFC 8684. Estende il TCP classico per far viaggiare una singola connessione su più percorsi di rete insieme. Un telefono può usare WiFi e rete cellulare nello stesso momento, per la stessa connessione. Un server con più interfacce può fare lo stesso, per ridondanza o per somma di banda. Apple lo usa in produzione fin da iOS 7, nel 2013, per Siri: è il caso d’uso reale più noto. Alcuni operatori mobili, per esempio in Corea del Sud, lo sfruttano per il bonding WiFi/LTE. Diversi data center lo adottano per il multi-homing tra uplink diversi. Nel kernel Linux mainline c’è dal 5.6.
Il punto che mi ha fatto alzare un sopracciglio è un altro. Dalla versione 1.24, i programmi scritti in Go richiedono MPTCP di default per i socket in ascolto. Il Go Security Team l’ha confermato il 29 ottobre. Insieme, ha dato un avviso scomodo: il bug di cui parliamo oggi non è specifico di MPTCP. Un sistema senza listener MPTCP attivi può restare comunque esposto ad attacchi simili. Il codice vulnerabile è nel path TCP IPv4 generico, non in un modulo opzionale. Si può disattivare MPTCP programma per programma, con la variabile GODEBUG=multipathtcp=0 a runtime. Ma il Go Security Team definisce questa mitigazione “fragile”: basta un solo listener MPTCP rimasto esposto per vanificarla. Nessuno ha dimostrato che ogni exploit funzionante dipenda davvero da MPTCP. Ecco perché il codice MPTCP resta superficie di attacco, anche se nel tuo stack non lo attivi mai consapevolmente: basta che sia compilato nel kernel e raggiungibile.
Il progetto MPTCP stesso dichiara, sulla propria pagina, che le principali distribuzioni Linux correnti spediscono il kernel con il supporto MPTCP compilato di default (CONFIG_MPTCP=y). Nomina esplicitamente Debian, Ubuntu, RHEL e Fedora. È una dichiarazione del progetto stesso, non una verifica indipendente distro per distro, ma il concetto resta valido: il supporto è acceso a livello di kernel, non “opt-in” a livello di sistema operativo. Solo la negoziazione per singola connessione resta a carico dell’applicazione.
La vulnerabilità kernel Linux CVE-2026-98432 in breve
Il CVE team del kernel Linux ha pubblicato la CVE-2026-98432 il 15 ottobre 2026. Il fix upstream era già stato applicato dieci giorni prima, il 5 ottobre. Capita spesso che la pubblicazione segua il commit con un certo ritardo. Il punteggio CVSS di 9,8 (critico) è arrivato solo il 24 ottobre, nove giorni dopo la pubblicazione della CVE.
Il problema sta nella gestione dell’handshake TCP per IPv4, in particolare nella funzione tcp_v4_syn_recv_sock(). Quando una connessione viene creata, le opzioni IP del pacchetto SYN vengono passate dal request socket in attesa al nuovo socket. Per esempio Record Route o Timestamp, se il client le include in un SYN costruito ad arte. Il problema è che vengono passate per riferimento, non per copia, e senza il lock del listener. Secondo l’analisi tecnica della patch, le strutture coinvolte si chiamano inet_opt e ireq_opt. Una seconda CPU può liberare quel buffer con kfree(), chiamato da inet_sock_destruct() o da tcp_v4_reqsk_destructor(). Nel frattempo una prima CPU lo sta ancora leggendo in ip_options_build(), per costruire il SYNACK. È un classico use-after-free causato da una race condition. Il percorso IPv6 equivalente, tcp_v6_syn_recv_sock(), copia le opzioni invece di passarle per riferimento: non è vulnerabile alla race principale. Esiste anche una seconda via d’attacco, tramite la migrazione dei request-socket: net.ipv4.tcp_migrate_req=1 oppure un programma eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Entrambe sono disattivate di default.
Il bug è remoto e non richiede autenticazione né interazione dell’utente, secondo la valutazione del kernel team. È presente dalla versione 4.4 del kernel. Il fix è firmato da Eric Dumazet, segnalato da Xinyang Ge di Anthropic. Sposta la liberazione della memoria a dopo un grace period RCU, con kfree_rcu(): così nessuna CPU può più leggere un buffer già liberato. Le versioni stabili corrette sono 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e la mainline dalla 7.3-rc7.
Punteggi CVSS discordanti: non tutti i vendor sono d’accordo
Qui la storia si complica. Il kernel CVE team e Ubuntu valutano la complessità di attacco come bassa, e danno 9,8 (critico). Oracle e SUSE danno invece 8,1 (importante): stesso vettore CVSS, ma complessità di attacco alta. Red Hat, curiosamente, ha due valutazioni che non coincidono tra loro. La pagina CVE pubblica mostra “Moderate, 5.9”. Il file di advisory leggibile da macchina, aggiornato il 29 ottobre, mostra invece “Important, 8.1”, con impatto alto su confidenzialità e integrità. Lo stesso giorno il bug tracker interno di Red Hat ha alzato la severità da medium a high. Amazon, dal suo lato, assegna 7,0. Al momento in cui scrivo, l’NVD non ha ancora pubblicato un punteggio proprio.
Vale la pena dirlo con onestà. Questa incongruenza interna a Red Hat non è un dettaglio che ho dedotto io: è riportata così dall’articolo originale di The Hacker News, la mia fonte principale per questi dati. Non è la prima volta che un vendor pubblica due numeri diversi per lo stesso bug, su canali diversi. Ma qui il salto da “moderato” a “importante” nello stesso giorno dice molto. Anche per chi scrive il codice, stimare con certezza lo sfruttabilità reale di una race condition nel kernel è difficile.
Stato delle patch: Debian già corretto, altri ancora no
Questo è il punto che mi riguarda più da vicino: gli hosting che gestisco girano su Debian stable. E qui i fatti parlano chiaro, senza bisogno di aggiungere enfasi: Debian ha già corretto questa vulnerabilità kernel Linux, sia su trixie che su bookworm. Debian trixie (stable) è stata corretta il 16 ottobre 2026, con il pacchetto linux 6.12.113-1, avviso DSA-6568-1. Debian 12 (bookworm) è stata corretta in due passaggi: il 17 e il 22 ottobre 2026, con linux 6.1.190-1 (avviso DLA-4841-1) e linux-6.12 6.12.113-1~deb12u1 (avviso DLA-4850-1). Nella propria tabella di tracciamento, Debian non elenca un punteggio CVSS separato per questa CVE. Si limita a segnare lo stato di fix per ogni release: è l’informazione che conta davvero, per chi deve decidere se riavviare un server.
Confrontare questo con lo stato di altre distribuzioni molto diffuse aiuta a dare peso alla cosa. Al 30 ottobre, Red Hat ha aggiornato lo stato di RHEL 8, 9, 10 e OpenShift 4. Prima era “fix deferred” (segnato il 29 ottobre), ora è “affected”. Nessuna data di rilascio è stata comunicata. Ubuntu, su tutte le versioni supportate (22.04, 24.04, 26.04, 26.10), risulta ancora “in lavorazione”, senza una data. Ubuntu 16.04, 18.04 e 20.04 risultano vulnerabili, senza nemmeno un fix elencato. SUSE Linux Enterprise Server, dalla SP4 alla SP7 più la 16.0, è nella stessa situazione. Oracle Linux (UEK), openSUSE Leap 16.0, SUSE Linux Micro 6.2 e Amazon Linux 2023 risultano invece già corretti. RHEL 7 non è affetto: il percorso di codice vulnerabile non è mai stato distribuito su quella release.
Non lo dico per fare concorrenza a Ubuntu o RHEL. Restano distribuzioni serie, con processi di sicurezza robusti. Lo dico perché su questo singolo bug, in questa finestra temporale, i fatti sono questi: chi si affida a hosting basati su Debian stable ha già il fix installato. Su altre distribuzioni molto usate, invece, il server resta esposto per un periodo indefinito. È un vantaggio concreto, verificabile guardando le date. Non è un’opinione sul progetto Debian in generale.
L’exploit (riportato, non verificato in modo indipendente) di Anthropic
La parte più insolita di questa storia riguarda Anthropic, l’azienda che per prima ha segnalato il bug tramite Xinyang Ge. Secondo i report di settore, uno dei suoi modelli AI interni, non rilasciato pubblicamente, ha costruito da solo un exploit root funzionante. Partendo solo dalla patch e dal report come prompt. L’attacco in due fasi funzionerebbe così. Nella prima fase, la race fa inviare all’attaccante byte extra dalla risposta del kernel. Da lì recupera un indirizzo kernel, per disinnescare KASLR. Nella seconda fase, lo stesso bug causerebbe un overflow di buffer. Sovrascrive un puntatore di callback con l’indirizzo di un payload già piazzato in memoria kernel dall’attaccante. Quando il kernel chiama quel puntatore, il payload esegue un comando shell a scelta come root. Una race persa farebbe fallire solo quel singolo tentativo di connessione, senza crashare il sistema: quindi sarebbero possibili tentativi ripetuti. Nel test descritto da Anthropic: 48 minuti per rubare l’indirizzo kernel, altri 5 minuti per arrivare all’esecuzione di comandi.
Red Hat dice che un attaccante remoto che raggiunge un servizio TCP esposto può in generale innescare la race. L’exploit root descritto da Anthropic, però, avrebbe preso di mira specificamente server con un listener multipath TCP attivo. Il post di Anthropic non chiarisce se un server senza MPTCP sia sfruttabile allo stesso modo. Né il record CVE né il fix upstream menzionano MPTCP in nessun punto. È la stampa di settore, non una fonte primaria, a riportare questo legame: lo scrivo quindi con lo scetticismo che merita, non come un fatto accertato al cento per cento. Anthropic non ha pubblicato il codice dell’exploit, né la versione esatta del kernel usata, né la configurazione del server target. Un’altra società, Innora, ha pubblicato un’analisi della causa radice, con un ambiente di riproduzione QEMU. Ha dichiarato che non rilascerà un exploit armato nel breve termine. Al momento non ci sono prove di sfruttamento reale da parte di vendor o CERT. Il bug non è nel catalogo CISA KEV, secondo la copia aggiornata da CIRCL del Lussemburgo al 28 ottobre.
Cosa fare adesso sui tuoi server
Nessun vendor ha pubblicato un workaround ufficialmente sanzionato per questa vulnerabilità kernel Linux. Red Hat dice esplicitamente che nessuna delle misure circolate finora raggiunge il suo standard di facilità di deploy e di stabilità. La mitigazione primaria resta applicare il kernel corretto e riavviare, quando la patch è disponibile per la tua distribuzione. Su Debian lo è già. Su RHEL e Ubuntu ancora no, al momento in cui scrivo.
Come difesa in profondità, non come soluzione definitiva, ha senso fare alcune cose. Verificare che net.ipv4.tcp_migrate_req sia impostato a 0. Controllare che non ci siano programmi eBPF BPF_SK_REUSEPORT_SELECT_OR_MIGRATE caricati. Valutare un filtraggio dei pacchetti IPv4 in ingresso con opzioni Record Route o Timestamp. Monitorare eventuali crash che citano ip_options_build, ip_build_and_send_pkt o skb_under_panic. Fare l’inventario di eventuali listener MPTCP esposti, evitando di lasciarli raggiungibili senza motivo. Se gestisci anche servizi contro attacchi applicativi più comuni, su come ho protetto i server in attesa della patch per PHP2Shell trovi lo stesso approccio: mitigare quello che si può, mentre si aspetta il fix definitivo, senza promettere protezioni che non esistono.
Per chi mi chiede se aggiornare subito: se usi Debian stable, il kernel corretto è già nei repository di sicurezza. L’aggiornamento è semplice, e la finestra di esposizione è già chiusa. Se usi altre distribuzioni, oggi non c’è ancora una patch da installare. Vale la pena seguire da vicino gli avvisi del tuo vendor nei prossimi giorni: la situazione cambia rapidamente.
Fonti: The Hacker News, Debian Security Tracker e il commit del fix. Debian, Red Hat, Ubuntu e gli altri nomi citati sono marchi dei rispettivi proprietari.
Lascia un commento