CVE-2026-46300: vulnerabilità del kernel Linux sfruttata, come verificare l'esposizione e applicare il fix

CVE-2026-46300 è una vulnerabilità del kernel Linux pubblicata il 28 ottobre 2026 e già inserita da CISA nel catalogo KEV, l'elenco delle falle sfruttate attivamente. Riguarda la gestione dei pacchetti IPsec (ESP) e, concatenata con altre due vulnerabilità, permette a un attaccante di installare webshell PHP ed eseguire comandi come root. Se gestisci server Linux, in particolare con VPN IPsec o applicazioni PHP raggiungibili da internet, devi verificare la versione del kernel e aggiornare.

Cosa è successo

Il titolo ufficiale è Linux Kernel Missing Initialization of a Variable Vulnerability. In pratica, una variabile non viene inizializzata correttamente quando il kernel unisce più frammenti di pacchetto (socket buffer coalescing). In questa fase si perde il marcatore che indica un frammento condiviso. Il risultato è che il codice di ricezione ESP, cioè la parte di IPsec che decifra il traffico in ingresso, decifra quei frammenti direttamente in memoria, modificando dati che appartengono alla page cache e che non dovrebbero essere toccati.

Da sola è una corruzione di memoria. Il problema è la catena: le fonti indicano che CVE-2026-46300 viene combinata con CVE-2026-109618 e CVE-2026-109619 per impiantare webshell PHP ed eseguire comandi con privilegi di root. È esattamente questo uso concatenato che è stato osservato in attacchi reali.

Chi è colpito

Il prodotto interessato è il kernel Linux. Le fonti disponibili non indicano un elenco preciso di versioni vulnerabili. I sei commit pubblicati su kernel.org riguardano i rami stable, il che suggerisce che più serie di kernel abbiano ricevuto la correzione. Quali versioni esatte siano affette e quali siano quelle corrette va verificato direttamente sui commit linkati in fondo e sui bollettini della tua distribuzione (Debian, Ubuntu, RHEL, Rocky, AlmaLinux, SUSE e derivate).

Sono esposti in modo più diretto i sistemi che:

• terminano tunnel IPsec, cioè gateway VPN, firewall su base Linux, router e appliance che usano il kernel Linux;
• ospitano applicazioni PHP raggiungibili da internet, perché la catena di sfruttamento si chiude con una webshell PHP;
• sono VPS o server dedicati con kernel non aggiornato da tempo.

Quanto è grave

Il punteggio CVSS non è ancora stato assegnato. Questo non va letto come un segnale di bassa gravità: CISA l'ha inserita nel catalogo KEV, quindi lo sfruttamento attivo è confermato, e ha fissato per le agenzie federali statunitensi una scadenza di rimedio al 31 ottobre 2026, tre giorni dopo la pubblicazione. Una finestra così stretta è rara e indica urgenza.

L'uso in campagne ransomware è indicato come sconosciuto. Quello che un attaccante può ottenere, secondo la descrizione ufficiale, è:

• modificare dati in page cache attraverso traffico ESP malformato;
• concatenare la falla con CVE-2026-109618 e CVE-2026-109619;
• scrivere una webshell PHP sul server;
• eseguire comandi come root, quindi con controllo completo della macchina.

Da root si leggono database, si copiano backup, si creano utenti persistenti e ci si muove verso altri sistemi della rete. Non è un rischio confinato al singolo server.

Come capire se sei esposto

Tre controlli, nell'ordine.

1. Versione del kernel

Da terminale: uname -r. Confronta il risultato con le versioni corrette indicate nei commit su kernel.org e nel bollettino della tua distribuzione. Su Debian e Ubuntu puoi vedere il pacchetto installato con dpkg -l | grep linux-image; su RHEL e derivate con rpm -q kernel. Ricorda che un kernel aggiornato ma non ancora caricato non protegge: dopo l'update serve il riavvio.

2. Uso di IPsec

Verifica se il sistema gestisce tunnel ESP: ip xfrm state e ip xfrm policy mostrano le associazioni e le policy IPsec attive. Controlla anche se strongSwan, Libreswan o servizi equivalenti sono in esecuzione con systemctl list-units | grep -i -E 'swan|ipsec'. Dall'esterno, verifica se le porte UDP 500 e 4500 e il protocollo ESP (IP protocol 50) sono raggiungibili da internet, con una scansione dalla rete esterna o guardando le regole del firewall perimetrale.

3. Indicatori di compromissione

La catena termina con una webshell PHP, quindi cerca file PHP modificati o creati di recente nelle directory web: find /var/www -name '*.php' -mtime -7 è un punto di partenza. Controlla processi avviati dall'utente del web server che non c'entrano con il servizio, nuovi utenti in /etc/passwd, chiavi aggiunte in ~/.ssh/authorized_keys, cron job sconosciuti e voci anomale nei log di accesso del web server e in /var/log/auth.log o nel journal. Se usi WordPress, i controlli che descrivo nell'articolo su come verificare la sicurezza di un sito WordPress sono utili anche qui.

Come risolvere la vulnerabilità: patch, aggiornamento e rimedio

La correzione esiste a livello di codice: sono i sei commit sui rami stable di kernel.org elencati nelle fonti. Le versioni corrette per ciascun ramo e la disponibilità del pacchetto aggiornato per la tua distribuzione vanno verificate sull'advisory del produttore e sul bollettino di sicurezza della distribuzione, perché i tempi di rilascio variano.

In pratica l'aggiornamento si applica così:

1. Debian e Ubuntu: apt update && apt upgrade, poi verifica che sia arrivato il nuovo pacchetto linux-image.
2. RHEL, Rocky, AlmaLinux: dnf update kernel.
3. SUSE: zypper update.
4. Riavvio obbligatorio per caricare il nuovo kernel, poi di nuovo uname -r per conferma.

Per appliance e firewall basati su Linux, cerca l'aggiornamento firmware del produttore: non puoi intervenire sul kernel da solo. Se la tua distribuzione non ha ancora pubblicato il pacchetto, non è il caso di aspettare passivamente: passa alle mitigazioni.

Cosa fare subito

1. Aggiorna il kernel e riavvia su tutti i sistemi Linux esposti a internet, iniziando da gateway VPN e server web con PHP.
2. Riduci l'esposizione di IPsec. Se non puoi aggiornare, limita con il firewall gli indirizzi sorgente che possono raggiungere UDP 500, UDP 4500 ed ESP ai soli peer noti. CISA indica che, se non esistono mitigazioni, va valutata la sospensione del servizio.
3. Verifica l'esposizione delle applicazioni PHP. Chiudi pannelli di amministrazione non necessari, blocca l'esecuzione di PHP nelle cartelle di upload, controlla i permessi di scrittura sulle directory web.
4. Ruota le credenziali dei sistemi interessati: password di root e amministratore, chiavi SSH, segreti IPsec (PSK e certificati), credenziali dei database raggiungibili dal server.
5. Controlla i backup. Assicurati che esista una copia recente, non collegata in modo permanente al server, e che sia ripristinabile. Se non hai mai verificato il ripristino, questo è il momento: ne parlo nell'articolo sul piano di disaster recovery per le PMI.
6. Censisci gli asset. Spesso il server dimenticato è quello compromesso: elenca ogni macchina Linux, inclusi VPS di test, NAS e appliance.

Se sospetti di essere già stato colpito

Se trovi una webshell, un processo anomalo o accessi non spiegabili, non spegnere il server e non cancellare nulla. Spegnere distrugge la memoria volatile, dove spesso si trovano le tracce più utili, e cancellare file rende impossibile ricostruire cosa è stato preso.

• Isola la macchina dalla rete a livello di firewall o switch, lasciandola accesa.
• Preserva i log del web server, del sistema, del firewall e del VPN gateway, copiandoli su un supporto separato.
• Annota orari e azioni fatte: servirà per la ricostruzione e per eventuali obblighi di notifica previsti dal GDPR se sono coinvolti dati personali.
• Fai eseguire un'acquisizione forense prima di qualsiasi bonifica, così da avere una copia integra su cui lavorare.

Un intervento di incident response con analisi forense permette di capire il punto di ingresso, l'estensione della compromissione e cosa va bonificato o ricostruito da zero. Nel mio studio un incarico di incident response parte da 1.500 € e un audit di sicurezza completo da 2.000 €, sempre con preventivo a prezzo fisso. Trovi il dettaglio nella pagina dei servizi dello studio.

Fonti

• Commit kernel.org stable 3599e6b3
• Commit kernel.org stable 2f2b1602
• Commit kernel.org stable 9d3e5fd1
• Commit kernel.org stable 78bf6b6b
• Commit kernel.org stable 760e1add
• Commit kernel.org stable 3bd9e113

Hai server Linux e non sai da dove cominciare?

Se gestisci una PMI e non hai un responsabile IT interno, posso verificare con te l'esposizione dei tuoi sistemi, applicare gli aggiornamenti e controllare se ci sono segni di compromissione. Lavoro da remoto per tutta Italia e di persona a Varese, Como e Milano. Puoi richiedere un preventivo gratuito, ricevi risposta entro 24 ore, oppure scrivermi direttamente dalla pagina contatti, anche su WhatsApp.