CVE-2026-120306: container escape in Beta9, come verificare e aggiornare al worker 0.1.756

È stata pubblicata CVE-2026-120306, una vulnerabilità critica (CVSS 9.9) in Beta9, il runtime open source di beam.cloud per workload serverless su GPU, sandbox e job in background. Il difetto sta nel modo in cui il worker esegue i passaggi di build delle immagini dei tenant: l'isolamento è insufficiente e un utente con un semplice token di workspace può uscire dal container di build e raggiungere il filesystem del worker, i suoi binari e il token dell'account di servizio Kubernetes. Il problema è corretto nel worker 0.1.756. Se gestisci un'installazione self-hosted di Beta9 che accetta build di immagini da utenti diversi, questa è una priorità.

Cosa è successo: la vulnerabilità CVE-2026-120306 in Beta9

Beta9 trasforma ogni comando shell presente nella definizione dell'immagine di un tenant in una riga RUN di un Dockerfile e la esegue con Buildah sul worker di build. L'immagine del worker imposta BUILDAH_ISOLATION=chroot e nessuna invocazione di Buildah passa --isolation. Il risultato è che il passo di build cambia solo la radice del filesystem (chroot), ma mantiene i namespace PID, network, IPC e user del pod del worker, gira come uid 0 e conserva la capability CAP_DAC_OVERRIDE.

In questa condizione il PID 1 nel procfs è l'entrypoint del worker, quindi /proc/1/root corrisponde al filesystem del container del worker ed è scrivibile. In quel filesystem si trovano i binari runc, buildah e runsc usati per avviare i container dei tenant, il token dell'account di servizio Kubernetes del worker e le directory host montate nel pod. I pod worker sono privilegiati. Le build layered Clip v2 sono il comportamento predefinito, quindi un tenant con un token di workspace raggiunge questa condizione semplicemente inviando una build di immagine.

Chi è colpito: versioni vulnerabili di Beta9

Sono interessate le installazioni di Beta9 con un worker precedente alla 0.1.756, in cui i passaggi RUN di Buildah vengono eseguiti con isolamento chroot dentro i namespace del worker. Il rischio concreto riguarda i deployment multi-tenant o comunque esposti a utenti che possono sottomettere build di immagini: chi può inviare una definizione di immagine con comandi shell può innescare il difetto.

Il fornitore e il prodotto nei feed risultano non classificati, ma il riferimento è univoco: il progetto è beam-cloud/beta9. Se usi Beta9 come servizio gestito di terze parti, verifica con il provider la versione del worker in produzione. Se lo esegui tu su Kubernetes, devi controllare la versione del componente worker.

Quanto è grave: punteggio CVSS e sfruttamento

Il punteggio è CVSS 9.9, gravità critica, con vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. Tradotto: attacco di rete, bassa complessità, privilegi bassi (basta un token di workspace), nessuna interazione utente e soprattutto scope changed, cioè l'impatto esce dal confine del componente vulnerabile. Impatto massimo su riservatezza, integrità e disponibilità.

In pratica un tenant ottiene accesso in scrittura al filesystem del worker, ai binari del runtime e al token dell'account di servizio Kubernetes. Da lì può arrivare a compromettere il nodo e, a seconda dei permessi del service account, il cluster. Al momento non risulta nel catalogo CISA KEV uno sfruttamento attivo, ma la combinazione di privilegi bassi richiesti e impatto sul cluster la rende da trattare con la massima priorità. La prova di concetto in sola lettura ha confermato i namespace condivisi, la presenza di CAP_DAC_OVERRIDE e la visibilità del binario runc del worker in /proc/1/root.

Come capire se sei esposto: verifica versione, esposizione e log

I controlli vanno fatti sul cluster che ospita i worker di Beta9.

• Versione del worker: individua l'immagine del worker in uso e confronta il tag con 0.1.756. Puoi elencare le immagini dei pod worker con kubectl get pods -o jsonpath sui container del namespace in cui gira Beta9, oppure controllare i manifest di deploy che hai applicato.
• Configurazione di isolamento: verifica se nell'immagine o nell'ambiente del worker è impostato BUILDAH_ISOLATION=chroot e se le invocazioni di Buildah non passano --isolation. Se la versione è precedente alla fix, assumi che sia così.
• Chi può sottomettere build: controlla quanti workspace e token esistono e se utenti non fidati possono avviare build di immagini. In un contesto multi-tenant l'esposizione è massima.
• Privilegi dei pod worker: verifica che i pod worker siano privilegiati e quali permessi ha il loro service account (kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SA). Più ampi sono i permessi, più grave è la conseguenza di una fuga del token.
• Log e indicatori: controlla i log del worker e dell'audit di Kubernetes per build anomale, accessi inattesi all'API con il service account del worker, scritture inattese su percorsi del worker e uso del token da indirizzi o pattern insoliti.

Come risolvere la vulnerabilità CVE-2026-120306: patch e aggiornamento

La correzione è disponibile nel worker 0.1.756. In quella release i passaggi RUN di Buildah, incluso il mkdir del WORKDIR, usano isolamento OCI con namespace PID, IPC e network privati al posto del chroot nei namespace del worker, e i valori ARG dei tenant vengono passati solo al container di build. Il commit introduce anche validazioni più severe su volumi, operazioni sui file della sandbox e sincronizzazione del workspace.

• Aggiorna l'immagine del worker alla release worker-0.1.756 pubblicata nel repository ufficiale e riavvia i pod worker.
• Dopo l'aggiornamento, ripeti i controlli: verifica che le build usino isolamento OCI con namespace privati e che gli ARG dei tenant non raggiungano l'ambiente del processo Buildah.
• Verifica sull'advisory ufficiale eventuali note di compatibilità, come l'installazione dei plugin CNI necessari per la rete privata dei container di build.

Se non puoi aggiornare subito, applica le mitigazioni della sezione seguente e pianifica l'upgrade con la massima priorità.

Cosa fare subito: mitigazioni e hardening

In ordine di priorità, finché non hai completato l'aggiornamento:

1. Blocca le build non fidate: sospendi la possibilità di sottomettere build di immagini per gli utenti non verificati. È il vettore diretto della vulnerabilità.
2. Riduci i privilegi del service account del worker: applica il principio del minimo privilegio ai permessi RBAC del service account associato ai pod worker, così da limitare il danno in caso di fuga del token.
3. Segmenta e isola: separa i nodi che eseguono i worker di build dal resto del cluster e dai carichi critici. Limita l'accesso di rete in uscita dai pod di build.
4. Ruota le credenziali: se sospetti esposizione del token del service account, ruota il token e le credenziali raggiungibili dal nodo.
5. Monitora: aumenta la verbosità dell'audit log di Kubernetes e dei log del worker per cogliere subito un uso anomalo del token o scritture inattese.

Se sospetti una compromissione: incident response e analisi forense

Se trovi segni di sfruttamento, non spegnere i nodi coinvolti: perderesti la memoria volatile e indizi preziosi. La procedura corretta preserva le prove.

• Isola il nodo dalla rete mantenendolo acceso, dove possibile.
• Preserva i log del worker, l'audit log di Kubernetes e lo stato dei pod prima di qualsiasi riavvio.
• Acquisisci una copia forense dei volumi e, se fattibile, della memoria dei nodi coinvolti.
• Ruota tutti i token e le credenziali potenzialmente esposti e ricostruisci i nodi da immagini pulite.
• Valuta gli obblighi di notifica previsti dal GDPR in caso di violazione di dati personali.

Gestisco attività di incident response e analisi forense su ambienti Linux e Kubernetes, con acquisizione delle prove secondo criteri difendibili. Se hai un dubbio, puoi anche leggere come eseguiamo una copia forense in modo verificabile.

Fonti ufficiali

• Repository ufficiale beam-cloud/beta9
• Commit della correzione
• Pull request #1897
• Release worker-0.1.756

Domande frequenti

CVE-2026-120306 è sfruttata attivamente?

Al momento non risulta nel catalogo CISA KEV uno sfruttamento attivo. Dato il punteggio 9.9 e i bassi privilegi richiesti, va comunque trattata come priorità alta. Verifica l'advisory ufficiale per aggiornamenti.

Quale versione risolve il problema?

La correzione è nel worker 0.1.756, dove i passaggi RUN di Buildah usano isolamento OCI con namespace PID, IPC e network privati. Aggiorna l'immagine del worker e riavvia i pod.

Sono vulnerabile se non permetto build a utenti esterni?

Il vettore richiede un tenant con token di workspace capace di sottomettere una build. Se le build sono solo interne e fidate il rischio immediato è minore, ma l'aggiornamento resta consigliato e la riduzione dei privilegi del service account va fatta comunque.

Come verifico i permessi del service account del worker?

Con kubectl auth can-i --list --as=system:serviceaccount:NAMESPACE:SA ottieni l'elenco delle azioni consentite. Se sono ampie, limitale: in caso di fuga del token riduci drasticamente l'impatto sul cluster.

Se gestisci Beta9 o un cluster Kubernetes e vuoi un controllo indipendente sull'esposizione, sulla configurazione RBAC e sull'hardening dei nodi, puoi scrivermi dalla pagina contatti o chiedere un preventivo gratuito con risposta entro 24 ore.