Microsoft ha individuato 59 difetti nel kernel Linux con una ricerca assistita dall’intelligenza artificiale, ottenendo 33 identificativi CVE e dimostrando in laboratorio otto attacchi capaci di portare un utente locale ai privilegi di root. Quando ha pubblicato i risultati, ieri, soltanto 38 correzioni erano già confluite nel ramo principale del kernel. Il kernel è il componente del sistema operativo che gestisce processi, memoria e interazione con l’hardware. La scoperta mostra quanto sia diventato veloce trovare vulnerabilità e quanto resti impegnativo verificarle, correggerle e distribuire gli aggiornamenti.
Il problema è più ampio della ricerca Microsoft. Pochi giorni prima OpenAI aveva presentato i risultati di un’altra scansione del kernel: 948 exploit locali dimostrativi, prodotti con un sistema automatico di ricerca, verifica e proposta delle patch. Sono studi differenti, con criteri e stati di correzione diversi, ma descrivono la stessa tensione: l’AI aumenta la capacità di scoprire difetti in un software essenziale per server, cloud, smartphone e apparati di rete. Gli stessi strumenti possono però ridurre il lavoro richiesto agli attaccanti per analizzare codice e aggiornamenti.
Indice degli argomenti
Vulnerabilità nel Kernel linux: come Microsoft ha trovato 59 bug in pochi mesi
Nel rapporto Lessons from 59 Linux Kernel Bug Reports, il laboratorio FORGE di Microsoft e il ricercatore Cen Zhang descrivono un progetto chiamato MDASH. Tra la fine di maggio e metà giugno 2026, la scansione di alcuni sottosistemi del kernel — reti, filesystem e moduli di sicurezza — ha generato 26.502 segnalazioni iniziali in circa due settimane. Dopo i filtri automatici ne sono rimaste 11.769. Agenti capaci di tentare la riproduzione dei difetti in ambienti virtualizzati QEMU hanno ristretto l’analisi a 621 casi sostenuti da prove sperimentali.
È servito poi il lavoro di ricercatori umani per eliminare duplicati, valutare la gravità e dialogare con i manutentori. Da quei 621 casi sono nate 59 segnalazioni pubbliche distinte. Ventiquattro delle 33 CVE assegnate avevano una gravità almeno alta secondo CVSS 3.1. Per otto CVE Microsoft ha sviluppato exploit di elevazione locale dei privilegi funzionanti in laboratorio, talvolta con configurazioni non predefinite o protezioni contro gli exploit disabilitate. Non è stata documentata nella ricerca una campagna criminale che sfrutti quelle otto falle.
Alcuni errori erano rimasti nascosti per anni: 8,1 anni l’età media dei 59 difetti, con uno presente da almeno 21 anni. Un esempio particolarmente significativo è la CVE-2026-64563, un errore nella libreria condivisa rhashtable. In determinate sequenze di operazioni, una struttura dati poteva continuare a riferirsi a memoria già liberata. Il codice vulnerabile era raggiungibile tramite una funzione diagnostica dei socket accessibile anche a utenti senza privilegi, e i ricercatori hanno dimostrato come, combinando le condizioni necessarie, potesse consentire di arrivare a root. Anche Android, in una configurazione verificata con SELinux attivo, risultava interessato.
La correzione di questa specifica falla richiedeva una modifica minima al codice. Ma la sua identificazione e la validazione dell’impatto hanno richiesto una ricostruzione tecnica molto più impegnativa. L’intero esperimento mostra che trovare il sospetto non coincide con consegnare una patch affidabile: secondo Microsoft, il lavoro sulle segnalazioni ha impegnato oltre quattro mesi-persona e il tempo mediano fra la prima patch pubblica e il rilascio nel ramo principale è stato di 41 giorni.
La ricerca OpenAI: quasi mille exploit in un’altra scansione
Il divario fra ricerca e correzione è ancora più visibile nello studio A thousand fewer paths to root, pubblicato da OpenAI il 4 novembre. Analizzando la versione più recente del ramo principale di Linux a metà ottobre 2026, un sistema di agenti ha individuato 2.308 possibili problemi, ne ha riprodotti dinamicamente 1.724 e ha prodotto 948 exploit locali di elevazione dei privilegi, insieme a proposte di correzione. Il costo API dichiarato per l’esecuzione è stato di circa 1,2 milioni di dollari.
Queste cifre non sono una classifica delle vulnerabilità effettivamente ancora aperte e non si possono sommare ai 59 casi Microsoft: periodi, ambiti analizzati, procedure di selezione e unità di misura differiscono; inoltre non è esclusa una sovrapposizione fra difetti identificati da ricercatori diversi. Quando OpenAI ha concluso l’analisi, 61 dei problemi erano già stati corretti a monte, 43 avevano patch in preparazione e 299 erano in fase di segnalazione e discussione pubblica. Per gli altri non si può dedurre dalla sola cifra complessiva che siano già disponibili aggiornamenti installabili.
La ricerca conferma però una tendenza documentata anche da Microsoft: un modello migliore può trovare nuovi difetti nello stesso codice già esaminato da modelli precedenti. Gli errori non sono necessariamente introdotti da uno sviluppo recente: possono esistere da molti anni e diventare individuabili grazie a tecniche di analisi più efficaci.
Quando l’AI aiuta gli attaccanti a capire le patch
Un aggressore non deve necessariamente scoprire da zero il difetto di un programma. Può confrontare una versione vulnerabile con quella aggiornata, isolare le modifiche di sicurezza e ricostruire quale comportamento fosse sfruttabile. Questa attività, chiamata patch diffing o reverse engineering delle patch, esiste da tempo. I modelli AI possono accelerare l’esame delle differenze, la comprensione del codice e la preparazione di test, anche se realizzare un exploit affidabile continua a richiedere competenze e a dipendere dalle difese del sistema.
Nel podcast Decoder di The Verge, pubblicato il 7 novembre, Alex Stamos, responsabile della sicurezza di Cognition ed ex chief security officer di Facebook, racconta di riuscire, con un modello a pesi aperti eseguito localmente, ad analizzare una patch Microsoft e sviluppare codice d’attacco. Precisa tuttavia che il procedimento non è ancora completamente automatico. Secondo Stamos, ciò che un tempo richiedeva ricercatori altamente specializzati diventa progressivamente accessibile a gruppi più numerosi.
Il rischio per chi amministra sistemi Linux non nasce quindi dalla sola pubblicazione di nuove CVE. Nasce dal tempo che separa la scoperta dalla correzione, dalla distribuzione nei pacchetti delle singole distribuzioni e dall’installazione sui server. Una patch pubblica può rendere più chiara la vulnerabilità prima che una parte degli utenti sia riuscita ad aggiornare. Il problema è ancora più serio quando un difetto locale di elevazione dei privilegi viene concatenato con un accesso iniziale ottenuto attraverso una diversa applicazione vulnerabile.
Il precedente PHP2Shell e la corsa contro il tempo
Il caso PHP2Shell ha mostrato nell’ottobre 2026 la pressione esercitata dalla scoperta accelerata delle vulnerabilità sulle comunità che mantengono software molto diffuso. Due problemi critici del motore PHP, identificati come CVE-2026-109618 e CVE-2026-109619, potevano consentire l’esecuzione remota di codice senza autenticazione. Le versioni corrette 8.5.12, 8.4.27, 8.3.36 e 8.2.35 sono state pubblicate il 21 ottobre.
Nella ricostruzione della PHP Foundation, i difetti erano stati indagati da ricercatori diversi, fra cui Calif, OpenAI e Wiz; i manutentori avevano incontrato difficoltà di progettazione e risorse nel correggere i problemi senza rompere la compatibilità del linguaggio. La fondazione ha riferito anche di un aumento delle segnalazioni assistite dall’AI, comprese quelle non valide o duplicate. Secondo l’advisory Sophos, Amazon Threat Intelligence aveva rilevato un tentativo di sfruttamento già il 17 ottobre, prima della divulgazione pubblica.
PHP2Shell non prova che gli attacchi siano nati dal reverse engineering delle patch: i tentativi riportati precedono infatti il rilascio delle correzioni. È però un esempio della stessa asimmetria temporale: gruppi diversi possono conoscere e cercare di sfruttare una falla mentre chi mantiene il software deve completare gli aggiornamenti e gli utilizzatori devono distribuirli.
La proposta di Stamos: riscrivere il kernel Linux in Rust
Davanti all’aumento dei bug individuabili, Stamos propone nel podcast una risposta più radicale delle correzioni una per volta. Per parte del vecchio software, sostiene, riscrivere può ormai costare meno che riparare migliaia di difetti. Spinge il ragionamento fino a chiedere a grandi imprese tecnologiche come Google e Amazon di finanziare la riscrittura del kernel Linux in Rust, un linguaggio che offre maggiori garanzie sulla sicurezza della memoria rispetto al C usato per gran parte del kernel.
Vero che la riscrittura integrale comporterebbe ostacoli notevoli: compatibilità con architetture hardware e driver, anni di lavoro sui componenti consolidati, prestazioni, manutenzione e soprattutto verifica che il nuovo software conservi il comportamento atteso. Rust non elimina vulnerabilità logiche, errori di autorizzazione o configurazioni insicure. Può invece prevenire per costruzione molte classi di errori di memoria, come alcuni degli use-after-free emersi nelle ricerche.
La transizione è peraltro già cominciata, ma per componenti selezionati. La roadmap Rust for Linux 2026 descrive Rust come parte integrante del kernel, con driver e strumenti già sviluppati nel linguaggio. Un riscontro empirico viene da Google, in una ricerca del novembre 2025 su Android, che ha misurato una densità di difetti di sicurezza della memoria molto inferiore nel nuovo codice Rust rispetto allo storico C/C++. Si tratta di risultati relativi all’ecosistema Android, non di una misura sulla riscrittura completa di Linux.
Fra la manutenzione ordinaria e il rifacimento totale esiste dunque una strategia intermedia: riscrivere prima i sottosistemi più esposti o difficili da mettere in sicurezza, usare l’AI per produrre e verificare test di regressione, ridurre il codice obsoleto e investire nella revisione dei componenti comuni, dove una singola falla può raggiungere più funzioni del sistema.
Perché non basta aumentare il numero di ricercatori AI
Microsoft riassume il limite della sola ricerca automatica con una frase: “Più token possono far emergere più bug, ma non un sistema sicuro”. Se i modelli producono migliaia di sospetti, il lavoro dei manutentori deve comunque separare i casi veri dai falsi positivi, comprenderne la causa, preparare correzioni che non introducano regressioni e coordinare distribuzioni e produttori. Il collo di bottiglia si sposta dalla scoperta alla riparazione.
Per gestire questa pressione, la Linux Foundation ha avviato Akrites il 25 giugno 2026, con aziende tecnologiche e laboratori AI impegnati a coordinare segnalazioni, correzioni e divulgazione delle vulnerabilità dell’open source critico. L’iniziativa prevede un gruppo condiviso per la risposta agli incidenti di sicurezza e procedure comuni di comunicazione riservata. Non sostituisce i manutentori: cerca di dare loro supporto, competenze e risorse per processare segnalazioni sempre più numerose.
La documentazione ufficiale del kernel Linux conferma perché la correzione richieda tempo: i report devono specificare versioni interessate e condizioni di riproduzione, i responsabili possono chiedere ulteriori analisi e le patch passano attraverso revisione e coordinamento. La sicurezza non si misura quindi contando soltanto le CVE scoperte, ma anche la velocità con cui difetti verificati diventano aggiornamenti realmente installati.
Kernel Linux e vulnerabilità: che cosa cambia per aziende e PA italiane
Per le organizzazioni italiane il rischio riguarda soprattutto server Linux, piattaforme cloud e Kubernetes, infrastrutture di rete, dispositivi Android e apparati che incorporano kernel mantenuti dal produttore. Le otto dimostrazioni Microsoft sono elevazioni locali dei privilegi: da sole non dimostrano che un server sia attaccabile via Internet senza accesso preliminare. Diventano più pericolose quando l’aggressore ottiene prima l’esecuzione di codice attraverso un servizio web, credenziali rubate o un’altra vulnerabilità.
La prima misura è sapere quali kernel sono davvero in uso: inventariare host, immagini container, nodi Kubernetes, dispositivi e firmware, tenendo traccia della distribuzione e dei pacchetti del produttore. Non basta confrontare il numero di versione con quello di Linux upstream: Red Hat, Ubuntu, Debian e altri fornitori possono integrare correzioni senza cambiare alla stessa maniera tutte le componenti del numero di versione.
La seconda è distinguere i sistemi più esposti e sensibili: macchine multiutente, ambienti con carichi non fidati, servizi con accesso remoto, piattaforme che ospitano dati critici e nodi condivisi. Occorre valutare rapidamente gli advisory dei vendor, installare gli aggiornamenti disponibili e pianificare i riavvii quando necessari. Il live patching può ridurre alcuni tempi di fermo, ma non copre ogni vulnerabilità né sostituisce le altre procedure di aggiornamento.
La terza è limitare le conseguenze dell’accesso iniziale: privilegi minimi per processi e container, isolamento dei carichi, restrizioni delle funzionalità del kernel non necessarie, monitoraggio di escalation anomale e controlli sulle identità. Per i fornitori e i grandi utilizzatori di software critico si aggiunge una responsabilità: finanziare test, manutenzione e riscrittura mirata delle dipendenze comuni. È su queste attività, oltre che sulla scoperta di nuovi difetti, che si giocherà la capacità di ridurre il rischio prodotto dalla nuova generazione di strumenti AI.
Partecipa alla community