Per quindici anni è rimasto nascosto nel cuore del kernel Linux, e ora chiunque abbia un account su una macchina non aggiornata può usarlo per diventare root in circa cinque secondi. Si chiama GhostLock (CVE-2026-43499), è stato divulgato il 7 luglio 2026 insieme a un exploit funzionante, e riguarda praticamente tutte le distribuzioni Linux in circolazione. Il punteggio CVSS 7.8 non rende giustizia alla portata reale del problema: la falla non serve solo a scalare i privilegi su un server, ma permette anche di evadere dai container e raggiungere il sistema host. È proprio questa seconda capacità a spostare GhostLock dalla categoria "vulnerabilità locale fastidiosa" a quella "rischio serio per il cloud e l'hosting condiviso".

Cosa è successo

GhostLock è una use-after-free nel codice dei real-time mutex (rt_mutex) del kernel, più precisamente nella logica di priority inheritance che viene attivata attraverso il sottosistema futex. In condizioni di gara (race condition), la funzione remove_waiter() azzera per errore un puntatore associato al task in esecuzione anziché a quello realmente in attesa: da lì nasce un puntatore pendente che un attaccante può manipolare per riscrivere strutture del kernel e ottenere l'esecuzione di codice con i massimi privilegi.

Il codice vulnerabile è presente per impostazione predefinita in ogni distribuzione mainstream dal kernel 2.6.39 del 2011 fino alla versione 7.1. La ricerca è stata pubblicata dal team di Nebula Security nell'ambito del lavoro "IonStack", e Google ha riconosciuto una ricompensa di 92.337 dollari tramite il programma kernelCTF. Ciò che rende GhostLock particolarmente pericoloso è la combinazione di tre fattori: non richiede alcun permesso speciale, nessuna configurazione anomala e nessun accesso di rete. Bastano normali chiamate di threading da un qualsiasi programma locale. L'exploit pubblico, secondo chi lo ha sviluppato, è affidabile al 97% e, cosa decisiva, esce dai container Docker e Kubernetes per compromettere l'host sottostante.

Perché la fuga dal container cambia tutto

Una vulnerabilità di local privilege escalation richiede, per definizione, che l'attaccante abbia già un piede dentro il sistema. Sembra un vincolo forte, ma nella realtà è la norma: un'applicazione web bucata, un container che esegue codice non fidato, uno script CI/CD compromesso o un semplice utente con accesso SSH sono tutti punti di partenza sufficienti. GhostLock trasforma quel foothold limitato in controllo totale della macchina. E quando il container in cui l'attaccante è confinato condivide il kernel con decine di altri container di clienti diversi, l'evasione verso l'host significa mettere le mani su tutti gli inquilini di quell'infrastruttura.

Cosa significa per le aziende italiane

Il punto di attenzione numero uno, in Italia, sono i provider di hosting condiviso e i fornitori cloud. Buona parte dell'hosting nazionale gira su CloudLinux, una distribuzione pensata proprio per la multi-tenancy, e su cluster Kubernetes che condividono il kernel dell'host fra molti workload. In questi ambienti un singolo sito WordPress compromesso su un piano di hosting economico può diventare, grazie a GhostLock, il trampolino per prendere il controllo dell'intero server fisico e dei dati di ogni altro cliente che ci risiede. È lo scenario peggiore per un fornitore: una violazione che nasce nel perimetro di un utente e si propaga a tutti gli altri.

Il secondo fronte riguarda le infrastrutture containerizzate di aziende e pubblica amministrazione. Molte organizzazioni italiane hanno adottato container e orchestratori negli ultimi anni convinte che l'isolamento fosse una barriera solida. GhostLock ricorda una verità scomoda: i container condividono il kernel dell'host, e una falla nel kernel annulla l'isolamento. Non basta aggiornare le immagini o rifare il deploy delle applicazioni: se il kernel dell'host non è corretto, il cluster resta vulnerabile.

Sul piano normativo il quadro è chiaro. Per i soggetti che rientrano in NIS2 — e i fornitori di servizi digitali, i data center e molti gestori di infrastrutture ci rientrano — la gestione tempestiva delle vulnerabilità e il patch management sono obblighi, non buone pratiche facoltative. Un'evasione da container che espone dati personali di più clienti configura una violazione ai sensi dell'art. 32 del GDPR (misure tecniche adeguate) e fa scattare la notifica al Garante entro 72 ore, oltre alla comunicazione ad ACN/CSIRT Italia per i soggetti obbligati. Per un provider, la differenza tra applicare la patch oggi o fra due settimane può essere la differenza tra un incidente contenuto e una notifica multipla di data breach.

Cosa fare subito

  • Aggiornare il kernel alla versione corretta per la propria distribuzione e riavviare. Su AlmaLinux 8 la correzione è in kernel-4.18.0-553.141.2.el8_10 e successivi, su AlmaLinux 9 in kernel-5.14.0-687.23.2.el9_8 e successivi, su AlmaLinux 10 in kernel-6.12.0-211.31.2.el10_2 e successivi. Le altre distribuzioni (RHEL, Debian, Ubuntu, SUSE) stanno rilasciando i rispettivi aggiornamenti: allinearsi appena disponibili.
  • CloudLinux: applicare il livepatch KernelCare, che chiude la falla senza riavvio su tutte le versioni interessate — soluzione ideale per i provider che non possono programmare downtime immediati.
  • Verificare la versione in uso con uname -r e confrontarla con l'advisory della propria distribuzione prima di considerare il sistema al sicuro.
  • Ambienti container e Kubernetes: aggiornare il kernel dell'host, non le immagini. Finché il nodo non è corretto, i pod restano esposti all'evasione.
  • Mitigazione temporanea dove il riavvio non è possibile: un profilo seccomp che blocchi le operazioni di priority-inheritance sui futex chiude il percorso di attivazione, ma va testato perché interrompe i workload che usano legittimamente i mutex a eredità di priorità.
  • Ridurre la superficie: limitare l'accesso shell locale ai soli utenti necessari, rafforzare l'isolamento (user namespace, runtime come gVisor o Kata dove possibile) e monitorare crash anomali del kernel e tentativi di privilege escalation.

GhostLock non è una minaccia esotica: è codice banale, un exploit pubblico e affidabile, e una superficie d'attacco che coincide con l'intero parco Linux. La finestra fra la disponibilità della patch e il suo sfruttamento di massa si misura in giorni. Per chi gestisce hosting, cloud o cluster multi-tenant, aggiornare il kernel questa settimana non è un'opzione: è la priorità.