Segui Una vulnerabilità critica nello stack di rete TCP IPv4 del kernel Linux potrebbe permettere a un attaccante remoto non autenticato di innescare la corruzione della memoria, causare il crash dei sistemi vulnerabili e potenzialmente eseguire codice arbitrario con privilegi di root. Tracciata come CVE-2026-98432, la falla ha un punteggio CVSS 3.1 di 9.8 ed è presente nel kernel Linux dalla versione 4.4.
La vulnerabilità deriva da una condizione di race che può causare l’accesso del kernel ai dati delle opzioni IP dopo che la memoria sottostante è già stata liberata. Un attaccante in grado di raggiungere un servizio TCP IPv4 esposto può tentare di innescare la condizione utilizzando richieste di connessione temporizzate specialmente contenenti opzioni IPv4. Non sono richieste autenticazione, privilegi locali o interazione dell’utente.
L’interesse per la sicurezza è aumentato significativamente dopo che Anthropic ha rivelato che un modello di ricerca interno di Claude aveva sviluppato un exploit funzionante in grado di ottenere l’esecuzione remota di comandi con privilegi di root su un server Linux con un listener Multipath TCP (MPTCP). L’exploit innanzitutto cerca un puntatore del kernel per bypassare KASLR e poi utilizza la stessa condizione use-after-free per corrompere la memoria e reindirizzare il flusso di controllo del kernel. Anthropic non ha rilasciato il codice dell’exploit.
È importante notare che la vulnerabilità sottostante non è limitata a MPTCP. Red Hat conferma che i sistemi con il normale networking TCP IPv4 rimangono vulnerabili anche quando MPTCP è disabilitato, incluse le configurazioni predefinite di Red Hat Enterprise Linux.
Al 4 novembre 2026, nessun vendor Linux, CERT o altra fonte recensita ha riportato conferme di sfruttamento della falla in attacchi reali. Esiste codice di ricerca pubblico che dimostra parti della vulnerabilità, ma un exploit pubblicamente rilasciato che offre la piena capacità di root remoto dimostrata da Anthropic non è stato documentato.
I team di sicurezza possono utilizzare la piattaforma AI-Native Detection Intelligence di SOC Prime per rafforzare le proprie difese contro lo sfruttamento di vulnerabilità emergenti, operazionalizzare l’intelligence sulle minacce e accelerare la ricerca di minacce in ambienti SIEM, EDR, XDR e Data Lake.
Rileva CVE-2026-98432 monitorando traffico TCP IPv4 insolito contenente opzioni IP, tentativi di connessione ripetuti progettati per innescare condizioni di race, crash del kernel o eventi di corruzione della memoria e attività sospette che potrebbero indicare un’esplosione riuscita post-sfruttamento.
I contenuti di rilevamento potrebbero non essere disponibili per ogni CVE. Controlla la piattaforma SOC Prime per copertura attuale. Se le rilevazioni pertinenti non sono ancora disponibili, controlla di nuovo poiché contenuti di rilevamento e intelligence sulle minacce vengono costantemente aggiunti.
Analisi CVE-2026-98432
CVE-2026-98432 interessa il codice di gestione delle connessioni TCP IPv4 nei kernel Linux contenente l’implementazione vulnerabile introdotta in Linux 4.4. Il team CVE del kernel Linux classifica il problema come critico con un punteggio CVSS 3.1 di 9.8 e il vettore AV/AC/PR/UI/S/C/I/A.
La vulnerabilità è una condizione use-after-free causata da un race durante l’elaborazione simultanea delle connessioni TCP. Quando si stabilisce una connessione TCP IPv4, tcp_v4_syn_recv_sock() trasferisce le opzioni IP associate alla richiesta in sospeso al socket appena creato senza fare una copia separata.
Un altro CPU può elaborare simultaneamente un SYN ritrasmesso associato allo stesso socket di richiesta. Durante quel processo, le funzioni responsabili della generazione del SYN-ACK continuano a leggere le opzioni IP mentre sono protette da una sezione critica di lettura RCU.
Tuttavia, il socket figlio può essere distrutto mentre quell’operazione è ancora in corso. Il kernel poi libera la struttura inet_opt associata usando kfree(), lasciando un altro CPU potenzialmente a accedere a una memoria che è già stata rilasciata. Il riferimento stantio risultante crea una condizione use-after-free in ip_options_build().
Esiste un race simile durante la migrazione dei socket di richiesta, incluse le configurazioni che utilizzano net.ipv4.tcp_migrate_req=1 o SK_REUSEPORT_SELECT_OR_MIGRATE basato su BPF. La correzione upstream sostituisce il rilascio della memoria non sicuro con un rilascio consapevole RCU, garantendo che i lettori abbiano completato l’accesso all’oggetto prima di poterne reclamare la memoria.
La prima questione riguarda specificamente IPv4. L’avviso del kernel afferma che IPv6 non è vulnerabile a quella particolare race poiché tcp_v6_syn_recv_sock() duplica le opzioni rilevanti invece di trasferirle nello stesso modo.
Lo sfruttamento remoto richiede traffico di rete costruito specialmente e una manipolazione precisa della condizione di race. Red Hat nota che i probabili esiti possono includere un crash del kernel, la corruzione della memoria e potenzialmente l’esecuzione remota di codice. La mancanza di autenticazione e interazione dell’utente aumenta sostanzialmente il rischio per i sistemi che espongono servizi TCP a reti non fidate.
Anthropic ha dimostrato che la vulnerabilità può essere trasformata in un exploit remoto completo di root. Il suo modello di ricerca ha mirato a un server Linux che accettava connessioni Multipath TCP e ha usato due fasi per ottenere l’esecuzione di comandi.
Durante la prima fase, l’exploit innesca ripetutamente la race e manipola un valore di lunghezza in modo che il kernel restituisca memoria aggiuntiva adiacente in una risposta di rete. Alla fine, una di queste risposte contiene un puntatore del kernel. Tale divulgazione rivela informazioni sul layout della memoria del kernel e permette all’exploit di superare la Randomizzazione del Layout dello Spazio degli Indirizzi del Kernel (KASLR).
Durante la seconda fase, l’exploit utilizza la stessa vulnerabilità per causare un overflow di buffer e sovrascrivere un puntatore di callback. Il puntatore viene reindirizzato verso un payload precedentemente posizionato nella memoria del kernel utilizzando la funzionalità legittima del protocollo. Quando il kernel invoca il callback modificato, le funzioni esistenti del kernel vengono concatenate fino a quando un comando shell selezionato dall’attaccante viene eseguito come root.
Una caratteristica particolarmente importante dell’exploit è che perdere la corsa non causa necessariamente il crash del server. Invece, il tentativo di connessione può semplicemente fallire, permettendo all’attaccante di ritentare ripetutamente. Nell’ambiente di test di Anthropic, ottenere un puntatore del kernel utile ha richiesto circa 48 minuti, seguiti da altri cinque minuti per ottenere l’esecuzione di comandi come root.
Questa dimostrazione non dovrebbe essere interpretata nel senso che MPTCP è necessario per lo sfruttamento. Anthropic ha dimostrato un percorso di exploit riuscito che coinvolge un listener MPTCP, ma il codice vulnerabile risiede nella gestione ordinaria delle TCP IPv4. Red Hat avverte esplicitamente che disabilitare MPTCP non affronta completamente la vulnerabilità e che le installazioni RHEL predefinite rimangono affette anche se MPTCP è disabilitato per impostazione predefinita.
La situazione PoC del CVE-2026-98432 è anche importante da distinguere dall’esistenza di un exploit completamente armato. Anthropic ha sviluppato un proof of concept remota funzionante di root internamente ma non lo ha pubblicato. Il codice pubblico riportato dai ricercatori di sicurezza può dimostrare o rilevare aspetti della race sottostante e della divulgazione della memoria, ma le fonti riviste non documentano codice rilasciato al pubblico che riproduce la catena completa di esecuzione di codice remoto di Anthropic.
La vulnerabilità è stata segnalata dal ricercatore di Anthropic Xinyang Ge. La correzione upstream di Linux è stata applicata il 5 ottobre 2026, mentre il record CVE del kernel Linux è stato pubblicato il 15 ottobre. Anthropic ha descritto pubblicamente la sua ricerca completa di sfruttamento il 27 ottobre.
Il progetto del kernel Linux identifica le seguenti versioni fisse upstream:
- Linux 5.10.272
- Linux 5.15.223
- Linux 6.1.190
- Linux 6.6.159
- Linux 6.12.113
- Linux 6.18.56
- Linux 7.2.10
- Linux 7.3
Il team del kernel raccomanda di aggiornare all’ultimo kernel stabile piuttosto che scegliere singoli commit.
L’esposizione e la remediation specifica della distribuzione differiscono perché i fornitori di Linux mantengono i propri kernel e backportano le correzioni di sicurezza. Red Hat attualmente valuta il problema Critico a 9.8 e ha rilasciato correzioni per più stream RHEL 8, 9 e 10. OpenShift e prodotti a strati che dipendono dai kernel RHEL affetti richiedono anche attenzione.
Anche Ubuntu valuta la vulnerabilità Critica a 9.8. Ubuntu 26.10 ha ricevuto un kernel generico corretto, mentre correzioni per Ubuntu 22.04 LTS, 24.04 LTS e 26.04 LTS erano disponibili nel pocket di testing -proposed all’inizio di novembre, con ulteriori rilascio supportati in attesa delle correzioni. Gli amministratori dovrebbero utilizzare la pagina CVE di Canonical piuttosto che affidarsi esclusivamente ai numeri di versione del kernel upstream.
Per la rilevazione di CVE-2026-98432, i team di sicurezza dovrebbero combinare la telemetria di rete e host. Segnali di caccia potenziali a livello di rete includono pacchetti TCP IPv4 in ingresso insoliti che trasportano opzioni IP, specialmente tentativi di connessione ripetuti contenenti opzioni Record Route o Timestamp e modelli anomali di ritrasmissione SYN. La presenza di tale traffico da sola non conferma lo sfruttamento, ma fornisce un utile pivot di caccia quando correlata a sistemi vulnerabili.
Il monitoraggio a livello host dovrebbe includere crash del kernel Linux, avvisi del kernel, indicatori di corruzione della memoria, riavvi inaspettati dei servizi e attività anomale immediatamente successivi a traffico di rete sospetto. Poiché uno sfruttamento riuscito potrebbe teoricamente offrire l’esecuzione di codice root, i difensori dovrebbero anche monitorare processi privilegiati inaspettati, nuovi file creati, cambiamenti di configurazione, meccanismi di persistenza e connessioni in uscita non spiegate.
Al momento non sono disponibili IOC specifici per attaccanti relativi a CVE-2026-98432 come indirizzi IP, domini o hash di malware confermati, perché le fonti recensite non hanno riportato sfruttamento nel mondo reale. I difensori dovrebbero quindi dare priorità alla rilevazione basata sul comportamento e alla valutazione dell’esposizione piuttosto che affidarsi a indicatori statici.
Mitigazione CVE-2026-98432
La remediation definitiva è installare un kernel fornito dal fornitore contenente la correzione di sicurezza. Il team CVE del kernel Linux raccomanda di passare al kernel stabile più recente supportato, mentre gli utenti delle distribuzioni Linux dovrebbero installare i pacchetti forniti specificamente dal proprio fornitore perché le correzioni sono comunemente backportate senza cambiare alla versione del kernel upstream.
Gli amministratori dovrebbero dare priorità ai server Linux esposti a Internet e ad altri sistemi che accettano connessioni TCP IPv4 in ingresso. La superficie di attacco è ampia perché la vulnerabilità esiste nello stack di rete del kernel piuttosto che in un’applicazione o prodotto server individuale.
Le organizzazioni dovrebbero intraprendere i seguenti passaggi:
- Inventario dei server Linux e identificare il kernel in esecuzione con strumenti come uname -r.
- Controlla l’avviso di sicurezza della distribuzione Linux rilevante piuttosto che determinare l’esposizione esclusivamente dal numero di versione upstream.
- Installa il kernel corretto fornito dal fornitore non appena è disponibile.
- Riavvia i sistemi interessati dopo aver installato il kernel aggiornato per assicurarti che il kernel patchato sia in esecuzione.
- Dai priorità ai server e all’infrastruttura esposti a Internet che accettano traffico TCP IPv4 in ingresso.
- Rivedi i servizi TCP esposti esternamente e limita l’accessibilità di rete non necessaria.
- Continua a monitorare gli avvisi dei fornitori perché la disponibilità delle correzioni differisce tra le distribuzioni Linux, varianti del kernel, kernel cloud e canali di supporto.
Red Hat e Ubuntu hanno anche documentato un approccio di filtro pacchetto intermedio che scarta i pacchetti TCP IPv4 in ingresso contenenti opzioni IP. La condizione nftables consigliata controlla una lunghezza maggiore di cinque dell’header IPv4 e scarta i pacchetti TCP corrispondenti prima che raggiungano il percorso di gestione dei socket vulnerabili.
Questa misura può ridurre l’esposizione perché il percorso di sfruttamento noto richiede opzioni IPv4. Tuttavia, entrambi i fornitori avvertono che il filtro pacchetto non è un sostituto completo per l’installazione del kernel corretto. Può anche interferire con i carichi di lavoro che dipendono legittimamente da opzioni IPv4 e quindi dovrebbe essere testato prima dell’implementazione in produzione.
Disabilitare MPTCP da solo non dovrebbe essere considerato una protezione sufficiente. Sebbene l’exploit funzionante di Anthropic abbia preso di mira un listener MPTCP, la vulnerabilità sottostante risiede nella gestione normale delle TCP IPv4. Red Hat nota specificamente che RHEL rimane vulnerabile nella sua configurazione predefinita anche se MPTCP è disabilitato.
Per gli ambienti che utilizzano applicazioni Go, disabilitare il comportamento automatico di MPTCP può ridurre l’esposizione allo specifico exploit dimostrato da Anthropic, ma questo rimane una misura di riduzione del rischio incompleta. I sistemi senza un listener MPTCP non dovrebbero essere considerati automaticamente sicuri perché altre tecniche di sfruttamento possono prendere di mira la stessa race sottostante.
Poiché non è stata confermata alcuna campagna di compromissione nel mondo reale, l’autoguida alla risposta agli incidenti dovrebbe attualmente concentrarsi sull’identificazione dei sistemi potenzialmente vulnerabili e del comportamento di sfruttamento sospetto piuttosto che sulla ricerca di un set di infrastrutture di attaccanti noto. Le organizzazioni che osservano traffico TCP insolito seguito da instabilità del kernel o esecuzione privilegiata inaspettata dovrebbero trattare l’attività come potenzialmente dannosa e preservare la telemetria di rete e host per l’indagine.
FAQ
Che cos’è CVE-2026-98432 e come funziona?
CVE-2026-98432 è una vulnerabilità critica use-after-free nel sottosistema di rete TCP IPv4 del kernel Linux. Durante l’elaborazione concorrente delle richieste di connessione TCP, la memoria dell’opzione IP può essere liberata mentre un altro CPU la sta ancora accedendo. Richieste di rete remota temporizzate specialmente possono innescare la race, potenzialmente causando crash, corruzione della memoria, divulgazione di informazioni o esecuzione remota di codice.
Quando è stata scoperta per la prima volta CVE-2026-98432?
La vulnerabilità è stata segnalata dal ricercatore di Anthropic Xinyang Ge. La correzione upstream di Linux è stata introdotta il 5 ottobre 2026 e il record CVE del kernel Linux è stato pubblicato il 15 ottobre. Anthropic ha divulgato pubblicamente la sua ricerca e tecnica di sfruttamento remota funzionante il 27 ottobre 2026.
Qual è l’impatto di CVE-2026-98432 sui sistemi?
Un attaccante remoto non autenticato può innescare una condizione use-after-free nel kernel Linux tramite traffico TCP IPv4. Le conseguenze possibili includono negazione di servizio tramite un crash del kernel, divulgazione o corruzione della memoria del kernel e potenzialmente esecuzione arbitraria di comandi con privilegi di root. Anthropic ha dimostrato un’esecuzione remota del comando root riuscita contro un sistema con un listener MPTCP.
CVE-2026-98432 può ancora influenzarmi nel 2026?
Sì. I sistemi che eseguono kernel Linux vulnerabili rimangono esposti fino a quando l’aggiornamento di sicurezza appropriato dal fornitore non è installato e il kernel patchato è in esecuzione. Il bug sottostante esiste da Linux 4.4 e le distribuzioni colpite includono le principali piattaforme Linux aziendali. Tuttavia, al 4 novembre 2026, le fonti recensite non riportano sfruttamenti confermati della vulnerabilità in attacchi nel mondo reale.
Come posso proteggermi da CVE-2026-98432?
Installa l’ultimo kernel corretto fornito dalla tua distribuzione Linux e riavvia il sistema per attivarlo. Dai priorità ai server che accettano connessioni TCP IPv4 in ingresso e verifica l’esposizione utilizzando l’avviso del fornitore. Dove la patching immediata non è possibile, filtrare i pacchetti TCP IPv4 in ingresso contenenti opzioni IP può ridurre il rischio, ma non è un sostituto completo per l’aggiornamento. I team di sicurezza dovrebbero continuare a rivedere gli avvisi dei fornitori per dettagli aggiornati per CVE-2026-98432 man mano che ulteriori correzioni e ricerche diventano disponibili.
