CVE-2026-98432: Ubuntu e RHEL non hanno ancora una patch, e un modello Claude ha già scritto l'exploit

I due fatti su CVE-2026-98432 non si conciliano affatto. Si tratta di un use-after-free nell'handshake TCP IPv4 del kernel Linux, raggiungibile via rete senza login e senza interazione, e il team CVE del kernel gli ha assegnato un punteggio di 9,8. Al 30 ottobre 2026, Ubuntu non ha alcuna correzione rilasciata per 22.04, 24.04, 26.04 o 26.10, e Red Hat elenca RHEL 8, 9 e 10 come interessate, senza correzione e senza mitigazione raccomandata. Il secondo fatto è che il 27 ottobre Anthropic ha pubblicato una ricerca secondo cui un modello Claude non ancora rilasciato ha prodotto un proof of concept funzionante per root remoto non autenticato contro un server con un listener MPTCP — circa 48 minuti per estrarre un indirizzo del kernel e altri cinque per arrivare all'esecuzione di comandi.

Una vulnerabilità che i due maggiori fornitori di Linux enterprise non sono ancora in grado di correggere, con un exploit funzionante scritto in parte da una macchina, non è un normale patch Tuesday. È il caso che decide se il vostro processo di aggiornamento del kernel e la vostra policy di accesso degli agenti siano in qualche modo correlati.

Il bug, in un paragrafo

Quando viene stabilita una connessione TCP, le opzioni IP associate al pacchetto in arrivo vengono passate al nuovo socket invece di essere copiate. Se l'handshake viene ritrasmesso, il pacchetto può essere elaborato su una CPU diversa da quella che possiede il buffer delle opzioni — e quella seconda CPU può leggere memoria che la prima ha già liberato. Una race simile esiste nel percorso di migrazione delle richieste. L'intervallo interessato inizia dal kernel 4.4, vale a dire la maggior parte delle macchine che eseguono ancora un kernel mantenuto. La correzione upstream, commit code>e3f33b0a1d89/code>, ritarda la liberazione dei buffer delle opzioni finché nessun altro core può ancora mantenere un riferimento.

La sfruttabilità deriva dalla meccanica: nessuna autenticazione, nessuna interazione da parte dell'utente, un percorso raggiungibile dalla rete e una race condition che può essere ritentata. La sintesi di Anthropic stessa sul perché il PoC sia praticabile è esattamente quella proprietà — una race persa fa fallire un handshake anziché mandare in crash la macchina, così un attaccante riprova.

Tre fornitori, tre numeri di gravità

La ripartizione del punteggio è la parte che vale la pena interiorizzare, perché decide se il tuo scanner aprirà un ticket questa settimana.

• Team CVE del kernel — 9.8, critico. Raggiungibile dalla rete, nessun privilegio richiesto, nessuna interazione.

• Red Hat — 8.1, Importante. La posizione dell'azienda è che la gara è difficile da vincere nella pratica.

• Ubuntu — Priorità alta, senza punteggio numerico pubblicato nelle pagine verificate.

Il divario tra 9,8 e 8,1 non è un disaccordo sul bug; è un disaccordo sulla probabilità di vincere una race. Entrambe le posizioni sono difendibili, e la differenza conta sul piano operativo: un 9,8 con un PoC pubblico è un'emergenza, un 8,1 con una race difficile è una correzione pianificata. Finché qualcuno non pubblica dati di riproduzione su hardware reale, la lettura onesta è che la race sia vincibile, dato che, stando a quanto riportato, un modello di frontiera l'ha vinta.

Chi ha una soluzione, e chi no

Al 29–30 ottobre, il quadro è disomogeneo in un modo che coglie di sorpresa chi presume che un kernel stabile significhi un kernel con le patch applicate.

• Debian 12 bookworm — corretto nella versione 6.1.190-1 tramite DLA-4841-1.

• Debian 13 trixie — corretto in 6.12.113-1 tramite DSA-6568-1.

• Ubuntu 22.04, 24.04, 26.04, 26.10 — nessuna correzione rilasciata; lavoro in corso.

• Ubuntu 16.04, 18.04, 20.04 — vulnerabili, nessuna correzione rilasciata.

• RHEL 8, 9, 10 e OpenShift 4 — interessati, nessuna correzione e nessuna mitigazione approvata da Red Hat.

• RHEL 6 e 7 — non interessati.

• Amazon Linux 2023 — kernel 6.18 segnalato come corretto; Oracle Linux UEK segnalato come corretto; SUSE segnala alcune release corrette e altre ancora in fase di test, senza indicare le versioni.

Le release stabili upstream che contengono la correzione sono 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 e 7.3 — ovvero l'elenco da confrontare con la propria build se si compila il kernel anziché usare un pacchetto della distribuzione.

Perché si continua a parlare di MPTCP

Il bug non è specifico di MPTCP, ed è qui che molti resoconti sbagliano. Red Hat considera qualsiasi servizio TCP raggiungibile come un possibile innesco. Ciò che MPTCP fornisce è un percorso dimostrato, e ciò che fornisce il traffico è Go: la versione 1.24 e successive abilita multipath TCP per impostazione predefinita per i socket in ascolto Linux quando il kernel ha MPTCP attivato. Il team di sicurezza di Go ha messo in guardia riguardo alla combinazione il 29 ottobre.

Quindi «disabilitare MPTCP» elimina il percorso che Anthropic ha dimostrato, non la vulnerabilità. È una misura temporanea difendibile con un'avvertenza specifica: vale la pena adottarla oggi sui servizi Go, e non sostituisce un kernel con le patch applicate.

I controlli sono brevi:

• code>ss -Mltnp/code> — elenca i socket che attualmente utilizzano MPTCP.

• code>net.mptcp.enabled/code> — se la funzionalità del kernel è attiva.

• code>net.ipv4.tcp_migrate_req/code> — disattivato per impostazione predefinita; se lo hai attivato, disattivalo di nuovo.

Per Go in particolare, code>GODEBUG=multipathtcp=0/code> a runtime, oppure una riga code>godebug/code> in code>go.mod/code>, disattivano l'opzione per quel binario.

Nessuna di queste è approvata dal fornitore. Red Hat afferma chiaramente che non dispone di alcuna mitigazione conforme al proprio standard, il che è una frase più utile di un elenco di soluzioni tampone basate sulla speranza.

Cosa ha effettivamente pubblicato Anthropic

La ricerca è circoscritta e specifica. Un modello Claude non ancora rilasciato, fornito del CVE e di un target con un listener MPTCP, ha prodotto una catena che ha fatto trapelare un indirizzo del kernel in circa 48 minuti e ha raggiunto l’esecuzione di comandi circa cinque minuti dopo. Anthropic non ha pubblicato l’exploit e, al 29 ottobre, né i fornitori né il record CVE avevano segnalato attacchi reali; la vulnerabilità non è nel catalogo KEV di CISA. Il 30 ottobre un repository GitHub di terze parti ha pubblicato strumenti di laboratorio per l’innesco di race condition e il memory leak: un harness di riproduzione, che si ferma prima dell’esecuzione completa del codice.

Quella combinazione è la parte interessante. La capacità è dimostrata, l'arma viene taciuta, e il dettaglio che la rende possibile — la proprietà di retry che trasforma una race condition fragile in una affidabile — è pubblico in prosa. Chiunque sia in grado di riprodurre la race condition ora sa perché vale la pena insistere.

Cosa fare questa settimana

• Applica la patch e riavvia dove esiste una correzione. Una correzione del kernel installata ma non resa effettiva con un riavvio non è una correzione; verifica con code>uname -r/code>.

• Dove la tua distribuzione non ha una patch — da Ubuntu 22.04 a 26.10, da RHEL 8 a 10 — decidi ora se accettare una live patch del fornitore, passare a una versione corretta o accettare l'esposizione con MPTCP disattivato sui servizi Go.

• Fai un inventario dell'esposizione MPTCP invece di dare per scontato che sia disattivata. Il valore predefinito è cambiato in Go, non nella tua configurazione, e una modifica a un valore predefinito è invisibile in un diff della configurazione.

• Fai una prova del riavvio. Questo tipo di correzione richiede un riavvio completo, e le organizzazioni che perderanno più tempo sono quelle che scoprono la propria strategia di failover durante la finestra di manutenzione.

Le due domande che questa CVE solleva davvero

Il primo riguarda la generazione di exploit e non è una questione filosofica. Un modello ha trovato una sequenza che moltissimi ricercatori umani non avevano trovato, su un bersaglio con una specifica configurazione abilitante, in meno di un'ora. Che l'exploit venga pubblicato o meno, la tempistica è cambiata: la finestra tra un avviso pubblico e un exploit funzionante ora si misura rispetto a modelli che leggono l'avviso.

Il secondo riguarda cosa significa applicare una patch quando i fornitori non possono farlo. La distribuzione che ti fornisce un kernel e il kernel che contiene la correzione non sono lo stesso oggetto, e il divario tra loro è esattamente il punto in cui questa vulnerabilità risiede per la maggior parte dei lettori di questo post. L'OrcaRouter AI Incident Archive indicizza incidenti come questo rispetto alle loro fonti primarie, alla gravità e all'affidabilità, ed è la versione di questa storia che vale la pena conservare una volta che il ciclo di notizie passa oltre.

La cosa da non fare è archiviarla sotto "aspettare il fornitore". La pagina stessa del fornitore dice che non c'è ancora nulla da aspettare.

Nota sulle fonti: il meccanismo, l'intervallo interessato a partire dal kernel 4.4, il commit upstream code>e3f33b0a1d89/code>, l'elenco delle versioni stabili e le indicazioni sulla mitigazione provengono dal record CVE e dagli avvisi delle distribuzioni consultati il 30 ottobre 2026. Le valutazioni 9.8, 8.1 e Ubuntu High sono rispettivamente del team CVE del kernel, di Red Hat e di Canonical. Lo stato delle patch per distribuzione proviene da DLA-4841-1 e DSA-6568-1 di Debian, dalle pagine CVE di Red Hat e Ubuntu e dalle dichiarazioni dei fornitori alla stessa data. La cronologia del proof-of-concept, i valori di 48 minuti e cinque minuti e la proprietà di retry provengono dalla ricerca di Anthropic del 27 ottobre, che ha tenuto riservato l'exploit. Il repository di laboratorio del 30 ottobre è descritto come di terze parti e non è il nostro.