Indice dei contenuti dell'articolo:
CVE-2026-23111 è una vulnerabilità del kernel Linux nel sottosistema Netfilter / nf_tables che consente, in determinate condizioni, a un utente locale non privilegiato di ottenere privilegi di root. Non si tratta di una vulnerabilità remota sfruttabile direttamente via rete, ma di una falla di Local Privilege Escalation, cioè una vulnerabilità utile a un attaccante che abbia già ottenuto un accesso limitato al sistema, una shell utente, l’esecuzione di codice tramite una web application compromessa o un punto d’appoggio dentro un container.
La vicenda è interessante perché il bug nasce da una condizione logica invertita: un singolo carattere, il simbolo !, cambia il comportamento atteso del codice e apre la strada a un use-after-free nel kernel. In termini pratici, il problema riguarda sistemi Linux che espongono contemporaneamente nf_tables e user namespaces, una combinazione abbastanza comune su molte distribuzioni moderne.
Per un provider di hosting, un amministratore di sistemi Linux o chi gestisce server multi-tenant, container host, ambienti CI/CD, nodi Kubernetes, VPS o server con utenti shell, questa CVE merita attenzione immediata. Il rischio non è tanto quello di un attacco diretto dall’esterno, quanto la possibilità che una compromissione iniziale relativamente limitata venga trasformata in controllo completo del sistema.
Cos’è nf_tables e perché è coinvolto
nf_tables è il framework moderno del kernel Linux usato da nftables, successore di iptables, ip6tables, arptables ed ebtables. È il componente che permette di definire regole di filtraggio, NAT, mangling e classificazione del traffico di rete. Anche quando l’amministratore non usa direttamente il comando nft, il sottosistema può essere presente e utilizzato indirettamente da firewall manager, container runtime, orchestratori o tool di sistema.
La vulnerabilità CVE-2026-23111 interessa una funzione specifica, nft_map_catchall_activate(), coinvolta nella gestione degli elementi “catchall” delle mappe nftables durante l’abort di una transazione. nftables lavora infatti con un modello transazionale: le modifiche alle regole vengono preparate e poi applicate o annullate. Quando qualcosa va storto, il kernel deve ripristinare correttamente gli elementi che erano stati temporaneamente disattivati.
Il problema è che in questo caso la logica era invertita. La funzione avrebbe dovuto saltare gli elementi già attivi e riattivare quelli inattivi. Invece, a causa di una negazione errata, faceva il contrario: saltava gli elementi inattivi e processava quelli attivi. La correzione upstream è concettualmente minima:
- if (!nft_set_elem_active(ext, genmask))
+ if (nft_set_elem_active(ext, genmask))
continue;
Questo è il classico esempio in cui una modifica apparentemente banale nel codice sorgente del kernel ha conseguenze di sicurezza molto serie. Il codice vulnerabile può portare a una gestione errata dei riferimenti interni alle chain nftables; ripetendo determinate operazioni, il reference count può essere decrementato in modo non corretto fino a consentire la liberazione di una struttura ancora referenziata. Da qui nasce il use-after-free, una delle classi di bug più pericolose nel kernel.
Use-after-free nel kernel: perché è grave
Un use-after-free si verifica quando il software continua a usare un’area di memoria dopo averla liberata. In user space può già essere un problema importante; nel kernel è molto più grave, perché il kernel è il componente con il massimo livello di privilegio del sistema operativo. Se un attaccante riesce a influenzare il riuso di quella memoria, può arrivare a corrompere strutture interne, deviare il flusso di esecuzione o manipolare credenziali e privilegi.
Nel caso di CVE-2026-23111, il bug diventa sfruttabile quando un utente non privilegiato può raggiungere il codice vulnerabile attraverso la combinazione di user namespaces e nftables. Gli user namespaces permettono a un processo non privilegiato di apparire come root all’interno di un namespace isolato. Questa funzionalità è utile per container rootless, sandbox, build isolate e alcune tecnologie desktop, ma aumenta anche la superficie di attacco del kernel.
Il punto importante è questo: anche se l’utente non è root sull’host, dentro un namespace può ottenere capacità sufficienti per interagire con alcune parti del kernel che normalmente non sarebbero accessibili. Se una di queste parti contiene una vulnerabilità, l’isolamento può diventare un ponte verso l’escalation.
Non è una RCE remota, ma non va sottovalutata
È importante evitare allarmismi imprecisi: CVE-2026-23111 non è una Remote Code Execution esposta direttamente su Internet. Un server non viene compromesso semplicemente perché ha una porta aperta. Tuttavia, in sicurezza Linux le vulnerabilità locali sono spesso decisive nella fase successiva all’intrusione.
Un attaccante può ottenere inizialmente un accesso limitato tramite una web application vulnerabile, un plugin WordPress compromesso, credenziali SSH deboli, una chiave rubata, un processo in container o un servizio eseguito con privilegi ridotti. A quel punto una Local Privilege Escalation permette di passare da un utente limitato a root, rendendo molto più difficile il contenimento dell’incidente.
Per questo motivo la vulnerabilità va considerata particolarmente rilevante nei seguenti scenari:
- server di hosting condiviso con più utenti locali;
- server con accessi SSH concessi a clienti, sviluppatori o fornitori;
- container host Docker, Podman, LXC o Kubernetes;
- runner CI/CD che compilano o testano codice non completamente fidato;
- ambienti multi-tenant;
- server web in cui una compromissione applicativa potrebbe fornire una shell limitata;
- sistemi con user namespaces abilitati per utenti non privilegiati.
Su un server classico, senza utenti locali non fidati e senza container rootless, l’urgenza può essere inferiore, ma il kernel va comunque aggiornato. In ambito professionale non è consigliabile lasciare una vulnerabilità kernel nota e con dettagli tecnici pubblici in attesa indefinita.
Distribuzioni coinvolte e stato delle patch
La vulnerabilità è stata corretta upstream nel kernel Linux e tracciata pubblicamente come CVE-2026-23111 nel National Vulnerability Database. Ubuntu la classifica come vulnerabilità ad alta priorità, descrivendo esplicitamente la possibilità di escalation locale tramite user namespaces e nftables. Debian la traccia nel proprio Security Tracker, con versioni corrette per i rami supportati.
Per il mondo Enterprise Linux, AlmaLinux ha incluso la CVE negli aggiornamenti kernel. In particolare, per AlmaLinux 9 la vulnerabilità è presente nell’advisory ALSA-2026:6570, mentre per AlmaLinux 10 è presente nell’advisory ALSA-2026:18134. Anche Rocky Linux e le distribuzioni derivate da RHEL tracciano la correzione negli aggiornamenti dei pacchetti kernel.
Il consiglio operativo è semplice: non tentare di patchare manualmente il sorgente del kernel su server di produzione. Bisogna installare il kernel corretto fornito dal vendor della distribuzione e riavviare il sistema nel nuovo kernel.
Come verificare rapidamente il sistema
Il primo controllo è la versione del kernel attualmente in esecuzione:
uname -r
Questo comando mostra il kernel realmente avviato, non semplicemente l’ultimo kernel installato. È una distinzione fondamentale: dopo un aggiornamento dei pacchetti kernel, il sistema rimane vulnerabile finché non viene riavviato nel kernel corretto.
Per verificare se i moduli nftables sono presenti o caricati:
lsmod | grep -E 'nf_tables|nft'
Per controllare le opzioni di configurazione del kernel:
zgrep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /proc/config.gz 2>/dev/null || \
grep -E 'CONFIG_USER_NS|CONFIG_NF_TABLES' /boot/config-$(uname -r)
Se il sistema espone sia CONFIG_USER_NS sia CONFIG_NF_TABLES, occorre considerare la macchina potenzialmente esposta, a meno che il vendor abbia già fornito una patch applicata e il server sia stato riavviato nel kernel corretto.
Su AlmaLinux, Rocky Linux, RHEL e derivate è utile verificare anche il valore di user.max_user_namespaces:
sysctl user.max_user_namespaces
Un valore maggiore di zero indica che il sistema permette la creazione di user namespaces fino al limite configurato. Un valore pari a zero disabilita di fatto la creazione di user namespaces.
Come patchare su AlmaLinux, Rocky Linux e RHEL-like
Su AlmaLinux e sistemi Enterprise Linux compatibili, la procedura consigliata è aggiornare i pacchetti kernel tramite dnf:
dnf clean all
dnf update -y 'kernel*'
reboot
Dopo il riavvio, controllare nuovamente il kernel in esecuzione:
uname -r
rpm -q kernel kernel-core kernel-modules
Per capire se un riavvio è ancora necessario dopo l’aggiornamento, è possibile usare:
dnf install -y yum-utils
needs-restarting -r
Se il comando indica che il sistema deve essere riavviato, il kernel aggiornato non è ancora in esecuzione. In un contesto server, soprattutto hosting o container host, questo passaggio non va ignorato: aggiornare gli RPM senza riavviare non elimina il rischio.
Mitigazione temporanea: disabilitare gli user namespaces
Quando non è possibile riavviare immediatamente, una mitigazione efficace consiste nel disabilitare la creazione di user namespaces da parte degli utenti non privilegiati. Su AlmaLinux, Rocky Linux e RHEL-like la strada corretta è agire sul parametro user.max_user_namespaces:
cat > /etc/sysctl.d/99-disable-userns.conf <<'EOF'
user.max_user_namespaces = 0
EOF
sysctl --system
La verifica si esegue con:
sysctl user.max_user_namespaces
L’output atteso è:
user.max_user_namespaces = 0
Questa mitigazione riduce la superficie d’attacco perché impedisce agli utenti non privilegiati di creare user namespaces. Tuttavia, non è una patch. Serve solo a guadagnare tempo fino al riavvio nel kernel corretto.
Bisogna inoltre considerare gli effetti collaterali. Disabilitare gli user namespaces può rompere container rootless, Podman rootless, Buildah rootless, alcuni ambienti di build, sandbox e strumenti che dipendono da questa funzionalità. Su un classico server hosting con stack web, database, mail e pannelli come Plesk o cPanel, la mitigazione è spesso accettabile. Su un nodo container o su ambienti di sviluppo evoluti va invece valutata con maggiore attenzione.
Debian e Ubuntu: differenze operative
Su Debian e Ubuntu la patch si applica normalmente aggiornando i pacchetti kernel:
apt update
apt full-upgrade -y
reboot
Dopo il riavvio:
uname -r
dpkg -l 'linux-image*' | grep '^ii'
Su queste distribuzioni può essere presente anche il parametro:
kernel.unprivileged_userns_clone
Per una mitigazione temporanea su Debian/Ubuntu è quindi frequente vedere:
sysctl -w kernel.unprivileged_userns_clone=0
printf 'kernel.unprivileged_userns_clone = 0\n' > /etc/sysctl.d/99-disable-unpriv-userns.conf
sysctl --system
Questo parametro non va dato per scontato su AlmaLinux o RHEL-like. In quell’ambito il parametro più corretto da usare è user.max_user_namespaces.
Priorità di intervento per chi gestisce hosting e server Linux
In un’infrastruttura reale, non tutti i sistemi hanno la stessa priorità. La classificazione pratica potrebbe essere la seguente.
Priorità massima per host che eseguono container, ambienti Kubernetes, server multi-tenant, macchine con shell utenti, sistemi CI/CD e server che eseguono codice di clienti o sviluppatori non completamente fidati.
Priorità alta per server web esposti a Internet, anche se non concedono shell dirette. Una vulnerabilità applicativa in WordPress, Magento, PrestaShop, Joomla o in un plugin può fornire un primo accesso locale, e una CVE kernel di questo tipo può trasformare quell’accesso limitato in compromissione completa.
Priorità ordinaria ma necessaria per server isolati, senza utenti locali e senza container. Anche in questo caso la patch va applicata, ma la finestra di manutenzione può essere pianificata con minore urgenza rispetto a un ambiente multi-tenant.
Perché il patching del kernel richiede disciplina
Le vulnerabilità locali del kernel vengono talvolta sottovalutate perché non espongono direttamente un servizio di rete. È un errore. In una catena d’attacco moderna, la fase più difficile non è sempre ottenere un primo accesso: spesso è mantenerlo, elevarlo e muoversi lateralmente. Una Local Privilege Escalation affidabile è esattamente ciò che consente a un attaccante di trasformare un incidente limitato in un problema infrastrutturale.
Nel caso di CVE-2026-23111, il rischio è aumentato dal fatto che sono stati pubblicati dettagli tecnici e riproduzioni indipendenti. Questo non significa che ogni sistema sia automaticamente compromesso, ma significa che la finestra tra divulgazione pubblica e sfruttamento reale si riduce. Quando un bug del kernel diventa comprensibile, riproducibile e documentato, il tempo gioca a favore degli attaccanti.
Conclusione
CVE-2026-23111 è una vulnerabilità tecnicamente elegante e operativamente pericolosa: un singolo carattere errato nel codice di nf_tables può portare a un use-after-free sfruttabile per escalation locale a root. Non è una vulnerabilità remota diretta, ma è molto rilevante in tutti gli ambienti in cui un utente non privilegiato, un container o un processo compromesso possono interagire con il kernel attraverso user namespaces e nftables.
La raccomandazione è netta: aggiornare il kernel dal repository ufficiale della propria distribuzione e riavviare. In attesa del reboot, su AlmaLinux e distribuzioni RHEL-like è possibile mitigare temporaneamente impostando user.max_user_namespaces = 0, valutando però l’impatto su container rootless e sandbox.
Per chi gestisce infrastrutture hosting, server Linux e ambienti multi-tenant, questa CVE ricorda un principio fondamentale: la sicurezza non si limita al patching delle applicazioni web. Il kernel, i namespace, il firewalling e le funzionalità apparentemente “di basso livello” sono parte integrante della superficie d’attacco. Un sistema aggiornato, riavviato nel kernel corretto e configurato con una superficie minima resta la base più solida per ridurre il rischio operativo.
