Linux Copy Fail: CISA impone patch entro il 15 maggio
CISA inserisce CVE-2026-31431 nel catalogo KEV: sfruttamento attivo. Exploit Python di 732 byte per root su Linux dal 2017, zero traccia su disco.
Contenuto
Il 1° maggio 2026 CISA ha aggiunto CVE-2026-31431, soprannominata "Copy Fail", al catalogo Known Exploited Vulnerabilities, confermando che la falla di escalation di privilegi nel kernel Linux è già sfruttata in-the-wild. L’agenzia federale ha ordinato alle agenzie civili statunitensi di patchare entro il 15 maggio 2026. La gravità è estrema: uno script Python di circa 732 byte consente a un utente locale di ottenere root su praticamente ogni distribuzione Linux dal 2017, alterando il page cache in-memory senza scrivere su disco e rendendo l’attacco quasi invisibile.
- CISA ha inserito la vulnerabilità nel catalogo KEV il 1° maggio 2026 e imposto una deadline al 15 maggio per le agenzie federali civili statunitensi.
- L'exploit è uno script Python di circa 732 byte che funziona invariato su Ubuntu, Amazon Linux, RHEL e SUSE, garantendo accesso root deterministico.
- Il bug sfrutta il sottosistema crittografico algif_aead combinato con splice() e l'algoritmo authencesn per corrompere 4 byte nel page cache in-memory di file leggibili, inclusi binari setuid.
- La condivisione del page cache tra host e container espone ambienti Docker, LXC e Kubernetes a rischio di container escape, con effetto cross-container.
Come funziona la catena di corruzione del page cache
La vulnerabilità risiede nel sottosistema crittografico AF_ALG, specificatamente nell’interfaccia algif_aead dedicata alle operazioni AEAD. La combinazione con la syscall splice() e l’algoritmo authencesn consente di inserire pagine del page cache di file leggibili all’interno di una scatterlist che il sistema tratta come scrivibile. Durante la decrittazione in-place, authencesn usa il buffer destinazione come scratch space, scrivendo 4 byte oltre il confine previsto.
Questa scrittura controllata corrompe deterministicamente il page cache in-memory del file target, inclusi binari setuid in esecuzione, senza marcare le pagine come dirty. Il kernel continua quindi a eseguire il binario alterato in RAM, garantendo all’attaccante privilegi di root. Poiché il file su disco resta intatto, la compromissione scompare al riavvio, lasciando pochi artefatti investigativi.
Secondo l’analisi tecnica pubblicata da xint.io, la condizione di sfruttamento è il risultato di una catena di tre modifiche introdotte nel codice upstream nei 2011, 2015 e 2017. Questo spiega perché praticamente ogni distribuzione mainstream risulti oggi esposta, dal momento che tutte incorporano quel medesimo percorso nel sottosistema crittografico.
L’exploit proof-of-concept si condensa in uno script Python di circa 732 byte, pari a circa dieci righe di codice. Come hanno dimostrato i ricercatori di Theori, lo stesso file funziona invariato su Ubuntu, Amazon Linux, RHEL e SUSE, ottenendo root in ogni scenario testato con una sola esecuzione.
"Same script, four distributions, four root shells — in one take. The same exploit binary works unmodified on every Linux distribution" — Theori researchers (via BleepingComputer)
Perché l'exploit è invisibile e cross-container
La caratteristica più pericolosa di Copy Fail è la totale assenza di persistenza su disco. Poiché la corruzione avviene esclusivamente nel page cache in-memory e il kernel non marca le pagine alterate come dirty, non viene generata alcuna scrittura nei blocchi di storage. Come ha osservato Google-owned Wiz, "Because the page cache represents the in-memory version of executables, modifying it effectively alters binaries at execution time without touching disk".
Questo comportamento rende l’attacco estremamente difficile da rilevare tramite monitoraggi filesystem standard, hash di integrità o tool di endpoint protection tradizionali. L’effetto è transitorio: al riavvio del sistema il binario originale viene ricaricato dal disco, cancellando ogni traccia della manipolazione. Per i team di sicurezza, questo significa che gli artefatti forensi si limitano alla memoria volatile.
La condivisione del page cache tra host e container amplifica ulteriormente il rischio. Kaspersky ha evidenziato che ambienti Docker, LXC e Kubernetes espongono per default ai processi interni il sottosistema AF_ALG. Un singolo container compromesso può quindi iniettare la propria corruzione nel page cache dell’host, bypassando l’isolamento e ottenendo il controllo totale del nodo fisico.
In infrastrutture multi-tenant, come i nodi dedicati a workload crittografici o le piattaforme cloud condivise, la compromissione di un singolo tenant si traduce immediatamente in accesso root cross-container. La combinazione di stealth e portabilità trasforma una falla locale in una minaccia di infrastruttura su larga scala.
Le prime evidenze di testing e la campagna in-the-wild
CISA ha formalizzato lo stato di emergenza inserendo CVE-2026-31431 nel catalogo Known Exploited Vulnerabilities il 1° maggio 2026, confermando che la falla è già sfruttata attivamente in-the-wild. L’agenzia ha attivato la Binding Operational Directive 22-01, ordinando alle agenzie federali civili statunitensi di applicare le patch entro il 15 maggio 2026. La gravità dello scenario ha spinto il governo a una finestra di remediation di sole due settimane.
Il responsible disclosure è stato gestito con tempi compressi. Secondo quanto riportato da crypto.news, Theori ha inviato il report privato al Linux kernel security team il 23 marzo 2026; la patch è arrivata in mainline il 1° aprile e l’assegnazione del CVE è avvenuta il 22 aprile. Questo ritmo serrato ha lasciato poco margine per il backporting prima dell’inizio dello sfruttamento attivo.
Parallelamente, Microsoft Defender Security Research Team ha dichiarato di essere "seeing preliminary testing activity that might result most likely in increased threat actor exploitation over the next few days". L’osservazione indica che attori di minaccia stanno già verificando l’affidabilità dell’exploit in previsione di campagne più ampie. Non è tuttavia chiaro se gli attacchi osservati da CISA costituiscano già un’operazione su larga scala o una weaponizzazione preliminare.
La vulnerabilità ha ricevuto un punteggio CVSS di 7.8, collocandola in una fascia di gravità alta ma non critica in teoria. Nella pratica, la semplicità di sfruttamento, la mancanza di interazione utente e l’universalità dell’exploit rendono il rischio effettivo sostanzialmente superiore al numero.
Cosa fare adesso
- Aggiornare immediatamente ai kernel Linux versioni 6.18.22, 6.19.12 e 7.0, o alle equivalenti patch backport, concentrando prima i sistemi esposti a Internet o con accesso multi-utente.
- Prioritizzare il patching sui nodi Docker, LXC e Kubernetes, dove la condivisione del page cache espone l’host a container escape anche da workload isolati.
- Verificare se il modulo algif_aead sia effettivamente caricato nei sistemi in produzione, poiché la vulnerabilità è sfruttabile solo dove il sottosistema AF_ALG è attivo.
- Rafforzare il monitoraggio a livello di kernel e memoria, poiché l’assenza di scritture su disco rende inadeguato il rilevamento basato esclusivamente su integrity check del filesystem.
Copy Fail dimostra come una catena di modifiche apparentemente innocue nel kernel possa trasformarsi, anni dopo, in un vettore di attacco universale e quasi invisibile. La combinazione di portabilità totale, dimensioni microscopiche e assenza di tracce su disco abbassa la soglia di sfruttamento a livelli pericolosissimi per qualsiasi infrastruttura Linux, dal server fisico al pod Kubernetes. La reazione di CISA, con una deadline di sole due settimane, non è eccessiva: è la conferma che il rischio è immediato e la finestra di esposizione, aperta dal 2017, è semplicemente troppo ampia per essere lasciata aperta ancora.
Domande frequenti
L'exploit richiede accesso fisico o remoto al server?
Non è un attacco remoto. La vulnerabilità è una local privilege escalation, quindi richiede un accesso iniziale al sistema, come una shell ottenuta tramite SSH compromesso o un job CI malevolo.
Perché l'antivirus o l'EDR non rileva l'attacco?
Poiché la corruzione avviene solo nel page cache in-memory senza scrivere su disco, i controlli di integrità del filesystem e le firme tradizionali non rilevano la modifica. È necessario un monitoraggio a livello di kernel o memoria.
I container isolati sono davvero a rischio anche senza privilegi?
Sì. Il page cache è condiviso tra host e container, e il sottosistema AF_ALG è accessibile per default ai processi containerizzati. Un container non privilegiato può corrompere binari setuid dell'host e forzare l'escape.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://www.bleepingcomputer.com/news/security/cisa-says-copy-fail-flaw-now-exploited-to-root-linux-systems/
- https://thehackernews.com/2026/05/cisa-adds-actively-exploited-linux-root.html
- https://thehackernews.com/2026/04/new-linux-copy-fail-vulnerability.html
- https://crypto.news/cisa-adds-linux-copy-fail-flaw-to-exploited-bug-list/
- https://xint.io/blog/copy-fail-linux-distributions