Linux kernel, tre falle sono sfruttate e quattro nuovi exploit portano a root

🛡️ Executive Summary

• CISA inserisce tre vulnerabilità del kernel Linux nel KEV dopo evidenze di exploitation attiva, ma non pubblica dettagli sulle campagne.
• Asim Manizada rilascia separatamente quattro exploit locali funzionanti per DirtyAH6, TUNderflow, PPPoEject e DiagSpill.
• I due gruppi di CVE non coincidono: tre sono già sfruttate, quattro hanno PoC pubblici ma nessuna exploitation reale confermata.

Il kernel Linux entra in una finestra di rischio particolarmente delicata: CISA ha inserito tre vulnerabilità nel catalogo KEV dopo aver ricevuto evidenze di sfruttamento attivo, mentre quasi contemporaneamente il ricercatore Asim Viladi Oglu Manizada ha pubblicato exploit funzionanti per altre quattro falle capaci di trasformare un accesso locale limitato in una shell root. I due eventi non devono essere confusi. CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964 risultano sfruttate in attacchi reali, ma il meccanismo operativo rimane pubblico solo in parte. DirtyAH6, TUNderflow, PPPoEject e DiagSpill, invece, dispongono ora di codice exploit pubblico ma non risultano utilizzate in campagne reali. Per i sysadmin la conseguenza è la stessa: basarsi sul solo CVSS non basta più.

CISA conferma tre vulnerabilità Linux sfruttate senza rivelare la catena

Il 18 settembre 2026 CISA ha pubblicato due alert separati che portano tre falle del kernel nel Known Exploited Vulnerabilities Catalog. Il primo alert CISA riguarda CVE-2025-39682, problema nel percorso TLS del kernel relativo alla gestione di record a lunghezza zero. Il secondo alert aggiunge CVE-2025-39964 e CVE-2026-53266, rispettivamente una race condition nel sottosistema crittografico AF_ALG e una scrittura fuori limite nella gestione ebtables SNAT durante la riscrittura degli indirizzi ARP. In tutti e tre i casi CISA afferma di possedere evidenze di active exploitation, ma non indica threat actor, malware, target, catena iniziale né modalità con cui gli attaccanti raggiungono il contesto locale necessario.

CVE-2025-39682 Linux Kernel Improper Check for Unusual or Exceptional Conditions Vulnerability

La distinzione è importante perché queste vulnerabilità non equivalgono automaticamente a tre RCE Internet-facing. Per CVE-2026-53266, ad esempio, Red Hat descrive il requisito di specifiche regole ebtables SNAT e indica come possibili conseguenze corruzione della memoria, denial of service ed escalation dei privilegi. Il valore operativo nasce quindi dalla combinazione tra accesso già ottenuto, configurazione del sistema e primitive disponibili nel kernel. È un modello già osservato quando CISA aveva confermato lo sfruttamento di una falla IPv6 Linux capace di facilitare l’uscita da container verso l’host.

Leggi anche: Bad Epoll porta un processo locale fino a root attraverso una race condition nel kernel Linux

DirtyAH6 e altre tre falle hanno ora exploit pubblici per ottenere root

Nelle stesse ore è arrivato un secondo sviluppo, tecnicamente indipendente. Asim Manizada ha pubblicato il write-up originale dedicato a quattro nuove local privilege escalation insieme agli exploit dopo la scadenza dell’embargo coordinato con le distribuzioni Linux. Le vulnerabilità sono DirtyAH6 (CVE-2026-80844), TUNderflow (CVE-2026-81000), PPPoEject (CVE-2026-68121) e DiagSpill (CVE-2026-74469). I difetti risiedono in quattro aree differenti dello stack networking: IPv6 IPsec AH, dispositivi TUN/TAP, PPPoE e diagnostica SCTP. Tutte consentono al ricercatore di ottenere root locale, ma i prerequisiti cambiano. Le prime tre richiedono normalmente unprivileged user namespaces oppure capability equivalenti, condizione rilevante perché numerose distribuzioni permettono ai processi non privilegiati di creare namespace. DiagSpill è differente: non richiede user namespace se il modulo SCTP interessato è disponibile. La ricerca arriva dopo OVSwrap, altra escalation locale scoperta da Manizada e già analizzata nel contesto dell’aggiornamento Tails e della vulnerabilità Open vSwitch capace di ottenere root.

Quattro bug vecchi fino a 21 anni diventano primitive moderne di escalation

La parte più rilevante non è il numero delle CVE, ma la natura dei difetti. DirtyAH6 manipola in modo errato informazioni dell’IPv6 Authentication Header e può produrre una scrittura fuori limite. TUNderflow nasce da un calcolo del buffer nel percorso TUN/TAP capace di andare in overflow quando viene fornito un headroom anomalo. PPPoEject conserva invece un puntatore verso un buffer che può essere spostato o liberato durante l’elaborazione dell’header, creando una use-after-free. DiagSpill sfrutta infine l’overflow di un contatore a 16 bit nella diagnostica SCTP: raggiunti 65.536 endpoint, il contatore torna a zero e il kernel può copiare circa 8 MiB oltre il buffer allocato. Secondo la disclosure inviata da Manizada alla mailing list oss-security, questi bug sono rimasti nel kernel per periodi compresi tra 10 e 21 anni. Le prime release stabili upstream che incorporano tutte e quattro le correzioni sono 5.10.270, 5.15.221, 6.1.188, 6.6.157, 6.12.109, 6.18.50 e 7.2.4. Per le distribuzioni, però, il numero di versione non basta: Debian, Ubuntu, Red Hat, SUSE e altri vendor possono applicare backport mantenendo il ramo kernel esistente. È lo stesso principio già evidente negli aggiornamenti Debian contro Zapscape e SCTPhantom, dove la verifica dell’advisory della distribuzione conta più del confronto meccanico con la mainline.

Exploit pubblico non significa sfruttamento attivo e KEV non significa attacco remoto

La sovrapposizione temporale dei due dossier crea un rischio di lettura errata. Le quattro vulnerabilità di Manizada non sono le tre aggiunte da CISA al KEV. Non risultano evidenze pubbliche che DirtyAH6, TUNderflow, PPPoEject o DiagSpill siano state utilizzate in attacchi reali. Al contrario, CISA afferma che le altre tre CVE sono già sfruttate, ma non pubblica exploit, IoC o una ricostruzione delle intrusioni. Anche la parola “locale” richiede cautela. DirtyAH6 e DiagSpill possono essere raggiunte via rete in configurazioni molto specifiche, ma Manizada descrive la possibilità di ottenere remote root con DirtyAH6 come teoricamente possibile e molto difficile da rendere affidabile. Per DiagSpill non identifica invece un percorso realistico verso root remoto. Il problema dominante resta quindi la post-exploitation: un attaccante che abbia già compromesso un servizio, un container o un account a privilegi ridotti può utilizzare una LPE per prendere il controllo completo dell’host. La ricerca recente sta inoltre rendendo queste primitive più facili da individuare. Google Project Zero ha appena pubblicato MAccConc, toolkit progettato per rendere riproducibili interleaving e race condition nel kernel, mentre Manizada dichiara di aver utilizzato un processo AI-assisted per modellare oggetti e stato della memoria durante la ricerca delle quattro vulnerabilità.

Continua con:

RefluXFS e snap-confine trasformano vulnerabilità locali Linux in escalation fino a root

WordPress, Linux e AWS: SCTPhantom mostra il rischio delle vecchie primitive nel kernel

Patch prima del CVSS e user namespace come superficie da rivalutare

Per gli amministratori la priorità è verificare gli advisory della propria distribuzione per tutte e sette le CVE, senza assumere che un kernel apparentemente vecchio sia vulnerabile o che uno recente sia necessariamente corretto. Le tre vulnerabilità inserite nel KEV devono essere trattate come problemi con exploitation già documentata da CISA; le quattro di Manizada richiedono invece urgenza perché il codice exploit è pubblico e il percorso verso root è stato dimostrato. Dove l’aggiornamento immediato non è possibile, la riduzione della superficie può aiutare. Disabilitare gli unprivileged user namespaces rimuove il percorso ordinario verso DirtyAH6, TUNderflow e PPPoEject, mentre sistemi che non utilizzano AH6, TUN/TAP, PPPoE o SCTP possono valutare la disattivazione dei componenti non necessari. Sono mitigazioni, non sostituti della patch. La settimana Linux mostra soprattutto che il rischio kernel non può più essere ordinato semplicemente dal numero CVSS: exploitation reale, disponibilità di exploit, prerequisiti locali e possibilità di attraversare container o trust boundary determinano quale falla debba essere corretta per prima.