CVE-2026-31431 attivo, CISA: patch container entro 15 maggio
La CISA conferma lo sfruttamento attivo di CVE-2026-31431: PoC da 732 byte, rischio breakout per i container Linux e deadline federale al 15 maggio.
Contenuto
Il 1° maggio 2026 la CISA ha inserito la vulnerabilità di escalation di privilegi locali CVE-2026-31431, soprannominata Copy Fail, nel catalogo KEV, confermando uno sfruttamento attivo in-the-wild contro il kernel Linux.
La falla consente a un processo con privilegi minimi di ottenere root corrompendo la memoria condivisa del kernel attraverso un proof-of-concept di appena 732 byte, già riadattato in Go e Rust.
Per le agenzie federali statunitensi la scadenza per il patching è fissata al 15 maggio 2026, ma il pericolo immediato riguarda ogni infrastruttura containerizzata cloud e on-premise dove l’isolamento tra guest e host può collassare in pochi secondi.
- La CISA ha aggiunto CVE-2026-31431 al catalogo KEV il 1° maggio 2026, riconoscendo lo sfruttamento attivo e imponendo alle agenzie federali una deadline di remediation al 15 maggio.
- Si tratta di una LPE nel sottosistema AF_ALG del kernel Linux (modulo algif_aead) con punteggio CVSS di 7,8: un utente non privilegiato può sovrascrivere 4 byte nel page cache per elevare i privilegi a root.
- L’exploit PoC originale pesa appena 732 byte ed è già stato adattato in Go e Rust, abbassando il barriera all’ingresso per attori minacciosi.
- Ambienti containerizzati come Docker, LXC e Kubernetes sono particolarmente esposti perché i processi interni accedono di default al sottosistema AF_ALG, consentendo il breakout verso l’host fisico sottostante.
Un bug logico vecchio di nove anni nel modulo crittografico
Il bug risiede nel modulo algif_aead del sottosistema AF_ALG del kernel Linux ed è stato introdotto attraverso tre modifiche separate apportate nel 2011, nel 2015 e nel 2017, lasciando le distribuzioni principali vulnerabili per circa nove anni.
La CISA lo classifica come "Linux Kernel contains an incorrect resource transfer between spheres vulnerability that could allow for privilege escalation", assegnando alla falla un punteggio CVSS di 7,8 e inserendola nel KEV catalog il 1° maggio 2026 in applicazione del BOD 22-01.
L’inserimento nel KEV catalog attiva per le agenzie federali statunitensi l’obbligo di remediation entro il 15 maggio 2026, una scadenza che eleva la pressione operativa sui team IT e impone una verifica rapida dell’intero parco macchine Linux.
La vulnerabilità è una local privilege escalation: non è sfruttabile da remoto da sola, ma richiede un accesso locale al sistema o la compromissione di un processo che già esegue sul target.
Come 4 byte nel page cache aprono il root senza toccare il disco
L’attacco sfrutta un errore logico per eseguire un overwrite controllato di 4 byte nel page cache della memoria condivisa, corrompendo l’entry point di un binario setuid caricato in RAM, come ad esempio /usr/bin/su.
"Because the page cache represents the in-memory version of executables, modifying it effectively alters binaries at execution time without touching disk" — Wiz, come riportato da The Hacker News
Corrompendo l’immagine in memoria, l’attaccante ottiene l’esecuzione di codice con UID 0 senza lasciare traccia su disco, sfruttando esclusivamente chiamate di sistema legittime che rendono il manufatto estremamente difficile da rilevare.
Il proof-of-concept originale è uno script Python di 732 byte, ma Kaspersky ha già individuato varianti in Go e Rust in repository open-source, confermando l’evoluzione verso un uso produttivo e l’assenza di tecniche avanzate come race condition o guessing di indirizzi di memoria.
Dai container all’host fisico: il percorso del breakout
Nei container Docker, LXC e Kubernetes, i processi interni hanno accesso di default al sottosistema AF_ALG quando il modulo algif_aead è caricato nell’host kernel, esponendo direttamente la superficie di attacco anche a workload isolati.
Secondo Kaspersky, "Copy Fail poses a risk of breaching container isolation and gaining control over the physical machine", un rischio che si materializza quando un processo non privilegiato all’interno di un pod ottiene root sull’host fisico sottostante, vanificando anni di hardening dell’isolamento.
Il meccanismo è particolarmente insidioso perché non richiede race condition o tecniche avanzate di guessing di indirizzi di memoria, rendendo l’exploit stabile e ripetibile persino in ambienti condivisi e ad alta densità di carico.
Attività preliminari rilevate: l’allerta di Microsoft Defender
Il Microsoft Defender Security Research Team segnala "seeing preliminary testing activity that might result most likely in increased threat actor exploitation over the next few days", indicando che la fase di sfruttamento attivo potrebbe accelerare a breve.
Al momento non è disponibile alcuna attribuzione specifica agli attori minacciosi coinvolti, né metriche ufficiali sulla scala dei tentativi rilevati in-the-wild; CISA conferma lo sfruttamento senza quantificarne il volume.
La comparsa di varianti Go e Rust nei repository open-source, rilevate da Kaspersky, indica che la comunità degli attori minacciosi sta trasformando il codice originale in strumenti più facilmente integrabili nei propri playbook di attacco.
Va precisato che non è in corso un attacco massiccio su larga scala confermato, ma la convergenza tra codice pubblico e testing preliminare suggerisce una finestra di rischio in espansione.
Cosa fare adesso
- Verificare immediatamente la versione del kernel in uso e consultare il vendor della distribuzione per le patch relative ai rami 6.18.22, 6.19.12 e 7.0, tenendo presente che al momento non tutte le distribuzioni hanno ancora reso disponibili gli aggiornamenti.
- Implementare la mitigazione interima disabilitando il modulo algif_aead o applicando regole seccomp che blocchino la creazione di socket AF_ALG, valutando preventivamente l’impatto su eventuali applicazioni crittografiche di produzione che dipendono da quel sottosistema.
- Auditare i cluster Kubernetes e i runtime container per identificare quali pod o servizi accedono al sottosistema AF_ALG senza necessità operativa documentata, riducendo la superficie di attacco.
- Rafforzare il monitoraggio comportamentale sui log di syscall: poiché l’exploit usa solo chiamate di sistema legittime, il rilevamento deve concentrarsi su anomalie di accesso alla memoria condivisa e pattern di scrittura nel page cache piuttosto che su indicatori statici di compromissione.
La lezione operativa è che una singola falla logica persistente nel kernel può retrocedere anni di investimenti sull’isolamento dei container. Per i team DevOps e i SOC la sfida non è solo applicare una patch entro il 15 maggio, ma ricostruire la visibilità su un attacco che non lascia artefatti su disco e parla il linguaggio delle syscall legittime. In questo scenario, la velocità del patching conta tanto quanto la capacità di monitorare ciò che accade in memoria, non sul filesystem: chi gestisce infrastrutture cloud deve agire adesso, prima che l’attività preliminare segnalata da Microsoft diventi exploitation sistematica.
Domande frequenti
Perché Copy Fail è più pericolosa nei container che nei server tradizionali?
Nei container Docker, LXC e Kubernetes i processi interni hanno accesso di default al sottosistema AF_ALG quando il modulo algif_aead è caricato nell’host, permettendo a un attaccante di uscire dall’isolamento e ottenere root sulla macchina fisica sottostante. Su un server tradizionale la stessa falla richiederebbe già un accesso locale al sistema.
Se l’exploit non modifica file su disco, come si può rilevare?
L’attacco utilizza esclusivamente chiamate di sistema legittime e agisce sul page cache in memoria, lasciando il filesystem intatto. Il rilevamento deve quindi spostarsi da indicatori statici su disco a monitoraggio comportamentale delle syscall e anomalie nell’accesso alla memoria condivisa del kernel.
La disabilitazione del modulo algif_aead può bloccare servizi di produzione?
Non è possibile quantificare a priori l’impatto operativo della mitigazione temporanea: applicazioni che dipendono dalle funzioni crittografiche accelerate tramite AF_ALG potrebbero smettere di funzionare, rendendo indispensabile un test in ambiente di staging prima di applicare la restrizione su larga scala.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.