Le ultime settimane sono state intense per chiunque gestisca server Linux per mestiere. Tra la fine di aprile e la metà di maggio, i ricercatori di sicurezza hanno reso note cinque gravi vulnerabilità del kernel e ciascuna di esse consentiva a qualsiasi utente connesso al sistema di ottenere accesso amministrativo completo alla macchina. Per diverse di queste vulnerabilità, il codice funzionante dell’exploit è stato pubblicato fin dal primo giorno.

SiteGround ha applicato le patch di sicurezza per ognuna di queste vulnerabilità sulla propria infrastruttura di hosting senza riavviare un solo server e senza interrompere un singolo servizio dei clienti.

Cosa avrebbe comportato questo per i tuoi siti

In parole povere: se una qualsiasi di queste vulnerabilità fosse stata sfruttata su un server prima dell’applicazione della patch, un malintenzionato a cui bastava un minimo punto d’appoggio (un plugin WordPress compromesso, una password FTP trapelata, uno script vulnerabile) avrebbe potuto scalare i privilegi da un singolo account limitato all’interno di un sito fino al controllo totale della macchina sottostante. Da lì, il solito copione: leggere i file degli altri utenti, inserire backdoor persistenti, sottrarre credenziali e addentrarsi ancora di più nella rete.

Non parliamo di rischi teorici. Esisteva un codice di exploit pubblico per ognuna di queste vulnerabilità. Copy Fail, in particolare, è stato utilizzato attivamente “in natura” nel giro di pochi giorni dalla sua divulgazione.

Cosa è successo effettivamente

In ordine approssimativo, ecco cosa ha colpito il mondo Linux:

29 aprile, divulgazione di Copy Fail (CVE-2026-31431) – un singolo script Python da 732 byte poteva trasformare qualsiasi utente normale in root, praticamente su ogni distribuzione Linux rilasciata dal 2017 in poi. Nessun trucco legato al timing, nessun tentativo alla cieca: solo un bug logico nel sottosistema crittografico del kernel. CISA lo ha aggiunto nel giro di pochi giorni alla lista delle vulnerabilità attivamente sfruttate.

7 maggio, divulgazione di Dirty Frag, vulnerabilità xfrm/ESP (CVE-2026-43284)  – un difetto nel codice di rete IPsec ESP del kernel che consente a un attaccante di scrivere dati arbitrari nella copia in memoria di file di sistema in sola lettura. Spesso viene definito “Copy Fail 2”.

7 maggio, Dirty Frag, vulnerabilità RxRPC (la seconda metà della catena) – un bug correlato, nel modulo di rete RxRPC del kernel. Combinato con la vulnerabilità xfrm/ESP sopra citata, permette a un normale utente di ottenere accesso root completo.

13 maggio, divulgazione di Fragnesia / Copy Fail 3.0 (CVE-2026-46300) – il terzo bug in tre settimane, appartenente alla stessa famiglia di Dirty Frag, ancora una volta nel sottosistema IPsec del kernel. Una dimostrazione funzionante è stata pubblicata lo stesso giorno.

14 maggio, divulgazione e correzione della vulnerabilità ssh-keysign / chage pidfd da parte di Linus Torvalds – Un tipo diverso di bug: non consentiva l’escalation a root, ma permetteva a qualsiasi utente senza privilegi di leggere file appartenenti a root, come /etc/shadow (gli hash delle password) e le chiavi host SSH.

Come abbiamo risolto senza interruzioni di servizio

Quattro scelte su come opera SiteGround hanno reso questa situazione gestibile e, con uno sguardo a ciò che ci aspetta nel futuro, tutte e quattro diventeranno ancora più importanti con il tempo, non meno.

Monitoriamo costantemente il panorama delle minacce. Il nostro team di sicurezza monitora 24/7 le kernel mailing list, i feed CVE e i canali di divulgazione delle vulnerabilità. Sapevamo di Copy Fail il giorno stesso della divulgazione, di Dirty Frag il giorno della pubblicazione e di Fragnesia nel giro di poche ore dalla pubblicazione della dimostrazione. Non esiste alternativa all’avere un monitoraggio in tempo reale: quando queste storie arrivano ai giornali di settore mainstream, il codice dell’exploit spesso circola già da giorni. Con l’accelerazione della scoperta di vulnerabilità guidata dall’IA, questo tipo di monitoraggio continuo diventa essenziale più che opzionale.

Abbiamo ingegneri in servizio 24/7. Le patch critiche del kernel non fanno orario d’ufficio, e nemmeno noi. Per ciascuna di queste vulnerabilità abbiamo sviluppato, testato e distribuito le patch su tutta la nostra infrastruttura entro 48 ore dalla divulgazione pubblica, spesso prima ancora che la maggior parte delle distribuzioni rilasciasse i propri pacchetti di aggiornamento ufficiali.

Utilizziamo il live kernel patching. Questa è la parte più importante per l’utente. Il patching tradizionale del kernel richiede un riavvio, quindi comporta un’interruzione per tutti i servizi in esecuzione sulla macchina. Il live patching applica la correzione al kernel in esecuzione in memoria, senza riavviare nulla. Siti web, database, email e sessioni SSH hanno continuato a funzionare durante tutti questi cicli di aggiornamento. Quando la frequenza delle patch aumenta, il costo del “semplice riavvio del server” cresce di pari passo, il live patching è ciò che mantiene questo costo pari a zero per l’utente.

Manteniamo kernel snelli. Gran parte del rischio di questi bug deriva dal fatto che il codice vulnerabile è attivo in maniera predefinita nella maggior parte delle distribuzioni. Copy Fail risiedeva nell’interfaccia kernel crypto AF_ALG. Dirty Frag e Fragnesia erano nei moduli esp4, esp6 e rxrpc: codice IPsec e AFS che la maggior parte dei server web non utilizzerà mai nel proprio ciclo di vita. Noi non carichiamo moduli del kernel non necessari. Questo significa che una parte della superficie d’attacco di questi exploit semplicemente non esisteva sulle nostre macchine, dandoci ulteriore margine per applicare la correzione definitiva.

Il fattore IA e perché questo è solo l’inizio

Un dettaglio nella divulgazione di Copy Fail merita particolare attenzione. Il bug non è stato individuato da un ricercatore umano che analizza il codice per settimane. È stato invece scoperto da uno strumento di audit del codice basato sull’IA (Xint Code) in circa un’ora di scansione del sottosistema crittografico del kernel di Linux. La stessa analisi ha anche evidenziato “altri bug ad alta severità, ancora in fase di divulgazione coordinata”, il che significa che altre divulgazioni sono già in arrivo.

Questo rappresenta un cambiamento significativo nel modo in cui le vulnerabilità vengono scoperte. Per anni, il collo di bottiglia nella ricerca di bug critici nel kernel è stato il numero limitato di esperti umani disposti a passare mesi a leggere il codice sorgente del kernel. Quel limite ora non esiste più. Gli strumenti di audit basati sull’IA possono analizzare interi sottosistemi a velocità macchina e stanno individuando problemi rimasti silenti in kernel ritenuti stabili per quasi un decennio.

Cosa significa questo in pratica: il ritmo delle divulgazioni di vulnerabilità gravi continuerà ad aumentare. Tre exploit universali per ottenere privilegi di root locale in tre settimane non sono un caso, sono un’anteprima. I cicli di patch reattivi che funzionavano quando un bug critico nel kernel compariva ogni sei mesi non saranno più sufficienti quando ne arriva uno ogni due settimane. La capacità di rilevare, reagire e applicare patch nel giro di ore invece che di giorni non è più un fattore aggiuntivo, è la condizione minima per restare al sicuro.

Il messaggio chiave

Linux sta attraversando un periodo insolitamente critico per la sicurezza del kernel: tre exploit universali per ottenere privilegi di root locale in tre settimane non sono la norma, e la situazione non sta rallentando. Con strumenti di audit basati sull’IA che ora analizzano il kernel a velocità impossibili per un team umano, ci aspettiamo che il ritmo di scoperta delle vulnerabilità gravi continui ad accelerare. Bug rimasti silenti in kernel ritenuti stabili per anni stanno venendo individuati, un sottosistema alla volta.

Quello che possiamo garantire è che il modo in cui abbiamo gestito questi casi è lo stesso con cui gestiamo ogni vulnerabilità critica: monitoraggio precoce, patch rapide, correzione live e riduzione al minimo possibile della superficie d’attacco già in partenza. I tuoi siti restano online. Gli exploit no. E con l’aumento della frequenza delle divulgazioni, questo aspetto diventerà sempre più decisivo.