Copy Fail CVE-2026-31431: falla Linux per escalation locale, priorità per container e CI

In sintesi: Copy Fail, tracciata come CVE-2026-31431, è una vulnerabilità del kernel Linux nel percorso algif_aead. Non è una RCE remota da sola, ma consente a un utente locale non privilegiato di elevare i privilegi fino a root su sistemi vulnerabili. Il rischio diventa critico su host multi-tenant, runner CI, ambienti container e piattaforme che eseguono codice di terzi.

Cosa è stato pubblicato

Il sito tecnico copy.fail descrive una falla logica nel kernel Linux che combina authencesn, AF_ALG e splice() fino a ottenere scritture controllate nella page cache. NVD registra CVE-2026-31431 come vulnerabilità risolta nel kernel Linux con il revert dell'ottimizzazione in-place di algif_aead; la severità CNA indicata da kernel.org è 7.8 HIGH.

Secondo i ricercatori, il problema interessa kernel costruiti nel periodo tra il 2017 e la patch, con impatto verificato su più distribuzioni mainstream. Il punto operativo non è la singola distro, ma la presenza di kernel vulnerabile più accesso locale o esecuzione di codice non affidabile.

Come funziona la primitiva

Copy Fail è rilevante perché non assomiglia a molte escalation locali classiche. Non dipende da una race condition fragile e non richiede offset specifici per ogni kernel.

La catena pubblica si può riassumere così:

un processo non privilegiato usa l'interfaccia socket AF_ALG per raggiungere primitive crittografiche del kernel;
il template authencesn passa attraverso un percorso di decrypt che può trattare pagine sorgente e destinazione in modo pericoloso;
splice() consente di coinvolgere pagine della page cache senza scrivere il file su disco nel modo tradizionale;
la conseguenza è una scrittura controllata di pochi byte nella copia cache di un file leggibile;
se il target è un binario setuid, il kernel può eseguire la versione alterata in cache e ottenere escalation.

Il dettaglio importante per i difensori è che il file sul filesystem può non cambiare come ci si aspetterebbe. Controlli basati solo su eventi di scrittura, inotify o hash statici dopo il fatto possono non vedere la manipolazione temporanea della page cache.

Perché è pericolosa nei container

I container condividono il kernel dell'host. Se un workload non fidato riesce a raggiungere AF_ALG e il kernel è vulnerabile, il confine non è più quello del container ma quello del kernel host.

Questo rende Copy Fail più simile a una primitiva di escape che a una semplice escalation "da utente locale" in senso tradizionale. Il rischio cresce quando:

il container non blocca la famiglia socket necessaria;
i profili seccomp sono permissivi;
i runner CI eseguono codice non revisionato;
lo stesso nodo ospita workload con livelli di fiducia diversi;
l'inventario kernel non distingue tra nodo host e immagine container.

Perché container e CI sono in prima linea

Su un server single-tenant, Copy Fail richiede già un accesso locale o una catena con un'altra vulnerabilità. Su ambienti condivisi il rischio cambia:

un runner CI che esegue pull request non fidate può trasformare codice utente in root sul runner;
un container con primitive raggiungibili può colpire un kernel condiviso;
un host di build multi-tenant può diventare punto di pivot;
un account shell compromesso può usare la falla per passare da utente a root;
sandbox e ambienti agentici che eseguono codice di clienti devono considerarla prioritaria.

Per PMI e agenzie, la domanda concreta è: "eseguiamo codice di terzi sui nostri server?". Se la risposta è sì, la priorità sale.

Azioni immediate

Identificare tutti i server Linux con utenti locali multipli, container, runner CI, job di build o sandbox.
Verificare la disponibilità del kernel corretto tramite il vendor della distribuzione.
Aggiornare il kernel e pianificare reboot controllato dove necessario.
Prima della patch, valutare la disabilitazione del modulo algif_aead come mitigazione temporanea, seguendo la guida del vendor e testando eventuali dipendenze AF_ALG.
Per workload non fidati, bloccare la creazione di socket AF_ALG con policy seccomp dove applicabile.
Dopo la patch, controllare utenti, cron, chiavi SSH, servizi systemd e binari setuid su host esposti a codice non affidabile.

Non eseguire proof-of-concept su produzione: anche se alcune modifiche alla page cache non persistono dopo reboot, l'effetto di escalation è reale.

Priorità di intervento

Priorità alta:

Kubernetes e orchestratori container con workload di clienti o fornitori;
self-hosted runner GitHub Actions, GitLab Runner, Jenkins e build farm;
server shell, bastion host e jump host condivisi;
piattaforme SaaS che eseguono codice o script caricati dagli utenti;
server Linux dove una web RCE potrebbe diventare root.

Priorità media:

VPS single-tenant con pochi utenti amministrativi;
server applicativi senza esecuzione di codice di terzi, ma con superficie web esposta;
workstation tecniche usate da sviluppatori con molte dipendenze non controllate.

Cosa monitorare dopo la patch

Per gli host più esposti, controllare:

accessi SSH e sudo nelle ore precedenti alla patch;
nuove chiavi in authorized_keys;
job cron e timer systemd inattesi;
modifiche a utenti privilegiati;
container o job CI eseguiti da sorgenti non fidate;
differenze inattese su binari setuid e configurazioni di sicurezza.

Copy Fail non sostituisce un piano di patch management: lo mette alla prova. Se non esiste inventario dei kernel e dei runner CI, questo è il momento di costruirlo.

Fonti

Come può aiutare SecBox

SecBox può aiutare a inventariare host Linux, isolare pannelli e runner, impostare policy di accesso, verificare esposizione container e creare un piano di patch con finestra di reboot controllata.

Richiedi un controllo urgente dei server Linux