Le 5 CVE che devi aver patchato sul VPS entro ottobre 2026

Il 27 agosto 2026 la CISA ha aggiunto al catalogo delle Known Exploited Vulnerabilities la CVE-2026-53362, una privilege escalation del kernel Linux sfruttabile da un utente senza privilegi attraverso un socket UDPv6. Era la seconda CVE kernel dell'anno a entrarci, dopo la CVE-2026-31431 di maggio, quella che i ricercatori hanno battezzato Copy Fail e che permette di diventare root con uno script di poche centinaia di byte. Nel frattempo altre tre vulnerabilità con exploit pubblico funzionante si sono accumulate sugli stessi sistemi che gestisci tu: kernel, e in un caso una libreria SSH che i tuoi script di automazione probabilmente linkano senza che tu lo sappia. Questo pezzo è la lista corta che avrei voluto trovare pronta a settembre, quando ho fatto il giro di patching su un parco di VPS durante un progetto di migrazione infrastrutturale per una PMI: cinque CVE, per ciascuna cosa fa, come verifichi se ti riguarda e come la chiudi, con i riferimenti agli advisory Debian per non fidarti di me sulla parola. E una morale che anticipo subito, perché è il vero contenuto dell'articolo: quattro di queste cinque vivono nel kernel, quindi si chiudono tutte insieme con un aggiornamento e un riavvio. Se il tuo VPS vanta 400 giorni di uptime, quel numero non è un trofeo: è la misura di quanto sei indietro.

TL;DR

• CVE-2026-31431 "Copy Fail": LPE kernel (interfaccia crypto AF_ALG), in CISA KEV, root da utente qualsiasi. Fix: aggiorna il kernel e riavvia (DSA-6238-1 / DSA-6243-1).
• CVE-2026-53362: LPE kernel via IPv6, in CISA KEV dal 27 agosto. Fix: kernel + riavvio (DSA-6381-1).
• CVE-2026-46333 "ssh-keysign-pwn": race ptrace, un utente locale legge /etc/shadow e le chiavi private host SSH. Fix: kernel + riavvio; mitigazione ponte kernel.yama.ptrace_scope=2.
• CVE-2026-46300 "Fragnesia": LPE kernel con container escape. Fix: kernel + riavvio (DSA-6306-1 / DSA-6295-1).
• CVE-2026-55200: RCE in libssh2 fino alla 1.11.1, lato client. Fix: apt upgrade del pacchetto (DSA-6365-1), niente riavvio ma riavvia i processi che la usano.

> - Verifica rapida: apt changelog linux-image-$(uname -r) | grep -c CVE-2026 e soprattutto: il kernel in esecuzione è quello installato? Se uname -r è più vecchio del pacchetto, devi solo riavviare.

Perché una privilege escalation locale dovrebbe spaventarti su un server remoto?

Perché sul tuo VPS l'"utente locale senza privilegi" esiste già, e non è un collega curioso: è www-data. La catena di attacco standard contro un server web nel 2026 non parte dal kernel, parte dall'applicazione: un plugin WordPress vulnerabile, una deserializzazione PHP, un pannello dimenticato con credenziali deboli. Quel primo passo consegna all'attaccante una shell con i privilegi del web server, che di per sé può fare danni limitati. È la local privilege escalation a trasformare l'incidente in una compromissione totale: da www-data a root, e da root a persistenza, esfiltrazione, movimento laterale verso le altre macchine che si fidano di questa. Le due CVE nel catalogo KEV sono lì proprio perché questa catena è stata osservata sul campo, non in laboratorio: il catalogo CISA censisce solo vulnerabilità con sfruttamento attivo documentato, ed è il motivo per cui lo uso come filtro di priorità quando il tempo di manutenzione è quello che è.

C'è un secondo motivo, più sottile, per cui questa tornata merita attenzione: la varietà dei bersagli intermedi. Una delle cinque non dà root ma legge i segreti sbagliati (le chiavi private con cui il tuo server dimostra la propria identità), e un'altra non attacca il server ma il client SSH dei tuoi script. Sono esattamente i punti ciechi di chi ragiona solo per "il mio sshd è aggiornato": la superficie reale di un VPS è più larga del demone in ascolto. Questo modo di ragionare per catene e superfici, e non per singoli servizi, è lo stesso che applico negli interventi di messa in sicurezza: nel mio profilo professionale trovi come imposto hardening e patching programmato dei VPS Debian e Ubuntu che seguo in produzione.

Una nota di metodo prima della lista, perché spiega la selezione. Il punteggio CVSS misura le caratteristiche intrinseche di una vulnerabilità, non la probabilità che qualcuno la usi contro di te: la ssh-keysign-pwn si ferma a 5.5 eppure consegna le chiavi di casa, mentre decine di CVE da 9 e passa non hanno mai visto un exploit funzionante fuori dai laboratori. Per questo il mio ordine di priorità è un altro: prima ciò che sta in KEV, dove lo sfruttamento è osservato e documentato; poi ciò che ha un proof of concept pubblico e tocca componenti che espongo davvero; solo dopo il resto, in ordine di punteggio. Cinque voci scelte con questo filtro valgono più di un report di vulnerability scanner da duecento pagine ordinato per CVSS decrescente.

Le cinque, una per una

CVE-2026-31431, "Copy Fail": root con uno script minuscolo

È la più grave della lista per rapporto fra semplicità ed effetto. Il difetto sta in algif_aead, l'interfaccia socket che il kernel espone verso la crypto API (AF_ALG): un'operazione in-place gestita male fa divergere le mappature di origine e destinazione dei dati, e il risultato pratico è che un utente senza privilegi può alterare un binario setuid e ottenere root. CVSS 7.8, exploit pubblico compatto, presenza nel catalogo KEV: la tripletta completa. Riguarda praticamente ogni kernel distribuito dal 2017 in poi, quindi la domanda non è se il tuo VPS fosse affetto, ma se sia già stato corretto. Debian l'ha chiusa con gli aggiornamenti del kernel (advisory DSA-6238-1 per trixie e DSA-6243-1 per bookworm); la verifica sul campo è un cerca nel changelog del pacchetto:

apt changelog linux-image-$(uname -r) 2>/dev/null | grep -i CVE-2026-31431

Se il grep trova la voce, la patch è nel pacchetto; resta da controllare che il kernel in esecuzione sia quello (ci torniamo alla fine, ed è il punto dove i parchi macchine falliscono).

CVE-2026-53362: la KEV di agosto, via IPv6

Un errore di conteggio in __ip6_append_data() porta una scrittura oltre la fine del buffer di un socket buffer quando si usano certe combinazioni di flag su un socket UDPv6, e da lì si costruisce una escalation a root. Non serve che il tuo server "usi" IPv6 in senso applicativo: basta che lo stack sia abilitato, e su Debian e Ubuntu lo è di default. È in KEV dal 27 agosto 2026, cioè con sfruttamento attivo osservato, e Debian l'ha corretta con il DSA-6381-1. Anche qui: kernel, quindi aggiornamento più riavvio, nessuna configurazione da toccare. Se stai pensando di disabilitare IPv6 come mitigazione, il mio consiglio è di non usare una CVE come pretesto per una scelta d'architettura: la patch esiste, la disabilitazione di IPv6 nel 2026 crea più problemi operativi di quanti ne risolva.

CVE-2026-46333, "ssh-keysign-pwn": il ladro di chiavi host

Questa è la più interessante da capire, perché non dà root: legge. Una race nella logica di dumpability di ptrace permette a un utente locale di leggere la memoria di processi privilegiati lanciati da binari setuid e setgid, e i ricercatori hanno dimostrato le due letture che contano: il contenuto di /etc/shadow attraverso chage, e le chiavi private host di OpenSSH attraverso ssh-keysign, come documentato nel dettaglio pubblicato da Canonical. Il CVSS dice 5.5, e sarebbe un errore fermarsi lì: con le chiavi host del tuo server, un attaccante può impersonarlo in un attacco on-path, e i client che si connettono non vedranno nessun avviso, perché la chiave è quella "giusta". Divulgata il 15 maggio 2026, exploit pubblico, corretta nei kernel Debian con DSA-6274-1 (trixie) e DSA-6275-1 (bookworm). Se per qualche motivo non puoi riavviare subito, esiste una mitigazione ponte documentata:

sysctl -w kernel.yama.ptrace_scope=2
# persistente: echo "kernel.yama.ptrace_scope = 2" > /etc/sysctl.d/99-yama.conf

che limita ptrace ai processi con CAP_SYS_PTRACE. E se il sospetto di compromissione è concreto, dopo la patch le chiavi host vanno rigenerate: è una delle azioni del protocollo che ho descritto nella gestione urgente delle intrusioni su VPS Debian e Ubuntu.

CVE-2026-46300, "Fragnesia": l'escape dal container

Un difetto nella gestione dei frammenti condivisi durante la coalescenza dei socket buffer, sfruttabile fin dai kernel 3.9, con esito di privilege escalation e, nelle configurazioni con container, di evasione dal container verso l'host. Exploit pubblico anche qui. Se sul VPS fai girare Docker o Podman, questa è la CVE che rompe l'assunzione su cui hai costruito l'isolamento: il container compromesso che resta un problema del container. Non è così, e non lo è mai stato del tutto: il confine di sicurezza vero resta il kernel condiviso, e ogni LPE kernel è potenzialmente un'evasione. Debian ha corretto con DSA-6295-1 (trixie) e DSA-6306-1 (bookworm). La verifica e il fix sono gli stessi dei casi precedenti: pacchetto kernel aggiornato, riavvio, e nel dubbio il grep sul changelog.

CVE-2026-55200: libssh2, l'unica che non sta nel kernel

Chiudo con quella diversa, che è anche quella che più facilmente ti sfugge: un out-of-bounds write in ssh2_transport_read() di libssh2, fino alla versione 1.11.1 inclusa, CVSS 8.3. La direzione dell'attacco è ribaltata rispetto all'intuizione: il bersaglio è il client. Un server SSH malevolo, o compromesso, invia pacchetti con un campo di lunghezza artefatto e corrompe la memoria del client che si è connesso, fino all'esecuzione di codice. Ti riguarda se i tuoi script di automazione, i tuoi job di backup verso storage remoti, o le tue applicazioni PHP con l'estensione ssh2 si connettono a macchine che non controlli al cento per cento: in quel modello di fiducia, ogni endpoint remoto è un potenziale attaccante del tuo automatismo. Debian ha pubblicato il DSA-6365-1; il fix è un normale apt upgrade del pacchetto, senza riavvio della macchina, ma con un dettaglio che spesso si dimentica: i processi a lunga vita che hanno la libreria caricata continuano a usare la versione vecchia finché non li riavvii. needrestart te li elenca senza fatica.

La procedura completa in un quarto d'ora

Ricapitolo in forma operativa, nell'ordine in cui la eseguo io su ogni macchina. Primo: aggiornamento pieno di indice e pacchetti, apt update && apt upgrade, controllando che arrivino sia il kernel sia libssh2. Secondo: needrestart per i servizi che tengono in memoria librerie vecchie. Terzo, il passo che separa chi è patchato da chi crede di esserlo: il riavvio. Il pacchetto kernel nuovo sul disco non protegge niente finché in esecuzione c'è quello vecchio, e la verifica è un confronto banale fra uname -r e l'ultima versione installata in /boot. Quarto: la mitigazione yama se e finché un riavvio non è possibile, sapendo che è un ponte, non una destinazione. Quinto: un giro di debsecan o del changelog per confermare che le cinque sigle di questo articolo risultino chiuse sul tuo sistema specifico, perché la fiducia va bene ma il grep è meglio.

Sesto, per non rifare tutto a mano il mese prossimo: unattended-upgrades installa anche i kernel nuovi, ma di suo non riavvia mai la macchina. Senza una finestra di riavvio pianificata ti costruisce con precisione la falsa sicurezza di cui sopra: pacchetti freschi sul disco, kernel vecchio in esecuzione. Le opzioni sane sono due: riavvii calendarizzati in una finestra concordata con chi usa i servizi, oppure la direttiva Unattended-Upgrade::Automatic-Reboot con orario notturno, accettabile sulle macchine singole i cui servizi ripartono da soli. Per l'audit periodico uso debsecan, che confronta i pacchetti installati con il database delle CVE di Debian e restituisce ciò che resta aperto sul tuo sistema specifico:

apt install -y debsecan
debsecan --suite trixie --only-fixed
# elenca le CVE con fix disponibile ma non ancora installato sulla macchina

Il patching di un VPS non fallisce quasi mai per mancanza di pacchetti: fallisce per riavvii rimandati. Il kernel aggiornato sul disco e mai caricato è la forma più diffusa di falsa sicurezza che incontro nei subentri.

Due note di contesto per chiudere il quadro. Se le tue macchine sono ancora su Debian 12, gli advisory citati arrivano ormai dal progetto LTS con le sue regole di copertura selettiva: ho spiegato cosa significa davvero bookworm in LTS e cosa controllare in un pezzo dedicato. E se ti stai chiedendo che fine abbia fatto la vulnerabilità di systemd-nspawn di cui si è parlato quest'anno, non è in questa lista perché l'ho già trattata a fondo nell'articolo su systemd 257, le novità e i CVE da patchare: vale la pena leggerlo in coppia con questo. La manutenzione di sicurezza di un server non è un evento, è un ciclo: le cinque CVE di oggi saranno sostituite da altre cinque, e ciò che resta costante è il metodo, aggiornare, riavviare, verificare sul changelog, non fidarsi dell'uptime. Se preferisci che questo ciclo su un parco di VPS lo imposti e lo verifichi qualcuno che lo fa di mestiere, patch management, finestre di riavvio programmate e controllo post-patch inclusi, contattami per una consulenza: il primo giro completo di verifica su un parco piccolo richiede tipicamente mezza giornata, e da lì in avanti diventa routine misurabile.