- Cosa: l’ACN segnala la disponibilità di un Proof of Concept (PoC) per la CVE-2026-98432, vulnerabilità del kernel Linux con punteggio CVSS 3.1 pari a 9.8, già sanata dal vendor.
- Il rischio: un attaccante remoto non autenticato, inviando richieste TCP appositamente predisposte, può rendere instabile o arrestare il sistema e, nei casi più gravi, eseguire codice arbitrario con i privilegi del kernel.
- Cosa fare: aggiornare il kernel alle versioni corrette dai repository ufficiali della propria distribuzione, verificando che includano la correzione, partendo dai sistemi esposti a Internet.
L’Agenzia per la Cybersicurezza Nazionale ha segnalato oggi la disponibilità di un codice dimostrativo per sfruttare la CVE-2026-98432, una falla nel sottosistema di rete IPv4 del kernel Linux. La correzione esiste già, ma la pubblicazione di un PoC rende lo sfruttamento alla portata di un numero molto più ampio di attaccanti. Chi non ha ancora aggiornato server, macchine virtuali e apparati basati su Linux dovrebbe considerarlo un intervento da pianificare nelle prossime ore, non nelle prossime settimane.
Cosa è successo
Secondo l’avviso dell’ACN, la CVE-2026-98432 è una vulnerabilità di tipo Use-After-Free con score CVSS 3.1 pari a 9.8. Riguarda il modo in cui il kernel gestisce le strutture dati che contengono le opzioni IPv4 associate alle richieste di connessione durante l’handshake TCP. A causa di una race condition, in determinate condizioni il kernel può accedere a queste strutture dopo che sono state deallocate, in particolare durante la generazione del pacchetto SYN-ACK, cioè la risposta che un server invia quando riceve una richiesta di apertura di connessione.
Per sfruttare la falla, spiega l’Agenzia, a un attaccante remoto non autenticato basta inviare richieste TCP appositamente predisposte al sistema vulnerabile. L’effetto può essere l’instabilità o l’arresto del sistema e, nei casi più gravi, l’esecuzione di codice arbitrario con i privilegi del kernel, il livello più alto possibile su una macchina. L’ACN raccomanda, ove non già fatto, di aggiornare il kernel Linux alle versioni corrette rese disponibili tramite i repository ufficiali della distribuzione in uso, verificando che sia inclusa la correzione per questa CVE.
Il contesto: gli exploit generati da agenti AI
La segnalazione arriva il giorno dopo un rapporto che riguarda proprio il kernel Linux. Come riporta ICT Security Magazine, il 4 novembre 2026 OpenAI ha pubblicato il documento «A thousand fewer paths to root», in cui dichiara di aver ottenuto 948 exploit Linux funzionanti, ciascuno in grado di dare i privilegi di root a un utente locale senza privilegi. Li ha prodotti una catena di agenti AI guidata da un modello per la cybersicurezza non ancora rilasciato, in una prova condotta a metà ottobre sul ramo principale del kernel.
Secondo il rapporto, il costo complessivo è stato di 1.213.430 dollari, pari a 1.279 dollari per exploit. Il dettaglio cita 1.169 exploit per l’escalation dei privilegi: il numero di 948 deriva dall’analisi delle varianti, che li ha ricondotti a correzioni distinte. OpenAI osserva che la difficoltà non era scoprire le vulnerabilità, ma stabilire quali fossero riproducibili e quali meritassero per prime l’attenzione dei manutentori. Gli agenti hanno anche scritto una patch per ogni vulnerabilità, poi rivista da ricercatori umani prima della segnalazione.
Una precisazione è necessaria: gli exploit del rapporto OpenAI riguardano l’escalation dei privilegi in locale, mentre la CVE-2026-98432 è sfruttabile da remoto. Le fonti non collegano i due casi.
Perché riguarda anche te
Il kernel Linux è ovunque. OpenAI, citata da ICT Security Magazine, ricorda che alimenta Android, l’infrastruttura cloud e i supercomputer. Nella lettura Nexim, per un’azienda o una PA italiana questo significa server web e applicativi, macchine virtuali in cloud, host che eseguono container, ma anche firewall, load balancer, concentratori VPN, NAS e molte appliance che al loro interno usano Linux senza mostrarlo all’utente.
Il punto critico è il vettore: la falla si trova nella gestione dell’handshake TCP, cioè nella fase che precede qualsiasi autenticazione. In linea di principio, quindi, un sistema con un servizio TCP raggiungibile può essere bersaglio anche se protetto da password robuste. Non tutti i sistemi Linux sono necessariamente vulnerabili: dipende dalla versione del kernel e dalla presenza della correzione, e va verificato caso per caso.
Il rapporto OpenAI aggiunge un elemento di scenario. Nella lettura Nexim, se un attaccante ottiene un primo accesso a una macchina, la disponibilità di exploit locali a basso costo rende più probabile che quell’accesso si trasformi in pieno controllo. E se la generazione automatica di exploit diventa economica, il tempo tra la pubblicazione di una falla e i primi attacchi tende ad accorciarsi: è una tendenza da considerare nella pianificazione, non un dato dimostrato dalle fonti.
Per le famiglie l’impatto è più indiretto ma reale: router domestici, NAS e dispositivi smart sono spesso basati su Linux e si aggiornano solo tramite il firmware del produttore.
Come proteggersi / Cosa fare
Le azioni che seguono partono dalla raccomandazione dell’ACN e integrano buone pratiche di settore riconosciute.
- Fare l’inventario. Elencare tutti i sistemi con kernel Linux: server fisici, VM, host di container, appliance di rete e sicurezza, NAS. Per ciascuno annotare distribuzione e versione del kernel in esecuzione (su un sistema standard il comando uname -r la mostra).
- Verificare la correzione. Consultare i bollettini di sicurezza della propria distribuzione e controllare quale pacchetto del kernel include la correzione per la CVE-2026-98432, come indica l’ACN.
- Stabilire le priorità. Partire dai sistemi esposti a Internet con servizi TCP in ascolto (siti web, VPN, posta, accesso remoto), poi passare a quelli interni più critici.
- Aggiornare e riavviare. Installare il kernel corretto dai repository ufficiali. Per buona pratica, ricordare che un nuovo kernel entra in funzione solo dopo il riavvio, salvo meccanismi di live patching supportati, e controllare dopo il riavvio che sia attiva la versione aggiornata.
- Contattare i produttori di appliance. Gli apparati chiusi non si aggiornano dai repository: chiedere al vendor un bollettino specifico e il firmware correttivo, e annotare le risposte nell’inventario.
- Ridurre l’esposizione dove la patch tarda. Limitare l’accesso ai servizi TCP ai soli indirizzi necessari, chiudere le porte non indispensabili e segmentare la rete per contenere eventuali compromissioni. Sono misure temporanee, non un sostituto dell’aggiornamento.
- Monitorare i segnali anomali. Riavvii inattesi, kernel panic e crash ripetuti dei sistemi esposti vanno trattati come possibili indizi di tentativi di sfruttamento e approfonditi.
- Rivedere il processo di patching. Definire tempi massimi di aggiornamento per le vulnerabilità critiche con exploit pubblico e mantenere l’inventario costantemente aggiornato: è la base per reagire in ore anziché in giorni.
Il punto di vista Nexim
Da operatore di rete, leggiamo in questa vulnerabilità un promemoria su quanto il perimetro conti anche quando il difetto è nel sistema operativo: un attacco che passa dall’handshake TCP arriva prima di qualsiasi controllo applicativo. La patch resta l’unica correzione definitiva, ma filtrare il traffico anomalo a monte, limitare i servizi esposti e avere visibilità sui flussi aiuta a guadagnare tempo e a ridurre il rumore mentre si aggiornano i sistemi. Per chi vuole valutare come affiancare questi controlli all’aggiornamento, le misure di protezione DDoS e sicurezza di rete sono uno dei tasselli da considerare. Il vero cambio di passo, però, è organizzativo: se gli exploit diventano più rapidi ed economici da produrre, anche inventario e patching devono diventare processi continui.
Fonti
- Linux: disponibile PoC per lo sfruttamento della CVE-2026-98432 – ACN
- OpenAI dichiara 948 exploit Linux generati da agenti AI per ottenere i privilegi di root – ICT Security Magazine