Cosa rompe davvero SCTPhantom

CVE-2026-64564 - soprannominata SCTPhantom da alcuni dei ricercatori che l'hanno seguita - è una vulnerabilità use-after-free all'interno dell'implementazione SCTP del kernel Linux, lo Stream Control Transmission Protocol usato soprattutto nella segnalazione delle telecomunicazioni, in alcuni sistemi di messaggistica finanziaria e in alcune pile di rete per container e cluster. La falla si trova precisamente in ASCONF, il codice che gestisce la Riconfigurazione Dinamica degli Indirizzi, che consente a un'associazione SCTP attiva di aggiungere o rimuovere indirizzi IP senza chiudere la connessione. Il CVE è stato annunciato ufficialmente il 4 agosto 2026, dopo un processo di divulgazione privata iniziato il 12 luglio 2026.

La causa profonda è una discrepanza d'identità: quando il kernel elabora una richiesta DEL-IP per rimuovere un indirizzo da un'associazione, valida quella richiesta usando l'indirizzo sorgente del pacchetto in arrivo, mentre un puntatore in cache separato all'interno del kernel continua a fare riferimento all'indirizzo indicato nel parametro stesso della richiesta. Un attaccante che costruisce una sequenza deliberatamente ordinata di chunk ASCONF può sfruttare quello scarto tra i due controlli per liberare una porzione di memoria del kernel mentre un puntatore attivo vi punta ancora - la definizione da manuale di una use-after-free, e uno degli strumenti più affidabili per trasformare un bug del kernel in esecuzione di codice reale.

Diciotto anni sono il titolo, non la lezione

Il codice responsabile risale a Linux 2.6.25, rilasciato nel dicembre 2007, il che colloca il bug a circa 18 anni d'età nel momento in cui lo Zhuque Lab di Tencent lo ha trovato. I ricercatori attribuiscono la scoperta a Corvus AI, una pipeline autonoma multi-agente di ricerca sulle vulnerabilità gestita internamente dal team, che ha segnalato il percorso di codice ASCONF come meritevole di una revisione manuale più approfondita. Questo dettaglio conta quasi quanto il bug stesso: non si tratta di un'area del kernel notoriamente a rischio finalmente sottoposta ad audit, ma di un angolo davvero poco frequentato che nessuno ha esaminato a fondo per quasi due decenni.

Le correzioni stabili sono arrivate il 3 agosto 2026 nei rami del kernel 6.6.148, 6.12.101, 6.18.42 e 7.1.6, e i maintainer delle distribuzioni hanno già iniziato a integrarle nei propri alberi di pacchetti. Questa è la parte della storia che ogni testata sta raccontando, ed è anche la parte che conta meno per la maggior parte dei lettori. Uno scarto di 18 anni tra il rilascio del bug e la sua scoperta dimostra che una politica di attesa della patch ha già fallito in silenzio per diciotto anni proprio su questo percorso di codice - non c'è motivo di credere che il prossimo angolo inesplorato del kernel verrà trovato più in fretta, ed è per questo che ridurre ciò che è realmente raggiungibile su una data macchina conta a prescindere da qualunque singola data di patch.

Accesso root e fuga dai container, dimostrati

Lo Zhuque Lab di Tencent ha dimostrato l'exploit dall'inizio alla fine, non solo un crash. Su sistemi con Debian 13, Ubuntu 24.04, Rocky Linux 9, RHEL 9 e OpenCloudOS, il team ha trasformato la use-after-free in un'escalation completa dei privilegi a root da un account locale non privilegiato, per poi usare la stessa tecnica per uscire da un container verso l'host in sei tentativi su otto, senza bisogno di CAP_NET_ADMIN o CAP_SYS_ADMIN, le capability elevate che la maggior parte delle guide di hardening dei container dà per scontate come primo requisito dell'attaccante.

La catena di exploit ha aggirato l'address space layout randomization del kernel, concatenato una seconda use-after-free usando chiavi di autenticazione SCTP controllate dall'attaccante, e costruito un grafo di oggetti del kernel falsificato per raggiungere root, il tutto senza shellcode né una catena return-oriented-programming, le tecniche che la maggior parte delle mitigazioni per exploit del kernel è progettata per intercettare. I test hanno coperto versioni del kernel dalla 5.14 fino alla release candidate 7.2, e la correzione upstream è arrivata come commit 9b2854f86f0b prima di essere retroportata nei quattro rami stabili citati sopra.

La correzione da una riga che quasi tutti i team saltano

La patch è reale e vale la pena applicarla, ma cura un sintomo. Quasi nessuna delle organizzazioni che eseguono queste cinque distribuzioni ha scelto di attivare SCTP: è compilato di default direttamente nel kernel mainline, e la maggior parte degli operatori non ha idea che sia presente, tanto meno che un processo locale possa raggiungerlo. Questa è la vera lezione nascosta nello stesso thread di divulgazione su oss-security dei ricercatori: un partecipante al thread ha fatto notare che i sistemi della famiglia RHEL tengono SCTP fuori per default, distribuito come pacchetto separato kernel-modules-extra con il caricamento automatico in blacklist, mentre i kernel delle famiglie Debian e Ubuntu integrano SCTP direttamente e lo lasciano caricare non appena un processo qualsiasi lo richiede. Due sistemi possono avere lo stesso identico CVE e trovarsi a un rischio reale molto diverso, e la differenza non ha nulla a che vedere con quale patch sia installata.

L'azione che vale la pena intraprendere questa settimana non è aspettare l'aggiornamento della distribuzione, ma verificare se SCTP stia facendo qualcosa di utile su una data flotta di macchine. Il comando lsmod | grep sctp mostra se il modulo è attualmente caricato; controllare /etc/modprobe.d/ alla ricerca di una voce di blacklist esistente mostra se il caricamento automatico è già bloccato. Dove nulla dipende legittimamente da SCTP - e sulla maggior parte dei server general-purpose non dipende nulla - mettere in blacklist il modulo chiude la porta a prescindere da quale versione del kernel arrivi in seguito, un'abitudine coerente con quanto l'ACN italiana (Agenzia per la Cybersicurezza Nazionale) e la maggior parte delle linee guida nazionali di hardening raccomandano già per qualsiasi modulo del kernel inutilizzato, non solo per questo.

Da leggere ora: Lo strumento RMM del tuo MSP ha un secondo bypass  |  La chiamata che aggira l'MFA della vostra azienda