Una vulnerabilità rimasta nascosta per diciotto anni nel cuore di Linux è stata resa pubblica il 6 agosto. Si chiama SCTPhantom, è tracciata come CVE-2026-64564 ed è un use-after-free nel codice SCTP del kernel: un utente locale può sfruttarla per ottenere i privilegi di root sulla macchina e, secondo chi l'ha scoperta, per evadere da un container e raggiungere il sistema host sottostante. Il bug è stato introdotto con Linux 2.6.25 nel 2008 ed è quindi presente in praticamente ogni kernel rilasciato da allora.

I fatti

SCTP (Stream Control Transmission Protocol) è un protocollo di trasporto — alternativo a TCP e UDP — che permette a una singola connessione di viaggiare su più percorsi di rete contemporaneamente. Una sua funzione accessoria, la riconfigurazione dinamica degli indirizzi (ASCONF), consente a un peer di aggiungere o rimuovere indirizzi mentre la connessione è già attiva.

Il difetto nasce da uno scambio di identità. Il kernel verifica una richiesta di cancellazione confrontandola con l'indirizzo sorgente del pacchetto, ma poi agisce su un percorso scelto in base a un indirizzo diverso, contenuto all'interno del messaggio. Secondo l'avviso del kernel, un singolo messaggio può trasportare un indirizzo, una cancellazione per quello stesso indirizzo e infine una cancellazione con carattere jolly: quella sequenza libera il percorso e poi ne riusa il puntatore ormai morto, lasciando la connessione a puntare a memoria che il kernel ha già rilasciato. Da lì, con la tecnica giusta, si arriva all'esecuzione di codice con i privilegi del kernel.

La falla è stata individuata dal Tencent Zhuque Lab e attribuita a Corvus AI, una pipeline di ricerca multi-agente che il laboratorio ha costruito proprio per il lavoro sul kernel. È l'ennesimo caso, nel 2026, di bug dormienti da anni riemersi grazie all'assistenza dell'intelligenza artificiale, dopo GhostLock a luglio: un segnale che vale la pena registrare, perché sposta gli equilibri fra chi cerca e chi difende.

Alcuni paletti tengono il rischio sotto controllo. La vulnerabilità è locale, non remota: serve già un punto d'appoggio sulla macchina. E richiede che SCTP sia raggiungibile sul bersaglio, condizione tutt'altro che universale. Dove queste condizioni valgono, però, Tencent riferisce di aver ottenuto root sui kernel di prova per Debian 13, Ubuntu 24.04, Rocky Linux 9 e RHEL 9, e OpenCloudOS. Sull'evasione dal container il laboratorio dichiara di essere riuscito 6 volte su 8 mantenendo il profilo seccomp di default e senza concedere né CAP_NET_ADMIN né CAP_SYS_ADMIN, ma precisa anche che nessuno all'esterno ha ancora riprodotto il risultato e che accesso al socket, profili seccomp e policy sui namespace utente spostano l'esposizione. Un avviso di openKylin sullo stesso bug, ad esempio, si ferma al kernel panic e al denial of service. Anche la gravità è ancora in discussione: Tencent la valuta 8,5 secondo CVSS v4.0, mentre NVD al 7 agosto non aveva ancora assegnato né punteggio né classificazione. Al momento della divulgazione non risultava codice di exploit pubblico né una voce nel catalogo KEV della CISA.

Cosa significa per le aziende italiane

Il primo istinto — "SCTP? non lo usiamo" — è spesso corretto, ma non basta a chiudere il discorso. SCTP è un protocollo di nicchia lato applicativo, però è diffuso nelle reti degli operatori di telecomunicazioni, dove trasporta la segnalazione (SS7, Diameter) del mondo mobile, e compare in alcuni stack di telefonia e in ambienti industriali. Per un operatore TLC italiano o per un fornitore di servizi che espone SCTP, questo bug tocca infrastruttura potenzialmente critica.

Il punto più rilevante per la maggioranza delle aziende, però, è un altro: il modulo sctp può essere caricato automaticamente dal kernel quando un processo, anche non privilegiato, apre un socket SCTP. In un ambiente multi-tenant — un cluster Kubernetes, una piattaforma di container condivisa, un host che esegue codice di terze parti — questo trasforma un difetto "di nicchia" in una possibile via di escalation da tenant a host. È esattamente lo scenario che preoccupa i provider cloud e chiunque faccia girare workload non completamente fidati sulla stessa macchina.

Sul piano normativo, per i soggetti che rientrano in NIS2 la gestione tempestiva delle vulnerabilità note e l'applicazione delle patch fanno parte degli obblighi di sicurezza delle reti e dei sistemi informativi; per gli operatori del settore finanziario, DORA impone processi analoghi di gestione delle vulnerabilità e del rischio ICT. Una falla che dà root sull'host, in un contesto dove si eseguono workload di clienti, va trattata con la stessa serietà di una vulnerabilità remota, anche se "solo" locale.

Cosa fare subito

  • Aggiornare il kernel. La correzione è già stata distribuita nei kernel stabili 7.1.6, 6.18.42, 6.12.101 e 6.6.148, rilasciati il 3 agosto. Chi esegue un kernel più vecchio con SCTP raggiungibile deve aggiornare.
  • Non fidarsi della sola stringa di versione. I vendor spesso applicano le correzioni tramite backport senza cambiare la versione upstream: verificate lo stato della patch sul tracker della vostra distribuzione (Debian, Ubuntu, Red Hat, Rocky, SUSE), non solo con uname -r.
  • Attenzione a un secondo bug affine. Un ulteriore use-after-free nello stesso codice è stato corretto il 6 agosto, dopo l'uscita delle release stabili del 3 agosto: quei kernel non lo contengono, ma tenetelo presente nel valutare la copertura.
  • Dove SCTP non serve, disattivarlo. Bloccare il modulo elimina del tutto la superficie d'attacco. Su molti sistemi si può mettere il modulo in blacklist (ad esempio con una riga install sctp /bin/true in /etc/modprobe.d/) per impedirne il caricamento automatico.
  • Negli ambienti container, restringere le capability, mantenere profili seccomp restrittivi e limitare l'accesso ai socket riduce la probabilità che un tenant possa attivare e sfruttare la funzione.

Il quadro va monitorato: se dovesse emergere un exploit pubblico o comparire una voce nel catalogo KEV della CISA, la priorità di intervento andrà rialzata di conseguenza.