Un exploit pubblico per AF_UNIX compromette l’isolamento dei container Ubuntu e raggiunge il root dell’host

Un exploit pubblico per CVE-2026-80521 può trasformare l’esecuzione limitata di codice all’interno di un container Ubuntu in privilegi root sull’host sottostante.

La vulnerabilità è un use-after-free nel garbage collector dei socket AF_UNIX del kernel Linux. È raggiungibile tramite normali chiamate di sistema consentite dalle configurazioni seccomp standard di Docker e Kubernetes, rendendo inefficaci i controlli predefiniti dei container contro questo vettore d’attacco.

DepthFirst ha pubblicato codice di exploit funzionante destinato a Ubuntu 26.04. Al 23 settembre 2026 non risultano attacchi confermati e la vulnerabilità non è inclusa nel catalogo Known Exploited Vulnerabilities della Cybersecurity and Infrastructure Security Agency statunitense. Di conseguenza, non esiste una scadenza di remediation fissata da CISA.

L’exploit pubblico aumenta comunque il rischio per le piattaforme che eseguono container non attendibili o semi-attendibili su un kernel condiviso.

Una race condition nel garbage collector di AF_UNIX crea il percorso di evasione

I socket AF_UNIX forniscono comunicazioni locali tra processi e possono trasferire descrittori di file aperti tramite messaggi SCM_RIGHTS. Il kernel deve tenere traccia dei riferimenti trasferiti e recuperare i gruppi circolari di socket che non sono più raggiungibili.

CVE-2026-80521 nasce da una race condition all’interno di questo processo di garbage collection.

Ubuntu attribuisce la segnalazione a Kyle Zeng. La descrizione tecnica utilizza tre socket — A, B e X — per spiegare come si sviluppa la race condition:

1. I socket A e B appartengono a gruppi di riferimenti collegati, noti come componenti fortemente connesse o SCC, mentre X è associato al gruppo.
2. Operazioni concorrenti inviano sk-B da sk-X a sk-B e chiudono A e B.
3. Durante l’operazione di invio, unix_add_edges() pubblica un nuovo edge che rappresenta la relazione B-to-B.
4. Esiste un breve intervallo prima che il socket buffer contenente quel riferimento venga inserito con skb_queue_tail().
5. Se le operazioni di chiusura e la garbage collection avvengono durante quell’intervallo, il collector può classificare come morto il gruppo A-B.
6. B non viene liberato immediatamente perché il collector non è ancora in grado di vedere il socket buffer che contiene il riferimento appena pubblicato.
7. Un passaggio successivo della collection segue il scc_entry obsoleto di B fino a uno stato parzialmente liberato.

Il risultato è un use-after-free. La correzione upstream, intitolata af_unix: Unlink scc_entry in unix_del_edge()., rimuove la voce SCC interna prima di liberare il vertex associato.

La spiegazione di DepthFirst giunge alla stessa conclusione: il collector può osservare un riferimento pubblicato prima di vedere la struttura dati che lo contiene. La pulizia parziale lascia quindi un puntatore persistente diretto verso memoria già rilasciata.

I controlli predefiniti dei container non bloccano le chiamate necessarie

La vulnerabilità non richiede l’accesso remoto all’host. L’attaccante ha bisogno di un contesto locale con privilegi ridotti, ad esempio del controllo di un processo all’interno di un container.

Questo requisito si riflette nel punteggio CVSS 7,8, classificato come High, e nel relativo vettore:

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H

L’attacco ha una complessità ridotta, richiede privilegi limitati e non necessita di interazione da parte dell’utente. Un exploit riuscito può compromettere la riservatezza, l’integrità e la disponibilità dell’host.

Le operazioni sui socket AF_UNIX sono normalmente disponibili all’interno dei container. I profili seccomp di Docker e Kubernetes consentono per impostazione predefinita le interfacce interessate; l’exploit non dipende quindi da una configurazione insolita o volutamente permissiva.

Una volta sfruttata la vulnerabilità nella memoria del kernel, namespace, cgroups e filtri seccomp non possono preservare il confine di sicurezza previsto. Questi meccanismi isolano i processi, ma si basano tutti sullo stesso kernel dell’host. Una compromissione del kernel opera a un livello sottostante.

La distinzione è importante per i servizi multi-tenant, i runner CI/CD, gli ambienti di sviluppo basati su container e i sistemi che eseguono codice inviato dai clienti. Un processo che dovrebbe essere confinato a un singolo container può invece ottenere il controllo root dell’host e potenzialmente compromettere altri workload che lo condividono.

L’esposizione di Ubuntu dipende dal pacchetto kernel installato

Il security tracker a livello di pacchetto di Ubuntu fornisce una valutazione più precisa del solo numero di versione del sistema operativo.

Il pacchetto base linux per Ubuntu 22.04 LTS è contrassegnato come non interessato. Tuttavia, il pacchetto linux-hwe-6.8 della stessa release è vulnerabile. Gli amministratori devono quindi verificare quale flavor del kernel e quale ramo di pacchetti siano effettivamente installati.

Gli stati pubblicati rilevanti sono:

Pacchetto	Release Ubuntu	Stato
linux	26.04 LTS, Resolute	Vulnerabile, intervento in corso
linux	24.04 LTS, Noble	Vulnerabile
linux	22.04 LTS, Jammy	Non interessato
linux-hwe-6.8	22.04 LTS, Jammy	Vulnerabile
linux-hwe-6.17	24.04 LTS, Noble	Vulnerabile
linux-hwe-7.0	24.04 LTS, Noble	Vulnerabile
linux-aws	26.04 LTS, Resolute	Vulnerabile
linux-aws	24.04 LTS, Noble	Vulnerabile
linux-aws	22.04 LTS, Jammy	Non interessato
linux-aws-6.8	22.04 LTS, Jammy	Vulnerabile
linux-aws-7.0	26.04 LTS, Resolute	Vulnerabile
linux-azure	26.04 LTS, Resolute	Vulnerabile
linux-azure	24.04 LTS, Noble	Vulnerabile
linux-azure	22.04 LTS, Jammy	Non interessato
linux-azure-6.8	22.04 LTS, Jammy	Vulnerabile

Diversi rami più vecchi o sostituiti sono contrassegnati come non interessati, non inclusi nella release, ignorati o fuori supporto. Tra gli esempi figurano linux-kvm su Ubuntu 22.04, 20.04 e 18.04, oltre ai rami AWS, Azure e HWE 5.15 su Ubuntu 20.04.

L’advisory Ubuntu disponibile non fornisce uno stato per un pacchetto specifico per GCP. Inoltre, non indica una data per la disponibilità delle build Ubuntu corrette.

Esiste una patch upstream, ma la remediation di Ubuntu è ancora incompleta

Il codice vulnerabile del kernel è stato introdotto in Linux 6.10 e portato nei rami stable 6.1 e 6.6.

La correzione upstream è stata integrata il 6 agosto nel kernel mainline 7.2 e nel kernel stable 7.1.10. Le organizzazioni che gestiscono kernel personalizzati possono applicare direttamente questa modifica, seguendo le normali procedure di test e distribuzione.

La disponibilità upstream non significa che ogni ramo del kernel Ubuntu abbia ricevuto un pacchetto corretto. Ubuntu continua infatti a indicare diversi rami come vulnerabili, mentre il pacchetto base linux di Ubuntu 26.04 è contrassegnato nello specifico come oggetto di un intervento ancora in corso.

Ubuntu e DepthFirst non hanno pubblicato workaround temporanei. Non sono stati inoltre divulgati exploit signature, artefatti forensi o indicatori affidabili a livello di kernel che i difensori possano utilizzare per identificare tentativi di sfruttamento.

La ricerca assistita dall’AI ha prodotto un exploit funzionante per il kernel

DepthFirst ha dichiarato che il proprio modello di rilevamento delle vulnerabilità, dfs-large1, ha identificato il problema con il supporto di un harness di test gestito da operatori umani. L’azienda ha utilizzato l’exploit per ottenere uno slot nella Google kernelCTF il 24 luglio e ha segnalato il problema al team di sicurezza del kernel il 5 agosto.

Successivamente, i maintainer del kernel hanno comunicato a DepthFirst che un ricercatore di OpenAI aveva individuato in modo indipendente lo stesso bug. Il commit della CVE attribuisce la segnalazione a Kyle Zeng.

L’episodio dimostra qualcosa di più del semplice triage automatizzato dei bug. Il processo di ricerca ha portato a un container escape funzionante contro Ubuntu 26.04, coprendo l’individuazione, l’analisi della race condition, l’exploitation e la validazione su un obiettivo pratico.

Si aggiunge inoltre ad altre vulnerabilità del kernel emerse da ricerche assistite dall’AI e culminate nell’escalation ai privilegi root sull’host. La disponibilità pubblica di exploit è diventata un problema operativo ricorrente per gli host Linux privi di patch, non soltanto una misura della gravità teorica.

I difensori devono dare priorità all’inventario dei kernel e a un isolamento più efficace

Gli amministratori dovrebbero innanzitutto associare ogni host che esegue container al pacchetto kernel e al ramo installati. Verificare soltanto se una macchina esegue Ubuntu 22.04, 24.04 o 26.04 non è sufficiente, perché i pacchetti base, HWE, AWS e Azure presentano stati diversi.

Quando possibile, i kernel personalizzati interessati dovrebbero ricevere la correzione upstream. Sui sistemi gestiti da Ubuntu, i pacchetti della distribuzione corretti dovrebbero essere installati non appena disponibili.

Nel frattempo, le organizzazioni dovrebbero rivalutare quali workload possano condividere lo stesso kernel. DepthFirst raccomanda un isolamento basato su microVM, come Firecracker o Kata Containers, per il codice non attendibile. Queste architetture forniscono ai workload kernel separati, impedendo a un exploit del kernel del container di compromettere direttamente il kernel primario dell’host.

Il monitoraggio dovrebbe concentrarsi su processi inattesi a livello di host originati da contesti containerizzati, transizioni di privilegi prive di spiegazione e modifiche non autorizzate ai file dell’host o alla configurazione del runtime. Si tratta di segnali comportamentali, non di indicatori specifici della vulnerabilità.

L’assenza di attacchi confermati o di una voce nel catalogo CISA KEV non deve essere scambiata per una bassa sfruttabilità. Il codice funzionante è già pubblico e le interfacce interessate sono esposte nelle configurazioni standard dei container.