Si chiama Fragnesia e porta con sé un messaggio inequivocabile: il kernel Linux sta attraversando una delle fasi più complesse della sua storia recente sul fronte della sicurezza.
A meno di una settimana dalla divulgazione di Dirty Frag e a poco più di due settimane da Copy Fail, il ricercatore William Bowling del team V12 Security ha pubblicato una terza vulnerabilità critica di tipo Local Privilege Escalation (LPE) nello stesso sottosistema del kernel, tracciata come CVE-2026-46300 con un punteggio CVSS di 7.8.
La notizia è rimbalzata immediatamente su tutte le principali piattaforme di threat intelligence e ha già generato advisory ufficiali da parte di Red Hat, Ubuntu, Debian, SUSE e Amazon Linux, tra gli altri. Il motivo dell’allarme è semplice: il proof-of-concept (PoC) funzionante è stato rilasciato pubblicamente su GitHub contestualmente alla divulgazione, senza alcuna finestra di embargo.
Indice degli argomenti
Cos’è Fragnesia e come funziona
Per capire Fragnesia bisogna partire da un concetto fondamentale: la page cache del kernel Linux. Si tratta di un’area di memoria RAM in cui il sistema operativo mantiene temporaneamente il contenuto dei file letti dal disco, per accelerarne l’accesso successivo.
File di sistema critici (come /usr/bin/su, il binario che gestisce il cambio utente con elevazione dei privilegi) vengono caricati in questa cache e, normalmente, non possono essere modificati da processi non privilegiati.
Fragnesia aggira questa protezione sfruttando un bug logico nel sottosistema XFRM ESP-in-TCP del kernel, responsabile della gestione del traffico IPsec incapsulato su connessioni TCP.
Il difetto si annida in una funzione specifica, skb_try_coalesce(), che gestisce il riassemblaggio dei frammenti di pacchetto nei socket buffer. Quando questa funzione trasferisce frammenti di pagina tra buffer, non propaga correttamente il marcatore SKBFL_SHARED_FRAG: di conseguenza, il kernel “dimentica” che quei frammenti sono in realtà pagine della page cache.
A quel punto, il percorso di ricezione ESP-in-TCP esegue la decrittazione AES-GCM direttamente sulle pagine della cache del file, modificandone il contenuto in memoria. Controllando il valore del nonce (il parametro IV usato dall’algoritmo di cifratura), un attaccante non privilegiato riesce a trasformare questa operazione in una scrittura arbitraria byte-per-byte sulla copia in-memoria di qualunque file leggibile dal sistema.
Il PoC pubblico dimostra l’exploit nella sua forma più diretta: viene scritto uno stub ELF da 192 byte nella copia in page cache di /usr/bin/su e alla prima successiva invocazione del comando viene eseguito codice arbitrario con privilegi di root. Nessuna race condition richiesta. Nessun privilegio iniziale necessario.
La famiglia Dirty Frag: tre vulnerabilità in tre settimane
Per comprendere la portata dell’evento, è necessario inquadrare Fragnesia nel contesto della serie di vulnerabilità che l’ha preceduta:
- Copy Fail (CVE-2026-31431), divulgata il 29 aprile 2026, prima LPE della serie basata sulla corruzione della page cache.
- Dirty Frag (CVE-2026-43284 + CVE-2026-43500), divulgata il 7 maggio 2026, sfrutta la combinazione di due flaw nel sottosistema xfrm-ESP e RxRPC.
- Fragnesia (CVE-2026-46300), divulgata il 13 maggio 2026, terza variante della stessa famiglia, bug logico indipendente nello stesso subsystem.
Ciò che rende il caso ancora più significativo dal punto di vista della ricerca è che la patch di Dirty Frag ha contribuito a rendere praticamente sfruttabile Fragnesia. La correzione del problema precedente ha esposto una violazione di invariante latente nel codice, che Bowling e il team V12 hanno identificato e trasformato in un nuovo exploit autonomo.
Un dato ulteriore, menzionato dallo stesso team V12, riguarda il metodo di ricerca: parte del processo di scoperta è stato assistito da strumenti di sicurezza basati su AI agentici. Indipendentemente dal peso che si voglia attribuire a questa affermazione, la velocità con cui vengono prodotti exploit affidabili e funzionanti nello stesso codice path è un segnale che i team di difesa devono prendere molto sul serio.
Vulnerabilità Fragnesia: le distribuzioni colpite
Fragnesia riguarda tutti i kernel Linux rilasciati prima del 13 maggio 2026. L’exploit pubblico è stato confermato su kernel Ubuntu 6.8.0-111-generic, ma la vulnerabilità interessa tutte le major distribution. I vendor che hanno già rilasciato advisory ufficiali includono:
Red Hat ha comunicato di essere in fase di valutazione per verificare se le mitigazioni esistenti per Dirty Frag si estendono anche a CVE-2026-46300. Microsoft, a sua volta, ha esortato le organizzazioni ad applicare le patch il prima possibile, e in assenza di patch a seguire le stesse mitigazioni di Dirty Frag.
Come difendersi: patch e mitigazioni immediate
Per difendersi da un eventuale attacco informatico che sfrutta la vulnerabilità Fragnesia è possibile applicare le patch già disponibili.
Qualora ciò non fosse possibile, ecco alcune utili azioni di mitigazione immediata.
Aggiornare il kernel (azione prioritaria)
La prima e più importante azione da intraprendere è aggiornare il kernel all’ultima versione disponibile per la propria distribuzione. AlmaLinux, CloudLinux e le altre distribuzioni già citate stanno rilasciando kernel patchati in modalità accelerata. Chi utilizza soluzioni di live patching come KernelCare riceverà la patch automaticamente senza necessità di riavvio.
I comandi bash per aggiornare il kernel Linux sulle diverse distribuzioni sono i seguenti:
Su Debian/Ubuntu: “sudo apt update && sudo apt upgrade“.
Su Red Hat Enterprise Linux, AlmaLinux e Rocky Linux: “sudo dnf update kernel“.
Su SUSE: “sudo zypper update kernel-default“.
Mitigazione temporanea: disabilitare i moduli ESP
Per i sistemi che non possono essere patchati immediatamente, la mitigazione raccomandata da tutti i vendor è disabilitare i moduli esp4, esp6 e rxrpc applicando i seguenti comandi bash:
Blacklist immediata (senza riavvio):
echo “install esp4 /bin/false” | sudo tee /etc/modprobe.d/fragnesia-mitigate.conf
echo “install esp6 /bin/false” | sudo tee -a /etc/modprobe.d/fragnesia-mitigate.conf
echo “install rxrpc /bin/false” | sudo tee -a /etc/modprobe.d/fragnesia-mitigate.conf
Rimozione immediata dei moduli (se già caricati):
sudo modprobe -r esp4 esp6 rxrpc
Importante sottolineare, però, che questa mitigazione interrompe il funzionamento dei tunnel IPsec (strongSwan, Libreswan) e dei client AFS basati su rxrpc. Non bisogna dunque applicarla su host che fanno terminazione di traffico IPsec in produzione senza aver prima verificato l’impatto.
Svuotare la page cache (se si sospetta un’esposizione pregressa)
Se esiste il rischio che un sistema possa essere stato compromesso prima dell’applicazione della mitigazione, è opportuno forzare il rilascio della page cache con il seguente comando bash per scaricare eventuali pagine alterate:
sync && echo 3 | sudo tee /proc/sys/vm/drop_caches
Questa operazione è sicura su sistemi live e non intacca i file su disco, ma solo le copie in memoria.
Restrizione degli user namespace non privilegiati
Wiz ha osservato che le restrizioni AppArmor sugli user namespace non privilegiati (abilitate di default su Ubuntu) agiscono come mitigazione parziale, richiedendo bypass aggiuntivi per lo sfruttamento dell’exploit pubblico. Su distribuzioni che non le abilitano di default, è opportuno valutarne l’attivazione usando i seguenti comandi bash:
# Ubuntu/Debian: verifica stato
cat /proc/sys/kernel/unprivileged_userns_clone
# Per disabilitare gli unprivileged user namespaces
echo 0 | sudo tee /proc/sys/kernel/unprivileged_userns_clone
Limitare l’accesso locale alle shell
Fragnesia, come tutte le vulnerabilità di tipo LPE, richiede l’accesso locale al sistema. Limitare il numero di utenti con accesso shell interattivo, consolidare le politiche di autenticazione e rivedere i permessi di accesso SSH, sono tutte misure di hardening strutturali che riducono la superficie di attacco.
Analisi del rischio: cosa significa per le organizzazioni
Ciò che più preoccupa di questa serie di vulnerabilità non è tanto il singolo bug, per quanto grave, quanto il pattern sistemico che si sta delineando.
Fragnesia: il problema non è solo tecnico
Tre LPE critiche nello stesso sottosistema del kernel in meno di tre settimane non sono un caso. Indicano che il codice path XFRM/ESP/page-cache contiene invarianti di sicurezza non adeguatamente documentate e che i processi di review del kernel non hanno intercettato queste violazioni in anni di storia del codice (il bug di Fragnesia riporta un Fixes: a un commit del 2013).
È lecito aspettarsi ulteriori scoperte nella stessa area nelle prossime settimane.
La finestra di esposizione è il vero rischio
Fragnesia è stata divulgata con PoC pubblico e senza embargo. Questo significa che dalla divulgazione in poi, qualsiasi attaccante con accesso locale a un sistema vulnerabile può diventare root.
La domanda che ogni CISO e responsabile IT deve porsi è: quanti sistemi Linux abbiamo con accesso shell per utenti non fidati o con accesso remoto non adeguatamente segregato? Ambienti multi-tenant, sistemi di sviluppo condivisi, server con accesso SSH per team esterni sono tutti scenari ad alto rischio.
Prioritizzazione basata sul contesto
Non tutti i sistemi Linux sono ugualmente esposti. Un server web con utente applicativo isolato in un container senza shell interattiva ha un profilo di rischio molto diverso da un server di sviluppo condiviso o da un sistema di build CI/CD accessibile a più team.
La prioritizzazione delle patch deve tener conto di:
- Accessibilità del sistema: chi ha accesso shell locale o remoto?
- Presenza di user namespace non privilegiati: la funzionalità è abilitata?
- Utilizzo di IPsec: la mitigazione temporanea è applicabile?
- Criticità dei dati: il sistema tratta dati sensibili, personali o regolamentati?
La minaccia del mercato degli zero-day
Come segnalato da ThreatMon, nelle stesse ore della divulgazione di Fragnesia, il threat actor “berz0k” ha pubblicizzato su forum criminali un exploit LPE per Linux a 170.000 dollari, non correlato alle vulnerabilità note.
Il mercato degli exploit zero-day per Linux è in crescita. Le organizzazioni devono considerare che la finestra tra discovery privata e sfruttamento attivo si sta accorciando drammaticamente, anche grazie all’uso dell’AI nella ricerca di vulnerabilità.
Conclusioni
Fragnesia non è una vulnerabilità isolata: è il terzo capitolo di una storia che sta ridisegnando il panorama della sicurezza del kernel Linux.
La risposta dei vendor è stata rapida e coordinata e questo è un segnale positivo. Ma la velocità con cui vengono prodotti nuovi exploit nella stessa area di codice suggerisce che i team di sicurezza devono prepararsi a un ciclo di patching accelerato ancora per alcune settimane.
Il messaggio operativo è chiaro: patchare immediatamente dove possibile, applicare le mitigazioni temporanee dove non è possibile e rivedere le politiche di accesso locale ai sistemi Linux aziendali.
La scoperta della vulnerabilità Fragnesia non è un’emergenza da gestire in silenzio: è un’occasione per consolidare le pratiche di vulnerability management e dimostrare ai board, agli auditor e ai clienti che la propria organizzazione reagisce in modo strutturato alle minacce di livello critico.
