Copy Fail CVE-2026-31431: CISA conferma exploit attivi. Proteggi i server Linux della tua PMI

Ultimo aggiornamento: 4 maggio 2026 — La notizia è fresca di poche ore e merita attenzione immediata.

Il 2 maggio 2026, la Cybersecurity and Infrastructure Security Agency (CISA) degli Stati Uniti ha inserito la vulnerabilità CVE-2026-31431 — ribattezzata "Copy Fail" — nel catalogo Known Exploited Vulnerabilities (KEV), il registro che elenca esclusivamente le falle di sicurezza per cui esistono prove di sfruttamento attivo. Non è un allarme teorico: qualcuno, da qualche parte, sta già usando questo bug per compromettere sistemi Linux in produzione.

La vulnerabilità è un difetto logico nel sottosistema crittografico del kernel Linux, presente in tutte le distribuzioni rilasciate dal 2017. Consente a un utente locale senza privilegi di ottenere accesso root corrompendo la page cache in memoria di file leggibili, inclusi i binari setuid, il tutto con uno script Python di appena 732 byte. Per il pubblico di Neomedia — PMI italiane, professionisti IT e provider che gestiscono server Linux on-premise, VPS cloud, container Docker e cluster Kubernetes — questa è una minaccia concreta che richiede azioni immediate.

Cos'è Copy Fail e perché è diversa dalle altre vulnerabilità Linux

Copy Fail (CVE-2026-31431) è stata scoperta dal team di ricerca di Theori, un'azienda sudcoreana specializzata in sicurezza, utilizzando il loro strumento di analisi assistita da AI chiamato Xint Code. La vulnerabilità è stata segnalata al team di sicurezza del kernel Linux il 23 marzo 2026, con patch mainline pubblicata il 1° aprile e divulgazione pubblica il 29 aprile. Nel giro di 24 ore dalla disclosure, sono apparsi su GitHub almeno sei exploit indipendenti, incluso un port in C compilabile su qualsiasi architettura [tenable.com].

Ma cosa rende Copy Fail diversa dalle decine di altre vulnerabilità di privilege escalation scoperte ogni anno nel kernel Linux? Tre caratteristiche la distinguono nettamente:

1. È deterministica, non una race condition. A differenza di Dirty Cow (CVE-2016-5195), che richiedeva una competizione temporale con possibili fallimenti, Copy Fail funziona al primo tentativo, ogni volta, senza crash del sistema [sysdig.com].
2. È portabile. Lo stesso script Python da 732 byte funziona immutato su Ubuntu 24.04, Amazon Linux 2023, RHEL 10.1 e SUSE 16, coprendo kernel dalla versione 6.12 alla 6.18. Nessun offset per-distribuzione, nessuna ricompilazione [securityaffairs.com].
3. È invisibile ai controlli su disco. La corruzione avviene esclusivamente nella page cache in memoria, senza mai modificare il file su disco. Il kernel non marca mai la pagina come "dirty". Strumenti come AIDE, Tripwire, Wazuh e OSSEC — che verificano hash su disco — non rilevano nulla [zendata.security].

Il punteggio CVSSv3 assegnato è 7.8 (HIGH). Non è remota in isolamento — richiede un accesso locale al sistema — ma come vedremo tra poco, questo non la rende meno pericolosa per l'infrastruttura tipica di una PMI.

Come funziona il bug: una spiegazione accessibile

Il meccanismo di Copy Fail nasce dall'intersezione di tre modifiche al kernel Linux accumulate in quasi un decennio, ciascuna ragionevole presa singolarmente, letale in combinazione:

• 2011: viene aggiunto il template crittografico authencesn per supportare gli Extended Sequence Numbers di IPsec. Il template usa il buffer di destinazione come spazio di lavoro temporaneo per riordinare 4 byte — un'operazione innocua all'epoca.
• 2015: il sottosistema AF_ALG riceve il supporto per operazioni AEAD (Authenticated Encryption with Associated Data), permettendo a qualsiasi utente, senza privilegi, di accedere all'API crittografica del kernel via socket.
• 2017: un'ottimizzazione (commit 72548b093ee3) rende le operazioni AEAD "in-place": il buffer di input e output diventano lo stesso, incatenando le pagine della page cache direttamente nella scatterlist di destinazione [tenable.com].

Il risultato di queste tre modifiche combinate è una catena di attacco sorprendentemente semplice. Quando un utente usa splice() per passare dati da un file al socket crittografico, la page cache del file — la copia in memoria che il kernel usa per leggere i file — viene collegata direttamente alla struttura dati che il template authencesn userà come spazio di lavoro. I 4 byte che il template scrive "fuori dal limite dichiarato" come gratta-e-vinci temporaneo finiscono dritti nella page cache del file scelto dall'attaccante.

L'attaccante controlla tre cose: quale file viene mappato, quale offset di 4 byte viene sovrascritto, e quale valore viene scritto. Ripetendo l'operazione circa 40 volte, può iniettare uno shellcode completo nella copia in memoria di un binario setuid come /usr/bin/su. Quando il binario viene eseguito, il kernel carica la versione corrotta dalla page cache, e lo shellcode gira con UID 0 — accesso root completo [izoologic.com].

Cosa significa che CISA l'ha aggiunta al KEV

Il catalogo Known Exploited Vulnerabilities della CISA non è un semplice bollettino. È un ordine operativo vincolante per tutte le agenzie federali statunitensi (Binding Operational Directive 22-01), che impone la remediation entro scadenze tassative. Ma il suo significato va ben oltre il perimetro governativo americano: quando una vulnerabilità entra nel KEV, la CISA sta dicendo al mondo che ha prove che qualcuno la sta già sfruttando.

Al 30 aprile 2026, Copy Fail non era ancora nel KEV. L'inserimento è avvenuto tra il 2 e il 3 maggio, a meno di una settimana dalla divulgazione pubblica del 29 aprile — una finestra di tempo straordinariamente breve che segnala la gravità della situazione. Nel catalogo KEV erano già presenti oltre 20 vulnerabilità del kernel Linux, incluse Dirty Cow (CVE-2016-5195) e Dirty Pipe (CVE-2022-0847), le due falle con cui Copy Fail viene più spesso paragonata [tenable.com].

La presenza nel KEV cambia il calcolo del rischio per qualsiasi organizzazione. Non si tratta più di chiedersi "potrei essere attaccato?", ma di assumere che qualcuno stia già scansionando attivamente sistemi vulnerabili e prepararsi di conseguenza.

Chi è davvero a rischio? Non solo le big tech

La narrativa che circola in alcune analisi preliminari è che Copy Fail sia un problema solo per ambienti multi-tenant, cloud provider e cluster Kubernetes condivisi. Questa lettura è pericolosamente riduttiva. Vediamo perché la PMI italiana è esposta su più fronti.

Server on-premise e VPS cloud

Qualsiasi server Linux con kernel 4.14 o successivo — quindi virtualmente ogni distribuzione installata dal 2017 — è vulnerabile. Per una PMI italiana tipica, questo include il server contabile in sede, il VPS che ospita il sito aziendale, il server di posta, il NAS aziendale basato su Linux. Se una qualsiasi di queste macchine ha un accesso SSH aperto — anche limitato a IP autorizzati, anche protetto da autenticazione a due fattori quando configurata — l'utente che si autentica parte da un contesto non privilegiato. Da lì a root, con Copy Fail, il passo è uno script da 732 byte.

Container Docker e Kubernetes

Copy Fail non è solo una vulnerabilità di privilege escalation: è anche un vettore di container escape. La page cache del kernel è condivisa tra tutti i container in esecuzione su uno stesso nodo. Un utente che esegue codice in un container — anche un container non privilegiato, con tutte le capability Linux droppate, conforme ai Pod Security Standard "Restricted" di Kubernetes — può sfruttare Copy Fail per corrompere un binario setuid dell'host e ottenere root sulla macchina fisica [zendata.security].

Questo significa che un'azienda che usa un cluster Kubernetes gestito (o self-hosted) per i propri servizi, o semplicemente esegue applicazioni in container Docker su un server condiviso, ha una superficie d'attacco che va oltre il container stesso. I profili seccomp predefiniti di Docker, containerd e CRI-O non bloccano la creazione di socket AF_ALG (address family 38), quindi il percorso di attacco è aperto con le configurazioni standard [zendata.security].

Workstation Linux degli sviluppatori

In molte PMI, gli sviluppatori usano workstation Linux (Ubuntu, Fedora, Debian) con accesso sudo. Se la workstation è vulnerabile, un malware arrivato via email di phishing che gira come utente normale può usare Copy Fail per elevarsi a root e installare keylogger, rubare chiavi SSH, o muoversi lateralmente verso i server di produzione. La sicurezza della workstation Linux non è un problema individuale: è un anello della catena di sicurezza aziendale.

Confronto con Dirty Cow e Dirty Pipe: perché Copy Fail è peggiore

Per comprendere la portata di Copy Fail, è utile confrontarla con le due vulnerabilità di privilege escalation del kernel Linux più note dell'ultimo decennio.

Caratteristica	Dirty Cow (CVE-2016-5195)	Dirty Pipe (CVE-2022-0847)	Copy Fail (CVE-2026-31431)
Meccanismo	Race condition su copy-on-write	Pipe buffer non inizializzato	Logic bug su page cache via crypto API
Affidabilità	Bassa: richiede tentativi multipli	Media: vincoli su offset e dati	Alta: deterministica, primo tentativo
Portabilità	Version-specific	Richiede adattamenti per distribuzione	Singolo script per tutte le distro
Dimensione exploit	~200 righe C	~100 righe C	~30 righe Python (732 byte)
Rilevabilità forense	Possibile su disco	Possibile su disco	Quasi nulla: solo page cache
Nel KEV CISA	Sì (dal 2022)	Sì (dal 2022)	Sì (dal 3 maggio 2026)

La differenza cruciale è la combinazione di affidabilità e invisibilità. Dirty Cow era rumorosa e inaffidabile. Dirty Pipe aveva vincoli su cosa e dove scrivere. Copy Fail è silenziosa, deterministica e funziona ovunque con lo stesso codice [sysdig.com].

Come verificare se i tuoi sistemi sono esposti

Prima di correre a installare patch, bisogna capire quali sistemi sono vulnerabili. Ecco una checklist operativa pensata per l'amministratore IT di una PMI.

Checklist di verifica in 4 step

1. Controlla la versione del kernel su ogni macchina Linux che gestisci (server fisici, VPS, VM, container host):

   uname -r

   Sono vulnerabili tutte le versioni dalla 4.14 fino alla 7.0-rc, incluse le 6.18.x precedenti alla 6.18.22 e le 6.19.x precedenti alla 6.19.12. Ricorda: molte distribuzioni backportano le patch su kernel LTS più vecchi (5.10.x, 5.15.x, 6.6.x, 6.12.x), quindi la versione numerica da sola non basta: verifica con il tuo vendor [sysdig.com].
2. Verifica se il modulo vulnerabile è caricato:

   lsmod | grep algif_aead

   Se il comando restituisce output, il modulo è attivo e il percorso di attacco è aperto.
3. Controlla se ci sono processi che usano AF_ALG:

   lsof | grep AF_ALG
   ss -xa | grep alg

   Questo ti dice se qualche applicazione legittima sta già usando l'interfaccia crittografica. Nella maggior parte dei server di una PMI tipica, l'output sarà vuoto.
4. Censisci i binari setuid:

   find / -perm -4000 -type f 2>/dev/null

   Ogni binario setuid-root è un potenziale bersaglio per Copy Fail. Valuta se ciascuno è realmente necessario e, dove possibile, rimuovi il bit setuid [zendata.security].

Piano di mitigazione: tre linee di difesa per la PMI

La protezione da Copy Fail non è un'operazione binaria (patch sì/no). È una strategia a più livelli, con azioni immediate, azioni a breve termine e misure strutturali. Ecco il piano.

Prima linea: difesa immediata (entro 24 ore)

Disabilita il modulo vulnerabile su tutti i sistemi dove l'aggiornamento immediato del kernel non è praticabile (server in produzione che non possono essere riavviati, appliance con kernel custom, sistemi legacy):

echo "install algif_aead /bin/false" > /etc/modprobe.d/disable-algif-aead.conf
rmmod algif_aead 2>/dev/null || true

Attenzione: questa mitigazione funziona solo se il modulo è compilato come caricabile dinamicamente (CONFIG_CRYPTO_USER_API_AEAD=m). Su alcune distribuzioni enterprise (RHEL, CentOS, Rocky Linux), il modulo potrebbe essere compilato staticamente nel kernel (=y). In quel caso, la mitigazione via modprobe non funziona e va usata l'opzione di boot initcall_blacklist=algif_aead_init aggiunta ai parametri del kernel in GRUB [tenable.com].

Impatto della disabilitazione: test condotti dalla community su oss-security indicano che disabilitare algif_aead non causa malfunzionamenti in cryptsetup, dm-crypt, LUKS, IPsec, OpenSSL, GnuTLS, SSH e nel kernel keyring. Questi componenti usano l'API crittografica del kernel direttamente, non attraverso AF_ALG. Le uniche applicazioni potenzialmente impattate sono quelle che abilitano esplicitamente l'engine afalg di OpenSSL, un caso raro al di fuori di ambienti di test. Verifica comunque in un ambiente non di produzione prima di applicare la mitigazione su larga scala.

Seconda linea: aggiornamento kernel (entro 7 giorni)

Le versioni del kernel che correggono Copy Fail sono:

• Linux 7.0
• Linux 6.19.12
• Linux 6.18.22
• Backport distribuzione-specifici per kernel LTS più vecchi (6.12.x, 6.6.x, 5.15.x, 5.10.x) — verifica con il tuo vendor [sysdig.com]

La correzione (commit fafe0fa2995a) elimina l'ottimizzazione in-place del 2017, ripristinando la separazione tra buffer di input e output. La page cache non entra più nella scatterlist scrivibile. È una modifica chirurgica che non introduce nuove funzionalità e ha un profilo di rischio bassissimo per la stabilità del sistema.

Nota operativa: dopo l'installazione del pacchetto kernel aggiornato, verifica con uname -r che il kernel attivo sia effettivamente quello patchato. Un errore comune è installare il pacchetto ma continuare a eseguire il vecchio kernel perché il sistema non è stato riavviato o perché GRUB non ha selezionato la nuova versione. Per ambienti che non tollerano downtime, soluzioni come kpatch (Red Hat) e Canonical Livepatch (Ubuntu) permettono il patching a caldo senza riavvio [zendata.security].

Terza linea: difesa strutturale (entro 30 giorni)

Copy Fail è un sintomo di problemi più profondi che vanno affrontati strutturalmente:

• Applica il principio del minimo privilegio agli accessi SSH. Chi ha davvero bisogno di una shell sui server? Disattiva gli account non utilizzati, revoca le chiavi SSH di ex dipendenti e fornitori, e implementa l'autenticazione a due fattori. Se vuoi approfondire, consulta la nostra guida pratica all'autenticazione a due fattori.
• Rimuovi i binari setuid non necessari. Su ogni sistema, esegui find / -perm -4000 -type f e valuta caso per caso. Meno binari setuid ci sono, meno bersagli ha un attaccante. Questo riduce la superficie d'attacco per Copy Fail e per qualsiasi futura vulnerabilità di privilege escalation.
• Implementa il monitoraggio runtime. Regole di detection comportamentale — come quelle sviluppate da Sysdig per Falco — possono identificare la creazione sospetta di socket AF_ALG da parte di processi non autorizzati. Per le PMI che usano container, un profilo seccomp personalizzato che blocca l'address family 38 (AF_ALG) fornisce una protezione aggiuntiva indipendentemente dallo stato delle patch [sysdig.com]. Approfondisci con il nostro articolo sulla cybersecurity per PMI in tempo reale.
• Riconsidera la fiducia nei container come barriera di sicurezza. Copy Fail dimostra — ancora una volta — che i container Linux non sono un confine di sicurezza robusto contro attacchi kernel-level. Se la tua infrastruttura esegue codice di terze parti in container (job CI, sandbox, plugin), tratta il nodo host come potenzialmente compromettibile. La nostra guida all'hosting aziendale ti aiuta a valutare le opzioni di isolamento.

Quando Copy Fail è un'emergenza e quando no

Non tutti i sistemi Linux hanno lo stesso profilo di rischio. Ecco una matrice decisionale per aiutare il responsabile IT di una PMI a calibrare la risposta.

⚠️ Emergenza (azione immediata richiesta)

• Server Linux con accesso SSH multi-utente (dipendenti, fornitori, consulenti con credenziali)
• Ambienti CI/CD che eseguono codice non fidato (pull request pubbliche, build automatizzate)
• Piattaforme SaaS che eseguono codice caricato dai clienti (notebook, sandbox, agent)
• Cluster Kubernetes con carichi di lavoro multi-tenant sullo stesso nodo
• Jump host e bastion server usati da più persone per accedere all'infrastruttura
• Server in infrastrutture ibride (on-premise + cloud) dove un singolo accesso compromesso apre la strada a tutti gli ambienti

✅ Rischio gestibile (patch pianificabile nel ciclo ordinario)

• Workstation Linux mono-utente usate esclusivamente dal legittimo proprietario, senza servizi SSH esposti
• Server single-user dove solo l'amministratore ha accesso e non ci sono altri account
• Sistemi isolati senza connettività di rete verso l'esterno
• Ambienti di test e sviluppo senza dati sensibili e senza connettività verso la produzione

Attenzione però: il profilo di rischio può cambiare se l'ambiente è esposto a Internet. Un server web compromesso via vulnerabilità applicativa (SQL injection, RCE) dà all'attaccante esattamente l'accesso locale che Copy Fail richiede. Per approfondire la protezione del perimetro cloud, leggi il nostro articolo sulla cloud security per PMI con Linux.

Come capire se sei già stato compromesso

La caratteristica più insidiosa di Copy Fail è la sua invisibilità forense su disco. I file rimangono immutati; i backup notturni non contengono tracce. Tuttavia, esistono indicatori che un'amministrazione attenta può monitorare.

Il team di Sysdig ha sviluppato regole di detection basate su un invariante del kernel Linux: quando un binario setuid viene eseguito, il kernel eredita il real user ID (ruid) dal processo chiamante, elevando solo l'effective user ID (euid). L'unico modo in cui il nuovo processo può avere ruid=0 partendo da un genitore con ruid≠0 è se il processo figlio chiama esplicitamente setuid(0) — esattamente ciò che fa lo shellcode iniettato da Copy Fail. Questa singola regola comportamentale rileva tutte le varianti dell'exploit con falsi positivi vicini allo zero [zendata.security].

Altri indicatori da monitorare:

• Creazione di socket AF_ALG da parte di processi non appartenenti al toolchain di cifratura disco (cryptsetup, systemd-cryptsetup, veritysetup)
• Burst di chiamate splice() da parte di utenti non privilegiati
• Esecuzione di binari setuid da parte di processi che non dovrebbero chiamarli
• Transizioni di privilegio anomale: un processo utente che improvvisamente gira come root senza una richiesta sudo o su legittima

La detection runtime — non l'analisi forense su disco — è lo strumento principale per identificare un attacco Copy Fail in corso o già avvenuto.

Cosa ci insegna Copy Fail sul futuro della cybersecurity

Copy Fail non è solo l'ennesima vulnerabilità da patchare. È un punto di svolta che merita una riflessione.

L'AI sta cambiando l'economia della scoperta delle vulnerabilità. Copy Fail non è stata trovata da un essere umano che leggeva codice, ma da Xint Code, uno strumento di analisi assistita da AI sviluppato da Theori. La scansione che ha scoperto Copy Fail ha impiegato circa un'ora. Ha anche trovato altre vulnerabilità ad alta severità nel sottosistema crittografico del kernel, ancora in fase di divulgazione coordinata. Se strumenti di questo tipo diventano accessibili, il tasso di scoperta di vulnerabilità critiche aumenterà, e la finestra tra scoperta e sfruttamento si comprimerà ulteriormente [zendata.security]. Per approfondire come l'AI sta ridisegnando il panorama delle minacce, leggi il nostro articolo su AI generativa e vulnerabilità zero-day.

Le vulnerabilità latenti sono la nuova normalità. Copy Fail è rimasta dormiente per nove anni — dal commit del 2017 alla disclosure del 2026. Tre modifiche indipendenti, ciascuna ragionevole nel proprio contesto, hanno creato una vulnerabilità che nessun revisore umano aveva notato. In codebase della complessità del kernel Linux, questo non sarà l'ultimo caso. L'unica difesa è una postura che assume la presenza di vulnerabilità sconosciute e costruisce più strati di protezione.

La distinzione "locale vs remota" sta diventando irrilevante. Copy Fail richiede accesso locale, ma in un mondo di container, CI/CD, SaaS e cloud computing, l'accesso locale è spesso la conseguenza di una compromissione precedente. Trattare le vulnerabilità locali come meno gravi significa ignorare la catena di attacco reale. Per le PMI italiane, questo implica ripensare la sicurezza non più come un perimetro da difendere ma come una resilienza stratificata: backup, detection, risposta rapida e aggiornamento continuo. Su questo tema, la nostra guida alla protezione ransomware per PMI offre un framework applicabile anche oltre il ransomware.

Conclusione: agire ora, non domani

Copy Fail (CVE-2026-31431) è una vulnerabilità di privilege escalation del kernel Linux che permette a un utente locale senza privilegi di ottenere accesso root con uno script Python di 732 byte. Colpisce tutte le distribuzioni Linux dal 2017. CISA ne ha certificato lo sfruttamento attivo il 2-3 maggio 2026, inserendola nel catalogo KEV. Le patch esistono, ma la finestra tra disclosure e sfruttamento si è già chiusa.

Per una PMI italiana con server Linux in produzione, la priorità assoluta è verificare l'esposizione e applicare le mitigazioni immediate: disabilitare il modulo algif_aead dove possibile, pianificare l'aggiornamento del kernel entro la settimana, e rafforzare i controlli di accesso SSH. Nel medio termine, investire in monitoraggio runtime e ridurre la superficie d'attacco (binari setuid, accessi multi-utente) crea una protezione che va oltre Copy Fail e copre le vulnerabilità che verranno scoperte domani.

La domanda non è se i tuoi sistemi saranno presi di mira, ma quando. E con Copy Fail, quel "quando" potrebbe essere adesso.