DirtyClone (CVE-2026-43503): una variante residua riapre la falla del kernel Linux e dà root nel multi-tenant

JFrog ha pubblicato il primo exploit funzionante per CVE-2026-43503 , una variante della famiglia DirtyFrag che i ricercatori hanno battezzato DirtyClone. La falla consente a un utente locale non privilegiato di ottenere root riscrivendo in memoria un binario fidato, senza lasciare tracce su disco né nei log del kernel. Il bersaglio principale non è il desktop, ma gli ambienti dove molti tenant condividono lo stesso kernel: cloud, cluster Kubernetes, container.

Cosa è successo

Durante un audit delle patch recenti del kernel Linux, il team di JFrog Security Research ha individuato che le correzioni applicate alla famiglia DirtyFrag avevano lasciato scoperto un percorso di elaborazione dei pacchetti nel sottosistema XFRM/IPsec. La stessa classe di vulnerabilità sopravviveva quindi attraverso una funzione diversa, __pskb_copy_fclone . JFrog ha segnalato il problema ai manutentori il 19 maggio, a ridosso di una segnalazione più ampia del ricercatore Hyunwoo Kim del 16 maggio. La patch è stata fusa nel ramo mainline il 21 maggio, l’identificativo CVE-2026-43503 è stato pubblicato il 23 maggio e il primo tag corretto, v7.1-rc5 , è uscito il 24 maggio (la pagina JFrog riporta date e commit non del tutto coerenti tra introduzione e timeline: si segue qui la timeline datata, più affidabile).

Al momento della pubblicazione del report non esisteva alcun proof of concept pubblico. JFrog precisa di averne sviluppato uno per dimostrare che la primitiva di attacco non è confinata a un singolo punto del codice, ma attraversa più percorsi di gestione dei socket buffer ( skb ). È bene circoscrivere il dato di novità: si tratta del primo exploit pubblico per questa specifica variante, non per l’intera famiglia DirtyFrag, già nota e in parte corretta dai CVE precedenti.

Come funziona, in breve

Il meccanismo sfrutta una sovrapposizione che il kernel non separa rigidamente: la stessa pagina fisica di memoria usata sia come page cache di un file sia come buffer di rete. L’attaccante mappa un binario privilegiato, tipicamente /usr/bin/su , portandolo nella page cache; con vmsplice e splice aggancia quella memoria a un pacchetto IPsec invece di copiarla; forza l’elaborazione locale del pacchetto su un tunnel di loopback. Quando il pacchetto clonato raggiunge la fase di decifratura ESP, il kernel scrive in place il risultato direttamente nella pagina ancora legata al file. Controllando chiave, IV e struttura del pacchetto in AES-CBC, l’attaccante trasforma la decifratura in una primitiva di scrittura mirata e patcha pochi byte della logica di autenticazione di su . Il file su disco resta intatto, ma la copia in memoria è modificata: alla successiva esecuzione, su consegna root .

La radice tecnica è un flag di sicurezza, SKBFL_SHARED_FRAG , che durante la clonazione del pacchetto non viene preservato. Quel flag dovrebbe imporre una copia prima della decifratura in place (una Copy-on-Write difensiva); la sua assenza sul pacchetto clonato è l’intera vulnerabilità. Va sottolineato che non si tratta di sostituzione o sideloading di binari, né di tecniche living-off-the-land: il binario fidato non viene rimpiazzato, viene riscritto nella sola page cache.

Perché è una notizia trasversale

L’impatto non sta nella sofisticazione, ma nel perimetro. JFrog assegna alla falla un punteggio CVSS base di 8.8 (high); l’incrocio con i tracker delle distribuzioni è già parzialmente avvenuto e mostra una sfumatura utile: Ubuntu classifica la priorità come Medium, pur a fronte di quel CVSS 8.8, segno che la valutazione del rischio reale dipende dalla configurazione più che dal solo punteggio. La condizione di sfruttabilità è la capacità CAP_NET_ADMIN , frequentemente ottenibile tramite gli unprivileged user namespace. È esattamente la configurazione diffusa negli ambienti multi-tenant: secondo l’analisi, il rischio più alto riguarda cloud condiviso, cluster Kubernetes e carichi containerizzati dove i namespace utente sono abilitati o dove girano container privilegiati. Ubuntu indica esplicitamente la possibile evasione dal container; JFrog evidenzia il rischio elevato nei container privilegiati e negli ambienti multi-tenant. In un cluster, questo sposta l’incidente da locale a strutturale.

In questi contesti la distanza tra accesso a una shell limitata e compromissione dell’intero nodo è un argomento di governance prima che di patch. Vale per chi mette in sicurezza un cluster, dove la superficie d’attacco è autoinflitta dalle scelte di configurazione, e per chi tratta la privilege escalation su Linux come requisito di conformità, non come esercizio offensivo. Una falla silenziosa, che bypassa il monitoraggio di integrità su disco, alza l’asticella del rilevamento: niente log del kernel, nessuna traccia di audit, nessuna modifica al file persistente.

Cosa fare

La protezione completa, avverte JFrog, si ottiene solo applicando l’intera catena di patch della famiglia: i sistemi corretti per le falle originarie ma privi delle correzioni successive restano esposti a bypass specifici. In concreto la catena comprende i due CVE originari ( CVE-2026-43284 e CVE-2026-43500 ) e i follow-up ( CVE-2026-46300 e CVE-2026-43503 ). La raccomandazione operativa è aggiornare il kernel alla versione corretta ( v7.1-rc5 o la backport della distribuzione). Dove la patch immediata non è possibile, l’advisory indica due workaround: bloccare l’acquisizione di CAP_NET_ADMIN impostando kernel.unprivileged_userns_clone=0 , oppure inserire in blacklist i moduli esp4 , esp6 e rxrpc , che forniscono le primitive di decifratura in place abusate. Quest’ultima opzione ha un costo operativo da pesare: disabilita IPsec e il supporto AFS/RxRPC, e per molti ambienti di produzione non è praticabile. Verificare lo stato di esposizione su Ubuntu e Debian è il primo passaggio di triage per chi gestisce flotte eterogenee.

Una nota di nomenclatura per evitare confusione: aprendo i tracker delle distribuzioni il lettore non troverà sempre il nome DirtyClone. Ubuntu, per esempio, etichetta CVE-2026-43503 come Fragnesia. È un disallineamento reale, perché JFrog riserva il nome Fragnesia a un CVE diverso ( CVE-2026-46300 , divulgato il 13 maggio, con il flag perso durante skb_try_coalesce ). I due termini, in questo contesto, indicano lo stesso CVE-2026-43503 osservato da prospettive diverse.