Ubuntu senza patch per CVE-2026-80521: exploit evade i container e prende root

🛡️ Executive Summary

• CVE-2026-80521 è una use-after-free nel sottosistema AF_UNIX capace di trasformare codice nel container in root sull’host.
• DepthFirst ha pubblicato un exploit completo contro Ubuntu 26.04 dopo aver vinto una slot Google kernelCTF con la vulnerabilità.
• La patch esiste upstream dal 6 agosto, ma Canonical indica ancora kernel Ubuntu interessati come vulnerabili o in lavorazione.

Un exploit pubblico per CVE-2026-80521 dimostra nuovamente che il kernel condiviso è il punto debole strutturale dell’isolamento basato sui container. La vulnerabilità è una use-after-free nel sottosistema AF_UNIX del kernel Linux e DepthFirst ha pubblicato una catena capace di partire da un container non privilegiato e ottenere root sull’host Ubuntu 26.04. Il dato operativo più delicato è il patch gap: la correzione upstream è disponibile dal 6 agosto 2026, ma il tracker di Canonical continua a indicare pacchetti Ubuntu interessati senza una correzione distribuita per tutte le configurazioni coinvolte. Non risultano exploitation attive, ma il codice funzionante è ormai pubblico.

CVE-2026-80521 rompe l’isolamento attraverso AF_UNIX

La ricerca originale di DepthFirst descrive CVE-2026-80521 come una heap use-after-free nel garbage collector del sottosistema AF_UNIX, utilizzato per la comunicazione locale tra processi e per il passaggio di file descriptor attraverso SCM_RIGHTS. La vulnerabilità nasce da una race condition nella gestione delle strutture utilizzate dal garbage collector: in determinate condizioni un unix_vertex può essere liberato mentre un riferimento resta presente nella struttura persistente utilizzata nelle successive operazioni di raccolta. Il passaggio successivo dereferenzia quindi memoria già liberata.

DepthFirst sostiene di avere individuato il bug con dfs-large1, modello interno addestrato alla vulnerability discovery, insieme a un harness sviluppato dai ricercatori. Il gruppo ha sfruttato la falla il 24 luglio in Google kernelCTF, ha notificato il kernel security team il 5 agosto e ha ricevuto conferma che un ricercatore di OpenAI aveva segnalato indipendentemente lo stesso problema. La patch upstream è arrivata il giorno successivo. È un’altra dimostrazione del rapporto ormai diretto tra AI e ricerca offensiva già osservato quando un modello aveva aiutato a individuare e trasformare in exploit una use-after-free nel kernel Linux.

Leggi anche: Linux kernel, tre falle sfruttate e quattro nuovi exploit portano a root

L’exploit passa dal container a root sull’host Ubuntu 26.04

Il punto che trasforma CVE-2026-80521 da normale vulnerabilità locale a problema cloud è la possibilità di container escape. DepthFirst ha pubblicato un exploit completo contro Ubuntu 26.04 che sfrutta il kernel condiviso per oltrepassare il confine del container e raggiungere il sistema host con privilegi root. L’exploit non significa che qualsiasi container Ubuntu sia automaticamente compromesso: servono un kernel vulnerabile e condizioni compatibili con la catena sviluppata dai ricercatori. Dimostra però che l’isolamento namespace/cgroup non può proteggere l’host quando la vulnerabilità risiede nella stessa componente kernel utilizzata da entrambi.

Il tracker ufficiale Canonical per CVE-2026-80521 conferma che il problema interessa diversi pacchetti kernel Ubuntu e permette di verificare lo stato delle singole release e varianti. Il nodo è proprio la distanza tra la correzione mainline e il suo backport nei kernel mantenuti dalla distribuzione: non basta sapere che Linux upstream ha già chiuso la falla, perché i server utilizzano pacchetti Canonical con alberi, configurazioni e backport propri.

Il patch gap diventa più pericoloso quando esiste già il codice exploit

La vulnerabilità non risulta nel catalogo KEV e, al momento della disclosure, non esistono prove pubbliche di sfruttamento in attacchi reali. È quindi scorretto descriverla come zero-day attivamente sfruttata. Il rischio operativo deriva da una combinazione differente: patch upstream disponibile, distribuzioni ancora in fase di backport e exploit pubblico che riduce drasticamente il lavoro necessario per studiare la primitive. Questa dinamica è già comparsa nell’ecosistema Linux. Pedit COW e DirtyClone hanno mostrato come primitive sul page cache possano essere trasformate in escalation root, mentre i quattro exploit pubblicati a settembre per DirtyAH6, TUNderflow, PPPoEject e DiagSpill hanno ricordato che la disponibilità del codice modifica il rischio anche in assenza di exploitation osservata. Il CVSS 7.8 di CVE-2026-80521 descrive la severità tecnica, ma non fotografa da solo il valore di un exploit container-to-host su infrastrutture multi-tenant.

I container non sono una barriera equivalente a una VM

DepthFirst usa la vulnerabilità per sostenere una tesi più ampia: workload non fidati e workload sensibili dovrebbero essere spostati verso forme di isolamento che non condividono lo stesso kernel, come Firecracker o Kata Containers. La formulazione è volutamente netta, ma il principio tecnico è corretto: namespace, cgroup, seccomp, capability e LSM riducono la superficie disponibile dentro un container; non eliminano però una vulnerabilità sfruttabile nel kernel comune. Anche Docker Sandboxes ha recentemente mostrato quanto sia delicato il confine tra workload isolato e host. Una microVM aggiunge invece un kernel separato e sposta il confine verso l’hypervisor. Non rende impossibile l’escape, ma costringe l’attaccante ad attraversare un livello differente invece di sfruttare direttamente lo stesso kernel del sistema fisico.

Continua con:
CISA conferma una falla Linux capace di facilitare l’uscita dal container
Google Project Zero rende riproducibili le race condition del kernel Linux

Per Ubuntu la priorità è chiudere la finestra tra upstream e distribuzione

Non essendoci una exploitation confermata, CVE-2026-80521 resta un problema di exposure management e patch management, non ancora di incident response generalizzata. I sistemi che eseguono workload non fidati meritano però priorità superiore, soprattutto dove più tenant condividono lo stesso host o dove un container compromesso contiene un’applicazione direttamente raggiungibile da Internet. La lezione non è che i container abbiano improvvisamente smesso di essere utili. È che non devono essere considerati un confine equivalente a una macchina virtuale quando il threat model include un attaccante capace di colpire il kernel. Ora che un exploit completo è pubblico, il tempo tra disclosure, backport e distribuzione della patch diventa esso stesso parte della superficie d’attacco.