Privilege escalation nel kernel Linux: 3 falle nella KEV, 4 exploit root pubblici

In una sola settimana di settembre 2026 il kernel Linux ha prodotto due cose insieme: tre bug di privilege escalation che CISA ora elenca come sfruttati in the wild, e quattro proof-of-concept root pubblicati con codice funzionante. La scadenza federale di remediation per i primi tre è oggi. I secondi quattro sono su GitHub in questo momento. È la parte di un'intrusione che nessuno pubblicizza e da cui tutti dipendono — il passo tra "ho una shell" e "possiedo la macchina" — e appena diventata molto più economica.

Due eventi di privilege escalation nel kernel Linux si sono scontrati questa settimana

Il giorno dell'aggiornamento KEV, CISA ha aggiunto tre falle del kernel al catalogo Known Exploited Vulnerabilities fissando per le agenzie federali (FCEB) una scadenza di remediation al 21 settembre 2026 ai sensi della Binding Operational Directive 26-04, la direttiva basata sul rischio che a giugno ha sostituito la vecchia regola KEV forfettaria a 14 giorni. Red Hat ha aggiornato i propri advisory nella stessa settimana riconoscendo la presenza di exploit pubblici e classificando i problemi come ad alto rischio (The Hacker News):

• CVE-2025-39682 (CVSS 9.8) — un controllo improprio nel percorso di ricezione TLS del kernel, che può causare fuga di memoria o crash della macchina per un utente locale autenticato.
• CVE-2026-53266 (CVSS 8.8) — una scrittura fuori dai limiti nel percorso di riscrittura ARP SNAT di ebtables, portabile fino alla privilege escalation locale.
• CVE-2025-39964 (CVSS 7.8) — una race condition su scritture concorrenti a un socket AF_ALG che corrompe le operazioni crittografiche o manda in crash la macchina.

Guardate la forma della lista. Nessuna di queste è una falla remota, non autenticata, del tipo "clicca-un-link". Tutte e tre presumono che l'attaccante sia già sulla macchina come utente non privilegiato. Ed è proprio per questo che sono rimaste senza patch abbastanza a lungo da essere sfruttate: un 7.8 con "locale" nel vettore perde ogni battaglia di prioritizzazione contro il 9.8 sul perimetro — fino al momento in cui qualcuno ottiene un appoggio e diventa l'unico bug che conta.

I quattro exploit root pubblici, e lo schema che li accomuna

Tre giorni prima delle aggiunte KEV, il ricercatore Asim Manizada ha pubblicato write-up tecnici e codice exploit funzionante per altri quattro bug del kernel, ognuno un pulito percorso da utente locale a root (The Hacker News):

Nome	CVE	Sottosistema	Meccanismo	Prerequisito
DirtyAH6	CVE-2026-80844	IPsec AH6 (IPv6)	Si fida di un campo del routing header senza verificarlo	User namespace non privilegiati
TUNderflow	CVE-2026-81000	TUN/TAP	Un valore usato sia come spazio libero sia come dimensione; l'input via Open vSwitch lo fa "wrappare"	User namespace non privilegiati
PPPoEject	CVE-2026-68121	PPPoE	Use-after-free: puntatore mantenuto su un buffer che una routine di device può liberare e spostare	User namespace non privilegiati
DiagSpill	CVE-2026-74469	SCTP (sctp_diag)	Contatore endpoint a 16 bit che "wrappa" al 65.536°, ~8 MiB scritti oltre il buffer	Nessuno

Tre dei quattro condividono un prerequisito: gli user namespace non privilegiati. È la funzionalità che permette a un utente comune di creare un namespace in cui detiene CAP_NET_ADMIN e raggiunge percorsi di codice dello stack di rete — ebtables, TUN, IPsec, PPPoE — mai pensati per essere pilotati da un attaccante. Non è una superficie d'attacco nuova; il kernel perde privilegi attraverso gli user namespace almeno da CVE-2014-4014, dove un user namespace permetteva di aggirare le restrizioni di chmod. La novità è la densità: quattro exploit rifiniti in un solo rilascio, tre dei quali passano dalla stessa porta.

DiagSpill è quello per cui rizzare le antenne. Non richiede alcun privilegio speciale — una lettura diagnostica SCTP che qualsiasi processo locale può innescare, con un contatore a 16 bit che "wrappa" e spalma circa 8 MiB oltre un buffer di heap. Su un host in cui avete disabilitato gli user namespace come misura di hardening, DiagSpill funziona ancora.

Perché "locale" è la parola più sottovalutata di un vettore CVSS

I framework di prioritizzazione sono costruiti per muovere prima il bug di perimetro, e giustamente — un RCE pre-auth è una mattinata peggiore di una race condition locale. Ma la contabilità presume in silenzio che il passo locale sia la parte difficile. Non lo è. In un'intrusione reale l'attaccante arriva con un appoggio per definizione: un RCE su web app lo ha calato in un service account, un token trapelato lo ha portato su un jump host, un container malevolo è evaso di un livello. Da lì, il bug di privilege escalation locale non è una nota a piè di pagina a bassa severità. È la differenza tra un incidente contenuto e la compromissione dell'intero dominio.

"È solo locale, ci arriviamo il prossimo ciclo." L'attaccante che stamattina ha phishato il vostro build agent non si cura che il bug del kernel sia locale. Locale è dove si trova già. Il 7.8 che avete rimandato è il 10 che gli serviva.

MITRE ATT&CK cataloga tutto questo sotto T1068 — Exploitation for Privilege Escalation, ed è una delle tecniche più affidabilmente presenti nelle analisi forensi post-breccia, proprio perché ogni intrusione che parte non privilegiata ne ha bisogno. Pubblicare sette LPE del kernel utilizzabili in una settimana non crea una nuova classe di rischio; abbatte il costo di un passo che gli attaccanti stavano già compiendo.

Remediation

Un runbook completo per le sette falle sopra. Il terzetto KEV e i quattro exploit pubblici si sovrappongono nella strategia di fix ma differiscono nell'esposizione, quindi trattateli insieme.

1. Sono vulnerabile?

Verificate il kernel in esecuzione e se gli user namespace non privilegiati sono abilitati — il segnale di esposizione più utile qui, dato che governa tre dei quattro exploit pubblici:

uname -r                                   # kernel in esecuzione
sysctl kernel.unprivileged_userns_clone    # knob Debian/Ubuntu (1 = esposto)
sysctl user.max_user_namespaces            # >0 = userns disponibili agli utenti
cat /proc/sys/kernel/unprivileged_bpf_disabled
# Stato CVE per distro (RHEL/derivate):
rpm -q --changelog kernel | grep -iE 'CVE-2025-39682|CVE-2026-53266|CVE-2025-39964'

Se unprivileged_userns_clone è 1 (o max_user_namespaces è diverso da zero) e non avete applicato la patch, DirtyAH6, TUNderflow e PPPoEject sono raggiungibili da qualsiasi account locale. DiagSpill (SCTP) è raggiungibile a prescindere.

2. Patch — la correzione vera

Non ci sono sostituti. Applicate l'aggiornamento del kernel corrente della vostra distribuzione e riavviate — un host live-patched o aggiornato-ma-non-riavviato sta ancora eseguendo l'immagine vulnerabile:

• RHEL / derivate: dnf update kernel && reboot, poi confermate con rpm -q kernel. Seguite le errata Red Hat per ciascuna CVE (database CVE Red Hat).
• Debian / Ubuntu: apt update && apt full-upgrade, poi reboot. Le versioni corrette sono tracciate nell'Ubuntu CVE tracker.
• Host air-gapped / a lunga vita: preparate il pacchetto kernel firmato dal vendor e riavviate nella finestra di manutenzione; non rimandate oltre su host raggiungibili da Internet o multi-tenant.

3. Non potete applicare la patch subito? Controlli compensativi

Guadagnate tempo chiudendo la porta condivisa:

• Disabilitate gli user namespace non privilegiati — elimina DirtyAH6, TUNderflow e PPPoEject di netto:

  sysctl -w kernel.unprivileged_userns_clone=0     # Debian/Ubuntu
  sysctl -w user.max_user_namespaces=0             # kill ampio (rompe container/sandbox rootless)
  

  Rendetelo persistente in /etc/sysctl.d/. Testate prima — Podman rootless, le sandbox di Chromium e alcuni runner CI dipendono dagli user namespace.
• Mettete in blocklist i moduli vulnerabili che non usate — sctp (DiagSpill), pppoe, ebtables:

  printf 'install sctp /bin/true\ninstall pppoe /bin/true\n' > /etc/modprobe.d/zh-hardening.conf
  

• Limitate il raggio dell'appoggio: applicate confinamento seccomp/AppArmor/SELinux ai servizi esposti così che la compromissione di un service account non possa chiamare liberamente queste syscall.

4. Caccia alla compromissione

Non c'è IOC di rete per un exploit locale del kernel — la prova è sull'host, quindi cercatela lì. Mappatura su ATT&CK T1068 e T1611 (Escape to Host):

• Oops / warning inattesi del kernel in dmesg intorno a SCTP, ebtables, TUN o AH6 — gli exploit corrompono memoria e spesso lasciano una traccia prima di riuscire.
• Processi che hanno ottenuto uid=0 senza un parent sudo/setuid legittimo. Audit con:

  auditctl -a always,exit -F arch=b64 -S clone,unshare -F args=1  # creazione userns
  ausearch -m avc,syscall -ts recent | grep -iE 'unshare|userns|sctp'
  

• Creazione di nuovi user namespace da parte di service account che non li avevano mai usati.
• Classici post-escalation: binari setuid inattesi, nuovi moduli kernel (lsmod a confronto con una baseline nota), /etc/passwd manomesso, persistenza cron/systemd aggiunta da root.

5. Bonifica + verifica

Se trovate prove di un'escalation riuscita, considerate l'host completamente compromesso:

1. Isolate e fate l'immagine dell'host per la forense prima di modificarlo.
2. Ruotate ogni credenziale, chiave e token che ha toccato la macchina — segreti dei service account, chiavi SSH, IAM cloud, token nell'ambiente del container.
3. Ricostruite da un'immagine nota-buona, poi applicate la patch, poi riavviate. Un host root-ato non può verificare la propria pulizia — un impianto competente sopravvive alla pulizia dei file.
4. Confermate il fix sull'host ricostruito: rpm -q kernel / dpkg -l linux-image-*, stato sysctl ri-irrobustito, e rieseguite il vostro controllo appoggio-verso-root contro di esso.

Dove vi lascia tutto questo, e dove si inserisce Zero Hunt

Il problema onesto che questa settimana mette a nudo non è una singola CVE — è che il passo di escalation locale è sistematicamente sotto-testato. Gli scanner segnalano il bug di perimetro e classificano il 7.8 "locale" come bassa priorità. Nessuno dimostra se, sul vostro build del kernel e con il vostro confinamento dei servizi, un appoggio realistico si concateni davvero fino a root.

Quella dimostrazione è ciò che il pentest generativo con AI di Zero Hunt è costruito per produrre. Lo swarm di 10 agenti non si ferma a "esiste una LPE locale del kernel". Gli agenti Post-Exploit e Pivot prendono un appoggio realistico a bassi privilegi — una compromissione di web app, un'evasione di container — ed eseguono l'escalation-verso-root e il movimento laterale end-to-end contro i vostri host reali, scrivendo un exploit per-target con un LLM locale invece di scaricare PoC pubblici, con ogni skill ri-testata nell'AI Gym prima di toccare la produzione e ogni finding firmato ECDSA in un registro con catena di custodia. L'output non è una riga 7.8 rimandata; è "questo appoggio ha raggiunto root su questo host, ecco il percorso". E quando l'escalation gira, il furto di credenziali e il fan-out laterale che la seguono sono esattamente ciò che il modello di AI Traffic Analysis legge sul filo — mentre accade, non nella revisione dei log di domani.

Il CVSS può dare un punteggio a un bug isolato. Non può dirvi se il passo locale — quello da cui dipende ogni intrusione reale — è raggiungibile nel vostro ambiente. È una domanda a cui si risponde solo eseguendo la catena. Parlatene con noi prima che escano i prossimi quattro exploit.