Se gestisci un server Linux (un VPS, un cluster Kubernetes, un runner CI, una macchina di staging) e non hai ancora aggiornato il kernel, hai sicuramente un problema di sicurezza. Chiunque abbia un account utente con una shell sul sistema può adesso diventare root, con meno di 800 byte di codice Python.

La nuova vulnerabilità si chiama Copy Fail, è registrata come CVE-2026-31431 ed è stata resa pubblica ieri dal ricercatore di Theori Taeyang Lee. Era presente nel codice da quasi un decennio. La vulnerabilità è stata scovata tramite Xint Code, la suite AI per fare Source Code Review che è stata usata in questo caso per scansionare le librerie crypto di Linux e scovare la falla.

In pratica, il kernel Linux espone un sottosistema crittografico accessibile dallo spazio utente tramite socket AF_ALG. Nel 2017 è stata introdotta un’ottimizzazione “in-place” nel modulo algif_aead per velocizzare le operazioni di cifratura: invece di copiare i dati, il kernel li utilizza direttamente in memoria.

Il problema è che questa ottimizzazione permette a una pagina della page cache di finire nella lista di destinazione scrivibile di un’operazione crittografica. A quel punto, un processo non privilegiato può usare la funzione splice() per scrivere pochi byte controllati direttamente nella page cache di un file che non possiede. La page cache è la copia in RAM dei file presenti su disco. Linux la usa per velocizzare gli accessi. Se si scrive in quella zona, il file su disco rimane intatto, ma il programma che viene eseguito legge dalla RAM e vede i dati modificati.

A questo punto si sceglie il bersaglio dell’exploit. In questo caso per la Proof of Concept è stato usato /usr/bin/su: un binario setuid che, con solo quattro byte riscritti nel punto corretto, restituisce una shell con privilegi root. La vulnerabilità ricade quindi nella tipologia delle Local Privilege Escalation e si guadagna una severity di 7.8/10. Di seguito possiamo vedere la PoC dell’exploit Copy-Fail su varie distribuzioni Linux, rilasciata al pubblico per la prima volta tramite questo tweet.

L’exploit è disponibile pubblicamente su GitHub e si trova in questa repository.

Per l’occasione, abbiamo testato un exploit anche su un sistema basato su WSL (Windows Subsystem for Linux) e possiamo confermare che è funzionante anche in questo caso, come si vede dall’immagine sottostante.

La questione è quindi molto più grave. Una Local Privilege Escalation richiede l’accesso al sistema, spesso dipende da una race condition poco affidabile, oppure funziona solo su versioni specifiche del kernel. Copy Fail si distingue però su vari aspetti:

• Non ha bisogno di race condition, ovvero l’exploit funziona in modo deterministico e non probabilistico, cioè ogni volta che viene lanciato, se il sistema è vulnerabile, ha successo.
• La page cache è condivisa tra tutti i processi sull’host: un processo all’interno di un container può scrivere nella page cache dell’host e l’isolamento offerto dal container non è sufficiente in questo caso.
• Colpisce tutte le distribuzioni principali come Ubuntu, Amazon Linux, RHEL, SUSE, Debian, Arch, Fedora, qualsiasi sistema con un kernel dal 2017 a oggi è interessato, indipendentemente dalla distribuzione.

Detto questo, quali sarebbero i sistemi più a rischio?

La priorità più alta la hanno i cluster Kubernetes multi-tenant, runner CI/CD che eseguono codice da pull request esterne (GitHub Actions self-hosted, GitLab shared runners, Jenkins), piattaforme SaaS che eseguono codice degli utenti in container, macchine condivise tra più utenti sullo stesso kernel. In queste ore moltissimi cluster multi utente come HPC e sistemi ad uso condiviso ad alte prestazioni (ad esempio cluster di calcolo) sono stati messi in manutenzione per una patch straordinaria. Su queste piattaforme, infatti, un singolo utente malevolo su centinaia di altri utenti potrebbe compromettere l’intero sistema, nonostante le policy RBAC applicate dall’amministratore dell’ecosistema.

In pratica, se il modello di isolamento in uso è basato su container senza l’aggiunta di microVM, gVisor o host dedicati, l’exploit Copy Fail può compromettere il tuo sistema. Siamo di fronte ad una privilege escalation che non si vedeva dai tempi della famosa CVE-2021-4034 che colpiva pkexec.

Serve rimediare urgentemente a questa vulnerabilità e per farlo è necessario aggiornare il kernel al pacchetto che include il commit mainline a664bf3d603d. Le principali distribuzioni stanno rilasciando la fix in queste ore.

Se non è possibile aggiornare immediatamente, si può disabilitare il modulo vulnerabile tramite il seguente comando:

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

Aggiornate subito!