CVE-2026-31431 Copy Fail spiegata

CVE-2026-31431 Copy Fail e una vulnerabilita di elevazione locale dei privilegi nel kernel Linux che e passata molto rapidamente da divulgazione tecnica a priorita operativa. Al 2 maggio 2026, il quadro ufficiale mostra una falla ad alta severita nel componente algif_aead, mitigazioni pubblicate dai principali vendor Linux e l'inclusione nel catalogo CISA Known Exploited Vulnerabilities a partire dal 1 maggio 2026.

Questo articolo resta volutamente ristretto. Non riproduce l'exploit, non stima la prevalenza e non ripete claim di terze parti sulla sua affidabilita. Si limita a cio che le fonti ufficiali confermano davvero: cosa colpisce la vulnerabilita, dove l'esposizione conta di piu, quali mitigazioni temporanee esistono e come validare lo stato della patch senza creare punti ciechi o regressioni operative.

Per il processo piu ampio di audit degli ambienti isolati, vedi Audit di sicurezza di una rete air-gapped: come auditare un ambiente isolato senza falso senso di sicurezza. Per una guida complementare su workflow e strumenti offline-capable, vedi Quali strumenti di sicurezza funzionano in reti isolate senza accesso a internet? Guida pratica ai workflow di sicurezza offline-capable.

Che cos'e CVE-2026-31431 (Copy Fail)?

CVE-2026-31431 e una vulnerabilita del kernel Linux in algif_aead, un componente legato all'interfaccia crittografica del kernel. Il record NVD eredita la descrizione upstream del percorso di fix: il comportamento vulnerabile viene corretto riportando algif_aead a un funzionamento out-of-place invece di mantenere la logica piu complessa in-place introdotta in precedenza.

La severita ufficiale che conta di piu per i difensori in questo momento e il punteggio kernel CNA di CVSS 3.1 7.8 HIGH, con il vettore AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. NVD mostra inoltre la classificazione CWE-669 e elenca diversi riferimenti di patch kernel.org legati a branch stabili.

Dal punto di vista operativo, i vendor stanno trattando il problema come local privilege escalation nel kernel Linux. Questo conta perche l'elevazione locale dei privilegi non e una frontiera puramente accademica. Se un attaccante ha gia esecuzione di codice come utente normale, oppure puo eseguire un workload non affidabile nel posto sbagliato, un percorso affidabile verso root puo cambiare molto rapidamente il confine di fiducia di un bastion, di un host condiviso o di un nodo container.

Cosa confermano finora gli advisory ufficiali

Il quadro ufficiale e gia sufficientemente chiaro per sostenere un triage immediato.

Fonte	Cosa conferma	Perche conta
NVD / kernel CNA	`algif_aead` e il componente interessato; il punteggio CNA CVSS e 7.8 HIGH; NVD mostra la CVE in CISA KEV.	Stabilisce l'identificatore tecnico, la severita e il segnale attuale di prioritizzazione.
Ubuntu	Data di divulgazione pubblica 29 aprile 2026; articolo di mitigazione pubblicato il 30 aprile 2026; impatto inquadrato come local privilege escalation, con il tema container trattato a parte.	Fornisce indicazioni difensive concrete e caveat operativi.
SUSE	Lo stato di prodotto e pacchetto e esposto pubblicamente nella pagina CVE SUSE, con riferimenti a workaround e advisory.	Utile per la validazione a livello di pacchetto e il triage di fleet.
Red Hat	Il bollettino pubblico `RHSB-2026-02` e indicato come Important e Ongoing; esistono pagine pubbliche separate per RHEL e OpenShift.	Conferma una gestione attiva del vendor e percorsi di follow-up specifici per prodotto.

Un secondo segnale operativo e lo stato KEV. NVD osserva esplicitamente che questa CVE e nel catalogo CISA Known Exploited Vulnerabilities, con Date Added: May 1, 2026 e Due Date: May 15, 2026. Anche se la tua organizzazione non segue le scadenze federali statunitensi, resta comunque un segnale utile di prioritizzazione: la vulnerabilita non e piu solo "nuova" o "interessante". E gia nella classe di problemi che i difensori dovrebbero trattare come urgenti.

Dove Copy Fail conta di piu

Non si tratta di una vulnerabilita edge esposta a Internet e sfruttabile senza autenticazione. L'esposizione dipende dalla presenza di un foothold locale o di un percorso di esecuzione su un sistema Linux. Questo lascia comunque diversi scenari ad alto valore.

Host con utenti locali o esecuzione locale di codice

Ubuntu afferma che, nelle distribuzioni senza workload containerizzati, la vulnerabilita consente a un utente locale di elevare i privilegi fino a root. Questo significa che la prima domanda non e "Il mio servizio esposto a Internet e sfruttabile direttamente dall'esterno?" La prima domanda e se l'host puo gia eseguire codice non affidabile o semi-affidabile sotto un account con pochi privilegi.

Esempi tipici includono:

host Linux amministrativi condivisi
bastion o jump host usati da piu team
runner CI e sistemi di build
server multiutente con accesso shell
server di amministrazione adiacenti all'infrastruttura di identita

Ambienti containerizzati

Ubuntu documenta anche una preoccupazione separata per i deployment containerizzati che possono eseguire workload potenzialmente malevoli: la vulnerabilita puo facilitare container escape scenarios. La guida pubblica di Red Hat per OpenShift e ROSA conferma che il vendor tratta l'esposizione managed e OpenShift come un tracciato operativo separato, che e l'inquadramento difensivo corretto.

Questa distinzione conta. Un team fleet non dovrebbe scrivere "container escape" come claim generale per ogni deployment Kubernetes o containerizzato. La formulazione corretta e piu stretta: la documentazione del vendor dice che gli ambienti containerizzati meritano attenzione separata e che il triage dei nodi container non deve essere mescolato con una semplice coda di patching di workstation e server.

Sistemi amministrativi e sistemi adiacenti all'identita

Anche se si tratta di una vulnerabilita del kernel Linux e non di una vulnerabilita Active Directory o Entra, root locale sull'host Linux sbagliato continua a essere importante per i team identita e infrastruttura. Bastion, nodi di provisioning, runner di automazione, appliance VPN, PAM jump host e sistemi Linux usati per amministrare Windows o infrastruttura cloud fanno parte del piano effettivo di identita. Un'elevazione locale dei privilegi in quel punto puo cambiare il modello di fiducia intorno a credentials, token, chiavi di gestione e percorsi di automazione.

Questo e anche il motivo per cui i team che gia eseguono Auditare la sicurezza di Active Directory: checklist pratica o Messa in sicurezza di Active Directory: cosa bloccare prima e come validarlo non dovrebbero trattare gli host Linux amministrativi come esterni al perimetro di assurance dell'identita. Se i tuoi percorsi amministrativi gia derivano nel tempo, lo stesso schema operativo descritto in Deriva degli accessi privilegiati in Active Directory: come i diritti admin ritornano dopo gli audit spesso si applica anche a bastion e tooling Linux adiacente.

Mitigazioni temporanee e loro tradeoff

La storia della mitigazione temporanea e importante perche la guidance ufficiale del vendor non la descrive come un semplice interruttore neutro.

Ubuntu indica che il Security Team ha pubblicato una mitigazione che disabilita il modulo interessato algif_aead tramite il pacchetto kmod mentre vengono distribuiti i pacchetti kernel corretti. SUSE documenta allo stesso modo un workaround che blocca il modulo tramite configurazione modprobe.

Questo e utile, ma comporta tradeoff.

La mitigazione non e neutra sul comportamento

Ubuntu avverte esplicitamente che la mitigazione disabilita un modulo usato per la crittografia accelerata via hardware. Il comportamento atteso e un fallback verso funzioni crittografiche userspace, ma Ubuntu nota anche che alcune applicazioni potrebbero non gestire bene questa transizione. Inoltre, le applicazioni gia in esecuzione possono essere influenzate se il modulo viene disabilitato o scaricato, e potrebbe essere necessario un reboot per forzare un comportamento di fallback coerente.

Questo significa che la decisione di mitigazione deve essere trattata come una vera modifica operativa, non come un semplice flag d'emergenza senza effetti collaterali.

Passo di mitigazione	Beneficio	Tradeoff da validare
Disabilitare `algif_aead` tramite la mitigazione fornita dal vendor	Riduce l'esposizione prima che tutti i fix del kernel siano completamente distribuiti	Può influenzare il comportamento crittografico accelerato via hardware e i processi di lunga durata
Scaricare immediatamente il modulo	Può ridurre la finestra di esposizione sui sistemi in esecuzione	Può richiedere validazione del servizio o reboot per garantire percorsi di fallback attivi
Applicare i pacchetti kernel corretti	Elimina la necessita di una postura basata solo su workaround	Richiede disciplina standard di rollout kernel, pianificazione dei reboot e validazione di versione

La regola pratica e semplice: se usi il workaround, documenta che e temporaneo, valida le applicazioni dipendenti dalla crittografia e conferma poi che il sistema raggiunga uno stato di kernel corretto invece di restare indefinitamente in una postura di mitigazione temporanea.

Come verificare esposizione e stato della patch

La sequenza piu sicura e vendor-first. Non dare per scontato che un semplice headline di versione del kernel visto sui social basti per determinare se una fleet sia esposta.

Verifiche Ubuntu

Ubuntu fornisce comandi concreti nel suo advisory:

uname -r

dpkg -l 'linux-image*' | grep ^ii

dpkg -l kmod

Ubuntu documenta anche come verificare se il modulo interessato e ancora caricato:

grep -qE '^algif_aead ' /proc/modules && echo "Affected module is loaded" || echo "Affected module is NOT loaded"

Queste verifiche sono utili anche oltre Ubuntu perche riflettono la logica corretta: controllare il kernel in esecuzione, controllare i pacchetti installati e controllare separatamente lo stato del modulo.

Verifiche SUSE

SUSE espone una pagina CVE pubblica con stato prodotto/pacchetto e versioni corrette pubblicate. Per ambienti gestiti da SUSE, il percorso autorevole consiste nel confrontare i pacchetti relativi al kernel installati con le versioni elencate nella pagina CVE e negli advisory collegati, invece di affidarsi a una formula generica per famiglia di distribuzione.

Verifiche Red Hat

La pagina pubblica dei bollettini Red Hat mostra RHSB-2026-02 come ongoing, e Red Hat pubblica anche indicazioni pubbliche su come determinare se un prodotto e interessato da una CVE specifica usando il database CVE di Red Hat e i link agli advisory associati. Red Hat ha inoltre pubblicato pagine pubbliche separate per RHEL e OpenShift su CVE-2026-31431, che rappresentano il percorso corretto per una validazione per prodotto.

Cosa registrare durante il triage

Per ogni sistema o gruppo di cluster, registrare almeno:

versione corrente del kernel in esecuzione
versione del pacchetto kernel installato
se algif_aead e caricato
se e stata applicata una mitigazione temporanea
stato dell'advisory del vendor per quella linea di prodotto
se resta un reboot pendente dopo patch o mitigazione

Questo basta per trasformare un headline rumoroso su una vulnerabilita in una vera coda di remediation. Se esegui gia review ricorrenti di infrastruttura, la stessa disciplina di evidenza descritta in Audit ricorrente di Active Directory: perche gli audit annuali derivano e come funziona il monitoraggio continuo della postura si applica qui: catturare lo stato, ripetere la verifica dopo la remediation e conservare la prova che la mitigazione temporanea e stata davvero rimossa.

Cosa validare dopo aver applicato i fix

Una risposta a Copy Fail non dovrebbe fermarsi a "pacchetto aggiornato". La fase di validazione e il luogo in cui si nascondono piu spesso mitigazioni temporanee, reboot pendenti e rollout parziali.

Area di validazione	Come si presenta il successo
Stato del kernel in esecuzione	L'host esegue realmente il kernel corretto atteso e non si limita ad avere il pacchetto presente su disco.
Stato del modulo	`algif_aead` e disabilitato o assente dove la mitigazione temporanea e ancora necessaria, e il suo stato e compreso dopo il patching completo.
Stato del reboot	I sistemi che richiedono un reboot per completare la mitigazione o attivare il kernel corretto non restano in uno stato ambiguo.
Comportamento applicativo	I servizi dipendenti dalla crittografia continuano a funzionare correttamente dopo la disattivazione del modulo o la sostituzione del kernel.
Postura dei nodi container	I nodi che ospitano workload containerizzati vengono verificati tramite il percorso del vendor per OpenShift, ROSA, OSD o la guidance specifica della distribuzione rilevante.
Evidenza di fleet	Ogni ambiente dispone di una fonte vendor registrata, di uno stato di patch e di un'azione residua se il workaround e ancora in uso.

L'errore operativo principale sarebbe trattare il workaround come identico a un fix pienamente validato. La documentazione del vendor non supporta questo approccio. Il workaround compra tempo; il kernel corretto e la validazione post-cambio chiudono il ciclo. Per visibilita di log ed escalazione attorno ai sistemi di identita adiacenti, questo puo essere affiancato a Monitoraggio sicurezza AD: gli Event ID che contano quando l'host Linux interessato si trova su un percorso amministrativo o alimenta una review di incidente piu ampia.

Perche questa CVE resta importante per i team identita e infrastruttura

Copy Fail non appartiene al catalogo di vulnerabilita AD/Azure di EtcSec, e questo articolo non deve fingere il contrario. Ma resta importante per i team identita e infrastruttura perche root locale sul sistema Linux sbagliato cambia piu di un solo host.

Esempi:

bastion usati per amministrare Windows o infrastruttura cloud
nodi Linux che conservano credentials di automazione o segreti di configurazione
nodi OpenShift o container adiacenti a confini di fiducia interni
jump system in ambienti segmentati o air-gapped

Questa e la ragione corretta per coprire qui questa CVE. Non perche si colleghi in modo pulito al catalogo esistente, ma perche la fiducia infrastrutturale, i percorsi amministrativi e l'evidenza di remediation continuano a contare quando il sistema interessato si trova vicino al piano identita.

CVE-2026-31431 (Copy Fail): cosa interessa la vulnerabilita del kernel Linux e come mitigarla