Cosa si è rotto, in parole semplici

Il 3 luglio 2026 il ricercatore Jaeyoung Chung ha pubblicato Bad Epoll, tracciato come CVE-2026-46242. È una race di tipo use-after-free nel sottosistema epoll del kernel Linux, il meccanismo standard con cui un programma sorveglia molti file e connessioni di rete contemporaneamente. Server, servizi di rete e browser web vi si appoggiano tutti, ed è per questo che non si può semplicemente spegnere.

L'effetto pratico è netto. Un aggressore che ha già un qualsiasi appiglio con pochi privilegi sulla macchina, una shell da un'applicazione web compromessa, un'app mobile malevola, un account di un fornitore, può scalare fino a root completo. Il proof of concept di Chung, presentato al programma kernelCTF di Google, allarga una finestra temporale normalmente ampia solo circa sei istruzioni macchina e ottiene root circa il 99 percento delle volte. Il kernel 6.4 e successivi sono colpiti se non già corretti; le build più vecchie basate su 6.1 no.

Perché solo locale non significa rischio basso

È allettante archiviare una scalata di privilegi locale sotto più tardi. Quel riflesso è sbagliato per chi gestisce una flotta. Le violazioni moderne hanno due passi. Il primo passo, una credenziale esposta, una sessione rubata, un front-end web vulnerabile, porta un aggressore sulla macchina come utente limitato. Bad Epoll è il secondo passo che converte quell'utente limitato in root, disattiva il logging e trasforma un incidente contenuto in uno esteso a tutto il dominio.

Il fronte Android affina il punto. Un'app malevola o trojanizzata che supera la bassa soglia di farsi installare può ora puntare a root sui dispositivi con kernel 6.4 o successivi. Per qualunque organizzazione che consenta al personale di leggere la posta aziendale su telefoni personali, il confine che si supponeva tra un'app cattiva e i vostri dati è appena diventato più sottile. Questa è una storia di gestione delle patch travestita da bug del kernel.

Il punto cieco dell'audit con IA che gli operatori hanno ereditato

Ecco il dettaglio che dovrebbe arrivare al consiglio di amministrazione, non solo al team di sicurezza. Lo stesso commit del kernel del 2023 ha introdotto due race condition contigue in circa 2.500 righe di codice epoll. Il modello Mythos di Anthropic ha colto la prima, ora tracciata come CVE-2026-43074. Ha mancato la seconda, quella diventata Bad Epoll. Le race condition sono notoriamente difficili da individuare, e la revisione automatica, come quella umana, non le individua in modo uniforme.

La lezione non è che la revisione del codice con IA abbia fallito. È che un passaggio pulito dell'IA non è un certificato di via libera. Se i vostri responsabili tecnici hanno iniziato a citare audit automatizzati come prova che il codice è sicuro, questo è il caso di studio che dice: un risultato positivo restringe il rischio, non lo chiude. Trattate la revisione con IA come uno strato, finanziate il fuzzing e gli specialisti umani accanto ad essa, e non lasciate mai che un rapporto verde della macchina diventi la ragione per saltare un controllo.

Cosa fare questa settimana

Applicate la correzione a monte, il commit del kernel a6dc643c6931, o il backport della vostra distribuzione, dando priorità agli host esposti a internet e multi-tenant dove è più probabile che giri codice locale non fidato. Per i parchi Android gestiti, distribuite gli aggiornamenti di sicurezza del fornitore e verificate quali dispositivi girano su kernel 6.4 o successivi. Epoll non si può disattivare, quindi non c'è scorciatoia di configurazione; la patch è la mitigazione.

Poi usate il momento come test di governance. Ponete una domanda nella vostra prossima revisione operativa: se oggi viene compromesso un account con pochi privilegi, cosa gli impedisce di diventare root entro venerdì? Se la risposta onesta dipende da una patch che non avete ancora pianificato, avete trovato la falla per cui questo bug è stato costruito.