Un ricercatore di sicurezza ha pubblicato un exploit funzionante ed estremamente affidabile per una vulnerabilità del kernel Linux che permette a un utente comune, privo di privilegi, di ottenere il controllo completo di una macchina come root - senza password, senza ingegneria sociale, con la sola esecuzione di codice locale. La falla, di tipo Local Privilege Escalation (LPE), identificata come CVE-2026-46242 e soprannominata "Bad Epoll", colpisce server e desktop Linux, oltre agli smartphone Android con kernel 6.4 o superiore. Una patch esiste già a monte, ma non è ancora ampiamente distribuita.
Come funziona lo use-after-free di Bad Epoll
Il bug risiede in epoll, il meccanismo che il kernel Linux usa per permettere a un singolo programma di monitorare contemporaneamente migliaia di file aperti o connessioni di rete - qualcosa da cui dipendono praticamente tutti i server web, i database e i demoni VPN. Il ricercatore Jaeyoung Chung, del Computer Security Lab della Seoul National University, ha scoperto che quando due routine interne di pulizia di epoll, all'interno della funzione ep_remove(), vengono eseguite nello stesso momento, una può liberare un'area di memoria del kernel mentre l'altra vi sta ancora scrivendo. Questa finestra di use-after-free è ampia solo circa sei istruzioni CPU, ma il proof-of-concept di Chung, ora pubblico su GitHub, sfrutta la memoria corrotta per costruire una catena di return-oriented programming (ROP) che dirotta il flusso di esecuzione del kernel e garantisce l'accesso root all'attaccante.
Chi è a rischio
- Server e desktop Linux: qualsiasi distribuzione con un kernel mainline dalla versione 6.4 in poi è vulnerabile.
- Dispositivi Android: funzionamento confermato su un Google Pixel 10 (kernel 6.6); i dispositivi più vecchi ancora sul ramo long-term-support 6.1 non sono interessati.
- Il browser come punto d'ingresso: poiché l'exploit richiede solo l'esecuzione di codice locale, i ricercatori osservano che in teoria potrebbe essere lanciato dall'interno di un processo sandboxato come il renderer di Chrome, trasformando un semplice bug del browser nella completa acquisizione del dispositivo.
Il primo tentativo di correzione da parte dei maintainer del kernel, rilasciato dopo la patch di una precedente vulnerabilità collegata (CVE-2026-43074), non ha chiuso del tutto la falla - ci sono voluti circa altri due mesi prima che una correzione adeguata arrivasse nel kernel mainline. Questo processo di patching lento e in due fasi spiega esattamente perché così tanti sistemi restino esposti: le distribuzioni e i produttori Android sono spesso indietro di diversi cicli di patch rispetto al mainline, e i server autogestiti lo sono ancora di più.
Come verificare se sei interessato
Esegui uname -r in un terminale per vedere la versione del kernel in uso. Se indica 6.4 o superiore e la tua distribuzione o il tuo dispositivo non hanno ricevuto un aggiornamento di sicurezza dall'inizio di luglio 2026, considera il sistema vulnerabile e applica il prima possibile l'ultima patch del kernel o del produttore.
Perché la questione va oltre i computer personali
Bad Epoll non ha bisogno di una connessione di rete per funzionare - gli basta l'esecuzione di codice locale, il che a prima vista sembra rassicurante. Ma oggi "locale" copre un terreno vastissimo: server di hosting condiviso, runner CI/CD, istanze VPS in cloud, apparati di rete autogestiti e qualsiasi macchina Linux che esegua mai codice non attendibile, che si tratti di uno script scaricato, di un container escape o di una scheda del browser compromessa. Non appena un attaccante ottiene anche il più piccolo appiglio, Bad Epoll lo trasforma in controllo amministrativo completo.
Uno schema più ampio
Bad Epoll è anche un promemoria di quanto l'infrastruttura di rete moderna - comprese le macchine Linux su cui girano gateway VPN, proxy autogestiti e router domestici - dipenda da un sottosistema del kernel di cui la maggior parte degli utenti non ha mai sentito parlare. Una singola macchina non aggiornata su una rete condivisa, o un provider VPN lento nel distribuire gli aggiornamenti del kernel sulla propria flotta di server, può trasformare un bug "puramente locale" in un'esposizione ben più ampia per chiunque instradi lì il proprio traffico. Questa vicenda prosegue un tema ricorrente quest'anno: dal furto di credenziali FortiGate a Citrix Bleed, l'anello più debole dell'infrastruttura della privacy si rivela ancora una volta essere codice del kernel e del firmware non aggiornato e dall'aspetto poco appariscente, piuttosto che la crittografia in sé.
