Exploit pubblico per CVE-2026-80521: container Ubuntu a rischio root

Il 22 settembre 2026 DepthFirst ha pubblicato codice exploit per CVE-2026-80521, una vulnerabilità use-after-free nel sottosistema AF_UNIX del kernel Linux. Il codice consente l'escape da container a privilegi root sull'host su tutte le release Ubuntu LTS attive: 22.04, 24.04 e 26.04. Il problema non è la novità della falla — il fix upstream è del 6 agosto 2026 — ma il tempo che Canonical non ha ancora tradotto in patch distribuite.

La finestra di esposizione supera le sette settimane. Ubuntu 26.04, la release più recente, risulta ancora "vulnerable, work in progress" nel tracker di sicurezza senza ETA. Le varianti cloud kernel per AWS, Azure e GCP condividono lo stesso stato. L'exploit è pubblico, dettagliato e testato. L'assunto che il kernel condiviso costituisca un confine sicuro per i container non regge più.

Il meccanismo: una race condition nel garbage collector dei socket

La falla risiede nel modo in cui il kernel gestisce i riferimenti tra socket AF_UNIX quando i file descriptor vengono passati tramite messaggi SCM_RIGHTS. Nella normale operazione, unix_add_edges() pubblica i riferimenti edge tra socket prima che skb_queue_tail() accodi il buffer nella coda di ricezione. Questo crea una finestra temporale misurata in cui il garbage collector può osservare riferimenti appena creati su dati ancora non accodati.

Un processo in container può attivare questa condizione con sequenze ordinarie di syscall: apertura socket, passaggio fd, chiusura forzata. Il trigger del garbage collector su riferimenti parzialmente pubblicati produce lo use-after-free. Poiché AF_UNIX è permesso di default nei profili seccomp di Docker e Kubernetes, l'attacco non richiede capacità speciali né syscall esotiche. Namespace, cgroup e filtraggio seccomp vengono elusi tutti insieme.

Il patch gap di Ubuntu: sette settimane e contando

La timeline esprime con numeri il problema strutturale. Il fix è stato committato nel kernel mainline 7.2 e backportato allo stable 7.1.10 il 6 agosto 2026. DepthFirst aveva già vinto uno slot Google kernelCTF con l'exploit il 24 luglio 2026. La vulnerabilità è stata segnalata al kernel security team il 5 agosto, con conferma indipendente da parte di un ricercatore OpenAI. Il CVE commit accredita Kyle Zeng come reporter.

Nonostante questo percorso documentato, lo stato del tracker Ubuntu al 23 settembre 2026 mostra 26.04 come "vulnerable, work in progress". Le release 24.04 e 22.04, con pacchetti kernel più recenti che includono il codice backportato dal branch 6.1 e 6.6, condividono la stessa condizione. Le varianti cloud non sono eccezione: i kernel ottimizzati per AWS, Azure e GCP riportano la stessa etichetta di vulnerabilità.

"Ubuntu's security tracker lists the Linux package on 26.04 as 'vulnerable, work in progress'" — The Hacker News/DepthFirst research

Perché l'AI-accelerated discovery cambia la scala del rischio

DepthFirst ha dichiarato esplicitamente l'uso del modello AI dfs-large1 per la scoperta della vulnerabilità, con un testing harness umano che ha validato e affinato il trigger. Questo non è un caso isolato nel 2026: il conteggio di Linux kernel CVE pubblicati nell'anno, circa 5.700 secondo LinuxCVETracker, segna un record annuale. Tre container escape con exploit pubblico sono documentati solo nel 2026: futex a luglio, crypto ad aprile, AF_UNIX a settembre.

Il pattern suggerisce un'accelerazione strutturale. La scoperta automatizzata comprime il tempo tra esistenza della vulnerabilità e pubblicazione dell'exploit. La distribuzione delle patch non ha corrisposto alla stessa velocità. Il risultato è che la superficie d'attacco non è più la vulnerabilità nascosta, ma il sistema di distribuzione che lascia esposti milioni di nodi per settimane.

Cosa fare adesso

Quattro azioni prioritarie emergono dalle fonti verificate. Nessuna dipende da patch Canonical già disponibili.

• Valutare microVM per workload non trusted: DepthFirst indica Firecracker e Kata Containers come isolamento temporaneo che riduce l'esposizione rispetto ai container tradizionali condivisi
• Applicare profilo seccomp custom: ByteIota propone una deny rule esplicita su socket() con domain=AF_UNIX (value: 1), superando il profilo RuntimeDefault di Kubernetes che non include questa restrizione
• Verificare lo stato nel security tracker Ubuntu: il tracker è l'unica fonte ufficiale di ETA; le fonti non indicano canali alternativi di notifica
• Ricalibrare il threat model: assumere che il kernel condiviso non costituisca più boundary di sicurezza per container multi-tenant senza isolamento hardware

La proposta seccomp di ByteIota non è un advisory Ubuntu ufficiale. Il dossier non documenta misure correttive specifiche dal vendor né timeline di rilascio patch.

Il confine che non regge più

L'articolo di The Hacker News riporta una dichiarazione di DepthFirst che definisce il momento: "The barrier to escaping containers by attacking the kernel has fallen so significantly that we must assume attackers can do so at will". ByteIota aggiunge una lettura sul target: "The attack surface is not exotic — it is the default configuration of every Ubuntu-based container deployment".

La convergenza di queste due osservazioni descrive uno spostamento del rischio. Non serve più una configurazione errata o un privilegio elevato. Serve solo un container standard su kernel non patchato. La complessità del meccanismo — una race condition nel garbage collector — è irrilevante per chi scarica l'exploit pubblico. Ciò che conta è il gap tra chi può scoprire o pubblicare e chi distribuisce correzioni.

Il dossier non documenta attacchi attivi confermati né presenza nel catalogo KEV CISA. L'assenza di exploitation nota non mitiga la criticità: l'exploit è disponibile, le versioni affette sono quelle più diffuse in produzione cloud, e il percorso di correzione non ha una data.

FAQ

Perché l'exploit funziona anche con seccomp attivo?

I profili seccomp standard di Docker e Kubernetes permettono la syscall socket() con dominio AF_UNIX. La vulnerabilità si attiva interamente attraverso syscall ordinarie, senza richiedere operazioni bloccate.

Altre distribuzioni Linux sono affette?

Il dossier non specifica lo stato di patch per Red Hat, Debian o SUSE. Il codice vulnerabile è stato introdotto nel kernel 6.10 e backportato ai branch stable 6.1 e 6.6, quindi la presenza della falla dipende dalla cronologia di backport di ciascuna distribuzione.

L'exploit è stato usato in attacchi reali?

Non emergono report confermati di exploitation attiva al momento della pubblicazione. La fonte non documenta presenza nel catalogo KEV CISA né campagne identificate.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/09/exploit-released-for-unpatched-ubuntu.html
• https://byteiota.com/cve-2026-80521-ubuntus-unpatched-container-escape-has-a-public-exploit/
• https://fieldeffect.com/blog/linux-container-escape-flaw-exploited-validate-kernel-fixes/controls
• https://www.techtimes.com/articles/319914/20260708/public-exploit-turns-15-year-linux-kernel-flaw-5-second-root-attack.htm
• https://nvd.nist.gov/vuln/detail/CVE-2022-0492
• https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2026-31431
• https://thehackernews.com/
• https://thehackernews.com/p/upcoming-hacker-news-webinars.html