Il 6 agosto 2026 lo Zhuque Lab di Tencent ha pubblicato i dettagli di SCTPhantom, una vulnerabilità nel kernel Linux che permette a un utente locale senza privilegi di ottenere root, e in certe condizioni di uscire da un container e prendere il controllo dell’host. Il bug si trova nel codice SCTP, è tracciato come CVE-2026-64564 ed è presente dal 2007, da Linux 2.6.25. Dopo la disclosure privata è arrivata anche una PoC pubblica, e questo cambia parecchio la superficie di rischio reale per chi gestisce server e cluster.

Cosa sono SCTP e ASCONF in breve?

SCTP, Stream Control Transmission Protocol, è un protocollo di trasporto un po’ meno famoso di TCP e UDP ma con un’idea in più: una singola connessione (chiamata associazione) può usare più percorsi di rete contemporaneamente verso lo stesso peer, così, se uno cade, il traffico continua a passare dagli altri. È definito dalla RFC 4960 e viene usato soprattutto in ambito telecomunicazioni, ma il supporto è presente in ogni kernel Linux, compilato o come modulo, anche quando nessuno lo usa attivamente.

ASCONF è invece l’estensione che permette di cambiare a runtime gli indirizzi usati da un’associazione già attiva, aggiungendone, rimuovendone o cambiando quello primario. È descritta dalla RFC 5061. È proprio nella gestione di questi cambiamenti che si nasconde SCTPhantom.

Il bug e la strada verso la root partono da un solito problema di allocazione della memoria:

Il problema nasce da un dettaglio sottile: un messaggio ASCONF porta con sé due indirizzi diversi, quello sorgente del pacchetto e quello indicato come parametro per scegliere quale percorso rimuovere. Il kernel controlla i permessi confrontando il primo, ma poi usa il secondo per decidere quale oggetto interno (il “transport”) eliminare davvero. Con una sequenza di richieste costruita ad hoc, un utente può far credere al kernel di rimuovere un percorso già liberato in precedenza, mentre l’associazione continua a tenerne un riferimento. Il risultato è una classica use-after-free: la memoria è stata liberata, ma qualcosa continua a usarla come se esistesse ancora.

Da qui, Tencent ha costruito una catena di sfruttamento completa. La use-after-free viene prima resa “stabile” ed utilizzabile, poi la memoria liberata viene rioccupata con dati controllati usando un accorgimento di rete (un anello di trasmissione TPACKET), il che permette di leggere un indirizzo del kernel. Da quell’indirizzo si ricostruisce la posizione reale del kernel in memoria (aggirando così l’eventuale KASLR se abilitato), si ripete la stessa tecnica per costruire un intero oggetto falso al posto di uno vero, e infine si arriva a invocare la funzione interna che assegna i privilegi di root a un processo. Tutto questo riusando codice già presente nel kernel. Il risultato finale è accesso di root completo al sistema.

La parte più delicata è che la stessa catena funziona anche dentro un container, senza bisogno di capability particolari, e con il profilo seccomp di default. Nei test effettuati dai ricercatori, sei tentativi su otto sono arrivati a controllare l’host partendo da un container non privilegiato, sfruttando una funzione del kernel che avvia processi al di fuori dei namespace del container. Questo non vuol dire che ogni container sia automaticamente vulnerabile: conta se SCTP è disponibile, se il container può usare raw socket e packet socket, e quali politiche di sicurezza (namespace, seccomp, capability, SELinux o AppArmor) sono davvero attive.

Di seguito possiamo vedere come l’exploit è funzionante su diverse distribuzioni Linux:

La correzione, commit 9b2854f86f0b destinato al kernel 7.2, rifiuta la cancellazione di un percorso quando coincide con quello ancora in uso per il messaggio ASCONF corrente, ed è già stata retroportata su 6.6.148, 6.12.101, 6.18.42 e 7.1.6. Su Debian, Trixie la eredita già con il kernel 6.12.101-1, mentre Bookworm e Bullseye risultano ancora scoperte secondo il Debian Security Tracker.

Su macchine tradizionali, se SCTP non serve va disabilitato bloccando il caricamento del modulo, anche se su alcuni sistemi è compilato direttamente nel kernel. RHEL parte già prudente, con il modulo bloccato di default da RHEL 8 in poi. Ubuntu invece non lo blocca, ed è per questo che nei test di Tencent Ubuntu 24.04 si è rivelato attaccabile senza intoppi.

Scendendo un po’ più nel dettaglio sul mondo container e Kubernetes, possiamo vedere essenzialmente che per sfruttare SCTPhantom ci si basa sulla superficie raggiungibile dal singolo workload. Il seccomp di default di Docker lascia passare socket() e setsockopt(), e la capability CAP_NET_RAW resta assegnata di default: è proprio quella usata dall’exploit pubblico per rioccupare la memoria liberata, quindi toglierla chiude questa via anche senza patchare il kernel. Su Kubernetes, il Pod Security Standard “Restricted” impone di eseguire il DROP tutte le capability tranne NET_BIND_SERVICE, escludendo di fatto CAP_NET_RAW, cosa che il profilo “Baseline” non garantisce.

Per chi gestisce server o cluster Kubernetes, la priorità è quindi aggiornare i kernel a una versione corretta e, dove SCTP non è necessario, disabilitarne il supporto. In ambiente container, rimuovere CAP_NET_RAW e adottare profili seccomp e Pod Security più restrittivi permette inoltre di ridurre significativamente la superficie di attacco.