Sette righe di Python. Settecentotrentadue byte. Tanto è bastato per dimostrare che praticamente ogni distribuzione Linux rilasciata negli ultimi nove anni — da Ubuntu ad Amazon Linux, da RHEL a SUSE — contiene un buco che permette a qualsiasi utente locale di diventare root. Non servono condizioni di race, non servono offset specifici del kernel, non serve nemmeno una conoscenza approfondita del sistema: basta eseguire lo script e il gioco è fatto. Si chiama Copy Fail, è catalogata come CVE-2026-31431, ed è stata resa pubblica il 29 aprile 2026. La community di sicurezza è in subbuglio, e a ragione: non si vedeva una vulnerabilità di escalation locale così pulita e universale dai tempi di Dirty Cow — con la differenza che questa è peggio.
A trovarla è stato Taeyang Lee, ricercatore della sudcoreana Theori, con l’aiuto di Xint Code, un agente AI specializzato nell’audit di sicurezza. E qui si apre un secondo livello di lettura, forse ancora più inquietante del bug in sé: un’intelligenza artificiale ha scandagliato il sottosistema crittografico del kernel Linux e in un’ora — sessanta minuti — ha identificato una falla che era lì, nascosta in bella vista, dal 2017. La domanda da porsi non è solo “come ci difendiamo da Copy Fail”, ma “quante Copy Fail ci sono ancora là fuori, in attesa che il prossimo agente AI le trovi?”.
Come funziona il bug che nessuno ha visto per nove anni
Copy Fail è una falla logica — non un errore di memoria, non un buffer overflow — nel template crittografico authencesn del kernel Linux. Per capire perché è così devastante bisogna fare un passo indietro e guardare come tre decisioni di design, prese in momenti diversi e ciascuna ragionevole in isolamento, si sono combinate in un cocktail esplosivo. Nel 2011 viene aggiunto authencesn, un wrapper AEAD usato da IPsec per gestire i numeri di sequenza estesi (ESN). Per fare il suo lavoro, authencesn usa il buffer di destinazione come spazio di lavoro temporaneo — una scelta perfettamente sicura all’epoca, perché il buffer veniva sempre allocato internamente al kernel. Nel 2015 arriva il supporto AF_ALG per le operazioni AEAD: il kernel espone un’interfaccia socket che permette a processi non privilegiati di usare la crittografia del kernel. Ancora nessun problema, perché input e output usano scatterlist separate. Poi, nel 2017, qualcuno aggiunge un’ottimizzazione apparentemente innocua: le operazioni AEAD diventano “in-place”, la stessa scatterlist serve sia da input che da output. Ed è qui che tutto crolla.
Il punto è che con splice() — una system call che trasferisce dati tra file descriptor senza copiarli, passando riferimenti diretti alle pagine della page cache del kernel — un attaccante può far finire le pagine di un file leggibile (per esempio /usr/bin/su) direttamente nella scatterlist di destinazione. Quando authencesn esegue la decrittazione, manipola i byte per gestire l’ESN e scrive 4 byte controllati dall’attaccante a un offset scelto dall’attaccante — ma quei 4 byte finiscono nella page cache del file bersaglio, non nel buffer crittografico. L’attaccante controlla tre parametri: quale file colpire, a quale offset scrivere, e quali 4 byte iniettare. Il risultato? Si può patchare un binario setuid in memoria e ottenere root istantaneamente. Nessuna race condition da vincere, nessun timing critico, nessun crash del sistema. Un exploit deterministico, lineare, brutale nella sua semplicità.
C’è un dettaglio che rende Copy Fail ancora più insidioso — e che dovrebbe togliere il sonno a chiunque gestisca infrastrutture critiche. Il kernel non marca mai la pagina corrotta come “dirty” per il writeback. Significa che il file su disco rimane intatto: i checksum non rilevano nulla, i tool di integrità dei file non vedono nulla. Ma la page cache è quella che il sistema legge effettivamente quando esegue un binario, quindi la versione corrotta in memoria è immediatamente attiva e visibile a tutto il sistema. Un fantasma che esiste solo in RAM, invisibile a qualsiasi verifica forense tradizionale. Per chi si occupa di incident response, è un incubo.
L’AI che scova falle più veloce degli umani (e le implicazioni che nessuno vuole affrontare)
La storia di come Copy Fail è stata scoperta è, per certi versi, più significativa del bug stesso. Taeyang Lee non ha semplicemente letto il codice e trovato l’errore: ha prima studiato come il sottosistema crittografico di Linux interagisce con i dati nella page cache, poi ha puntato Xint Code — l’agente AI di Theori — contro l’intero sottosistema crypto/ con un prompt molto specifico. Gli ha chiesto di esaminare tutti i percorsi di codice accessibili dallo userspace, con particolare attenzione al fatto che splice() può far finire file read-only in aree modificabili. In un’ora di scansione, l’AI ha prodotto Copy Fail come “output a severità più alta”. Un’ora.
Non è un caso isolato. Ad aprile 2026 il panorama della cybersicurezza è stato scosso da una serie di scoperte simili. Anthropic ha dimostrato che il suo modello Claude Mythos Preview è in grado di trovare autonomamente vulnerabilità zero-day in ogni sistema operativo e browser principale, costruendo exploit funzionanti. Un ricercatore ha usato Claude Code per scovare un heap buffer overflow nel kernel Linux che era lì da ventitré anni, nel driver NFSv4. I report automatizzati ai maintainer del kernel sono passati da spazzatura a segnalazioni legittime — 5-10 report validi al giorno, secondo chi le riceve. La verità è un’altra rispetto alla narrativa rassicurante del “l’AI ci proteggerà”: siamo entrati in un’epoca in cui la scoperta di vulnerabilità è stata automatizzata, ma la capacità di applicare patch no. I cicli di aggiornamento delle organizzazioni — settimane, a volte mesi — non reggono il passo di un agente che trova zero-day in sessanta minuti. E ogni patch pubblicata diventa a sua volta un blueprint per l’exploit, perché l’AI accelera anche il reverse engineering delle correzioni.
Chi ha il potere in questo scenario? Non gli utenti, non gli amministratori di sistema delle piccole aziende, non i maintainer volontari del kernel — persone che lavorano gratis o quasi per tenere in piedi l’infrastruttura su cui gira il mondo. Il potere ce l’hanno le aziende di sicurezza che vendono agenti AI, i governi che li usano per operazioni offensive (il Pentagono finanzia ricerca di questo tipo da anni), e le grandi corporation tech che possono permettersi team di risposta rapida. Il software libero, paradossalmente, diventa sia il terreno di caccia più ricco — perché il codice è aperto e analizzabile — sia il più esposto, perché i tempi di patch dipendono da comunità cronicamente sotto-finanziate. Non ci giriamo intorno: l’asimmetria è strutturale.
Container, Kubernetes e il mito dell’isolamento
Se Copy Fail fosse “solo” una privilege escalation locale, sarebbe già grave. Ma il punto è che in un mondo di container e microservizi, “locale” ha un significato molto diverso da quello che aveva dieci anni fa. Un container condivide il kernel con l’host. La page cache è condivisa. Un processo non privilegiato dentro un container Docker o un pod Kubernetes può usare Copy Fail esattamente come farebbe su una macchina fisica — e una volta ottenuto root sul nodo, l’intero cluster è compromesso. Il CERT-EU ha classificato Copy Fail come vettore di escape da container e compromissione di nodi Kubernetes, raccomandando di applicare le mitigazioni immediatamente su nodi Kubernetes, runner CI/CD esposti a workload non fidati, e sistemi multi-tenant.
Facciamo un passo indietro e guardiamo il quadro completo. La supply chain degli attacchi moderni funziona così: si trova un punto di ingresso — una RCE in un’applicazione web, un accesso SSH rubato, una pull request malevola in un runner CI — e si atterra con privilegi minimi. Prima di Copy Fail, scalare a root richiedeva exploit specifici per kernel e distribuzione, spesso inaffidabili. Ora basta uno script Python da 732 byte che funziona ovunque senza modifiche. Per chi attacca, è un moltiplicatore di forza enorme. Per chi difende, è un incubo logistico: la superficie esposta include ogni singola macchina Linux — fisica, virtuale o containerizzata — messa in produzione dal 2017 in poi. E con le syscall usate dall’exploit (socket, splice, sendmsg, recvmsg) che sono perfettamente legittime e usatissime, bloccarle con seccomp senza rompere nulla richiede un’analisi approfondita di ogni workload. Sysdig ha pubblicato regole Falco per rilevare la creazione di socket AF_ALG da processi non privilegiati, ma è una toppa su una falla strutturale.
Il nocciolo della questione è che l’architettura stessa dei container — isolamento nello userspace, kernel condiviso — ha un limite intrinseco che vulnerabilità come Copy Fail rendono evidente. Le alternative esistono: microVM come Firecracker (usate da AWS Lambda), unikernel, o approcci come gVisor che intercettano le syscall. Ma sono soluzioni che aggiungono complessità, costi, e che le piccole organizzazioni non possono permettersi di implementare. Di nuovo, chi può permettersi la sicurezza vera sono i giganti del cloud — AWS, Google, Microsoft — mentre le aziende più piccole, le cooperative, i progetti comunitari restano esposti. La sicurezza diventa un lusso, e questo è un problema politico prima ancora che tecnico.
Dirty Cow, Dirty Pipe, Copy Fail: la storia che si ripete
Ogni pochi anni il kernel Linux produce una vulnerabilità di escalation locale che diventa un nome proprio — un marchio, quasi, con tanto di logo e sito web dedicato (copy.fail, appunto). Dirty Cow nel 2016 sfruttava una race condition nel meccanismo copy-on-write del virtual memory subsystem: funzionava, ma richiedeva tentativi multipli e a volte crashava il sistema. Dirty Pipe nel 2022 era più pulita ma specifica per certe versioni del kernel e richiedeva manipolazione precisa dei buffer delle pipe. Copy Fail è un salto qualitativo. Nessuna race da vincere, nessuna dipendenza dalla versione, lo stesso identico script funziona su Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 e SUSE 16 senza una singola modifica. La parola che i ricercatori di Theori usano è “straight-line”: un percorso di codice lineare, deterministico, che non può fallire. È la vulnerabilità di escalation locale perfetta, o quasi.
Questo schema ricorrente — un bug che resta nascosto per anni in un sottosistema che pochi capiscono davvero — dice qualcosa di profondo sulla sostenibilità del modello open source così come è strutturato oggi. Il kernel Linux è mantenuto da un nucleo relativamente ristretto di sviluppatori, molti dei quali lavorano per le stesse corporation (Red Hat, Google, Intel, Meta) che poi lucrano sull’ecosistema. Il sottosistema crittografico, in particolare, è un angolo del codice denso, complesso, dove una review approfondita richiede competenze molto specialistiche. Il commit del 2017 che ha introdotto la vulnerabilità — l’ottimizzazione in-place in algif_aead.c — è passato attraverso il normale processo di review senza che nessuno cogliesse l’interazione con authencesn e splice(). Non per incompetenza, ma perché il codice era stratificato su tre decisioni di design prese in sei anni diversi, da persone diverse, per ragioni diverse. La complessità è il nemico, e il kernel Linux è un mostro da oltre 30 milioni di righe di codice.
Quanto alla timeline di Copy Fail: il bug è stato segnalato al security team del kernel il 23 marzo 2026, le patch sono state committate nel mainline il 1° aprile, la CVE assegnata il 22 aprile, la disclosure pubblica il 29 aprile. Ma al momento della disclosure — e qui sta il problema — nessuna distribuzione aveva ancora rilasciato un kernel patchato. Debian, Ubuntu e SUSE hanno spinto gli aggiornamenti nei giorni successivi. Red Hat inizialmente ha rimandato, per poi allinearsi sotto la pressione della community. Nel frattempo, l’exploit era pubblico su GitHub, completo e funzionante. La finestra di esposizione tra disclosure e patch disponibili è il momento in cui il danno reale accade, e per Copy Fail quella finestra è stata — ed è tuttora, per molti sistemi — spalancata. Le versioni del kernel con la fix sono la 7.0, la 6.19.12 e la 6.18.22; la mitigazione temporanea consiste nel disabilitare il modulo algif_aead tramite /etc/modprobe.d/ o nel bloccare la creazione di socket AF_ALG via seccomp.
Domande frequenti
Cos’è Copy Fail (CVE-2026-31431)?
Copy Fail è una vulnerabilità di escalation di privilegi locale nel kernel Linux che permette a qualsiasi utente non privilegiato di ottenere permessi di root. Sfrutta un bug logico nel template crittografico authencesn, raggiungibile attraverso l’interfaccia socket AF_ALG combinata con la system call splice(). Il risultato è la possibilità di scrivere 4 byte controllati nella page cache di qualsiasi file leggibile sul sistema, permettendo di modificare binari setuid in memoria e ottenere root.
Quali sistemi sono vulnerabili?
Tutte le distribuzioni Linux che utilizzano un kernel rilasciato dal 2017 in poi sono potenzialmente vulnerabili. Il bug è stato verificato su Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1, SUSE 16 e Rocky Linux 9.7. Lo stesso exploit funziona senza modifiche su tutte queste distribuzioni e architetture.
Copy Fail può essere sfruttata da remoto?
No, Copy Fail richiede esecuzione di codice locale come utente regolare. Tuttavia, se combinata con qualsiasi vettore che dia accesso locale — una RCE in un’applicazione web, un accesso SSH compromesso, una pull request malevola in un runner CI — diventa immediatamente una via verso root. In ambienti containerizzati, qualsiasi processo dentro un container può sfruttarla per evadere dal container e compromettere il nodo host.
Come proteggersi dalla vulnerabilità?
La soluzione definitiva è aggiornare il kernel alle versioni 7.0, 6.19.12 o 6.18.22 che contengono la fix. Come mitigazione temporanea, si può disabilitare il modulo kernel algif_aead aggiungendo blacklist algif_aead e install algif_aead /bin/false in un file dentro /etc/modprobe.d/. In ambienti containerizzati, il CERT-EU raccomanda di bloccare la creazione di socket AF_ALG via policy seccomp su tutti i workload.
Perché Copy Fail è considerata più grave di Dirty Cow e Dirty Pipe?
A differenza di Dirty Cow (2016) che richiedeva di vincere una race condition e poteva crashare il sistema, e di Dirty Pipe (2022) che funzionava solo su versioni specifiche del kernel, Copy Fail è un exploit deterministico che non richiede race, non crasha il sistema, e funziona identicamente su tutte le distribuzioni dal 2017. Inoltre, la modifica avviene solo nella page cache in memoria senza lasciare tracce su disco, rendendola invisibile ai tool di verifica dell’integrità dei file.
Copy Fail non è solo un bug. È un segnale — dell’accelerazione impressionante nella scoperta automatizzata di vulnerabilità, della fragilità strutturale di infrastrutture critiche che girano su codice mantenuto da comunità sotto-finanziate, del divario crescente tra chi può permettersi la sicurezza e chi no. Il kernel su cui gira il mondo ha un problema di complessità che nessun numero di occhi umani — e forse nemmeno di agenti AI — può risolvere completamente. La risposta non è più sicurezza come prodotto (da vendere, da comprare), ma sicurezza come pratica collettiva: finanziamento strutturale allo sviluppo open source, audit indipendenti, trasparenza nei processi di disclosure. Il contrario, in altre parole, di quello che fa il mercato.