CVE-2026-46333: Falla Kernel Linux di 9 Anni — Guida Protezione PMI

Il 20 maggio 2026 i ricercatori della Qualys Threat Research Unit (TRU) hanno divulgato i dettagli di CVE-2026-46333, una vulnerabilità nel kernel Linux che è rimasta nascosta per nove anni. La falla, un errore logico nella funzione __ptrace_may_access() del sottosistema di tracing dei processi, consente a un utente locale non privilegiato di leggere file che normalmente richiederebbero accesso root: chiavi private SSH e l'intero file /etc/shadow con gli hash delle password. Colpisce le installazioni predefinite di Debian, Fedora e Ubuntu, ovvero la stragrande maggioranza dei server Linux in produzione nelle piccole e medie imprese italiane. È la quarta vulnerabilità locale del kernel Linux resa pubblica in tre settimane, dopo Copy Fail, Dirty Frag e Fragnesia. E a differenza delle precedenti, questa consegna all'attaccante le chiavi del regno in un colpo solo.

Saeed Abbasi, senior manager della Qualys TRU, ha descritto la tecnica come capace di «trasformare qualsiasi shell locale in un percorso verso root o verso materiale crittografico sensibile» [infosecurity-magazine.com]. Il punteggio CVSS ufficiale è 5.5, ma Qualys stessa sottolinea come la distinzione tra un accesso non privilegiato e la compromissione totale dell'host collassi nella pratica: i file divulgati sono sufficienti per prendere il controllo completo del sistema.

Per il sysadmin di una PMI italiana che gestisce uno o più server Linux — che si tratti del portale web aziendale, del server di posta o dell'infrastruttura che ospita applicativi gestionali — non è una notizia da archiviare. È un problema da risolvere lunedì mattina.

Come funziona la vulnerabilità

Il cuore del bug risiede nella funzione __ptrace_may_access(), il meccanismo con cui il kernel decide se un processo può tracciare (ptrace) un altro processo. Durante l'uscita di un processo privilegiato, esiste una finestra temporale strettissima in cui il processo ha già rilasciato il proprio descrittore di memoria (mm) ma mantiene ancora aperti i propri descrittori di file. In quella finestra, il controllo dumpable — che dovrebbe bloccare l'accesso esterno — viene saltato perché il kernel non trova un mm valido da verificare [qualys.com].

Un attaccante che esegue codice sotto lo stesso UID può sfruttare la syscall pidfd_getfd() (introdotta nel kernel Linux a gennaio 2020 con la versione 5.6-rc1) per catturare i descrittori di file ancora aperti dal processo morente e duplicarli con i propri privilegi. Se quei descrittori puntano a file aperti dal binario privilegiato prima di rilasciare i privilegi — come le chiavi host SSH aperte da ssh-keysign o /etc/shadow aperto da chage — l'attaccante ne ottiene una copia perfettamente utilizzabile [qualys.com].

In sintesi, il flusso dell'attacco è il seguente:

1. Race condition su setuid binary: l'attaccante lancia ripetutamente un binario setuid (es. ssh-keysign) e cerca di agganciarlo con pidfd_getfd() durante la finestra di uscita.
2. Cattura del descrittore: quando la race va a segno, l'attaccante duplica il descrittore di file che punta alla chiave privata SSH ancora aperta dal processo.
3. Lettura del contenuto: con il descrittore in mano, il file system non oppone resistenza: il descrittore è già autorizzato. Il contenuto della chiave viene letto integralmente.
4. Escalation: con la chiave SSH host, l'attaccante può impersonare il server; con /etc/shadow può craccare le password offline o usarle per autenticarsi.

Qualys ha sviluppato quattro proof-of-concept funzionanti, tutti trattenuti durante la finestra di divulgazione coordinata. Due riguardano la divulgazione di informazioni (ssh-keysign e chage), due consentono l'esecuzione di comandi arbitrari come root (pkexec e accounts-daemon). Il PoC per pkexec è sfruttabile persino da remoto via SSH, se esiste una sessione console allow_active [orca.security].

Quali sistemi sono a rischio

La vulnerabilità interessa tutti i kernel Linux mainline dalla versione 4.10-rc1 (novembre 2016) fino al commit di fix del 14 maggio 2026. Nove anni di kernel, con pidfd_getfd() che ha allargato la superficie d'attacco a partire dal kernel 5.6 (gennaio 2020).

Le distribuzioni confermate come vulnerabili nelle configurazioni predefinite sono:

• Debian 13 (e derivate come Raspberry Pi OS Bookworm)
• Ubuntu 24.04, 26.04 (LTS e correnti)
• Fedora 43 e 44
• AlmaLinux 9 e 10 — confermati vulnerabili con exploit pubblici funzionanti. AlmaLinux 8 ha il bug logico presente nel kernel 4.18 ma i PoC attuali non funzionano; la patch è stata distribuita comunque [almalinux.org]
• CentOS 9, Arch Linux — testate con successo dai PoC pubblici

Nota su Ubuntu 22.04: pur utilizzando kernel nella fascia vulnerabile (5.15 LTS o successivi HWE), questa versione non è stata esplicitamente confermata dai test pubblicati da Qualys. Si raccomanda comunque di applicare le patch correttive non appena disponibili, poiché l'assenza di una conferma esplicita non equivale a immunità.

Il profilo di rischio è più acuto in tre scenari tipici delle PMI italiane:

• Server condivisi e VPS multi-tenant: dove shell non privilegiate sono disponibili a più utenti. Un cliente compromesso su una macchina condivisa può leggere i file dell'host e degli altri tenant.
• Runner CI/CD: ambienti di build che eseguono codice non fidato (tipici negli stack DevOps moderni). Un pipeline malevolo può esfiltrare le chiavi SSH usate per il deploy.
• Postazioni di sviluppo: workstation di sviluppatori con accesso SSH a server di produzione. Un malware in esecuzione come utente normale sulla workstation può rubare le chiavi e propagarsi.

Verifica se il tuo server è vulnerabile

La prima azione è verificare la versione del kernel in esecuzione. Da terminale, eseguire:

uname -r

Se il kernel è precedente alle versioni patchate, il sistema è esposto. Le versioni minime che includono la correzione (commit 31e62c2ebbfd) sono:

• AlmaLinux 8: kernel-4.18.0-553.124.4.el8_10
• AlmaLinux 9: kernel-5.14.0-611.54.6.el9_7
• AlmaLinux 10: kernel-6.12.0-124.56.5.el10_1
• Debian/Ubuntu: verificare con apt changelog linux-image-$(uname -r) la presenza del commit 31e62c2ebbfd o della CVE-2026-46333
• Fedora: kernel aggiornato via dnf update a partire dal 15-16 maggio 2026

Un ulteriore controllo rapido consiste nel verificare il valore corrente di ptrace_scope, l'impostazione del modulo YAMA che regola l'accesso al tracing:

sysctl kernel.yama.ptrace_scope

Se il valore restituito è 0, il sistema è completamente esposto a tutti i PoC pubblici. Con valore 1 (configurazione predefinita di Ubuntu), l'exploit contro accounts-daemon viene bloccato, ma i PoC per ssh-keysign e chage — che sfruttano pidfd_getfd() — restano pienamente funzionanti: la protezione è solo parziale. Impostato a 2 o 3, tutti gli exploit noti vengono bloccati, ma il bug sottostante rimane presente fino all'aggiornamento del kernel [qualys.com].

Le tre azioni immediate per mettere in sicurezza i server

Ecco il piano d'azione concreto, pensato per il sysadmin che lunedì mattina ha una lista di server da controllare e poco tempo per farlo.

Azione 1: Aggiornare il kernel — priorità assoluta

L'unica correzione completa è installare il kernel patchato e riavviare. Su Debian e Ubuntu:

sudo apt update && sudo apt upgrade -y
sudo reboot

Su AlmaLinux, Rocky Linux, CentOS e Fedora:

sudo dnf update -y
sudo reboot

Nota importante: gli aggiornamenti kernel di maggio 2026 per AlmaLinux includono anche la patch per Fragnesia (CVE-2026-46300). Un solo riavvio risolve entrambe le vulnerabilità [almalinux.org]. Per i sysadmin che avevano rimandato il reboot per Fragnesia, questo è il momento di programmarlo: due problemi risolti con un'unica operazione.

Per i server in produzione dove il riavvio immediato non è possibile, passare all'Azione 3 (mitigazione temporanea) e pianificare la finestra di manutenzione entro 48 ore. La pubblicazione di exploit funzionanti da parte di ricercatori indipendenti — il codice è sufficientemente compatto (circa 90 righe di C) da essere adattato in poche ore — rende la finestra di esposizione critica [red-orbita.com].

Azione 2: Ruotare le chiavi SSH compromesse o potenzialmente esposte

Se il server ha permesso accessi locali a utenti non fidati durante la finestra di esposizione (cioè da novembre 2016 a oggi), le chiavi host SSH vanno considerate potenzialmente compromesse e ruotate immediatamente dopo l'aggiornamento del kernel.

Per rigenerare le chiavi host SSH su un server:

# Rimuovere le chiavi esistenti
sudo rm /etc/ssh/ssh_host_*

# Rigenerarle
sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""
sudo ssh-keygen -t rsa -b 4096 -f /etc/ssh/ssh_host_rsa_key -N ""
sudo ssh-keygen -t ecdsa -b 521 -f /etc/ssh/ssh_host_ecdsa_key -N ""

# Riavviare il servizio SSH
sudo systemctl restart sshd

Attenzione: la rotazione delle chiavi host invalida la fiducia dei client che si connettono al server. I client SSH vedranno un avviso di chiave cambiata e dovranno accettare la nuova fingerprint. In ambienti con automazione (Ansible, script di deploy, CI/CD), aggiornare i known_hosts centralizzati prima del cambio.

Qualys e Orca Security raccomandano inoltre di rivedere qualsiasi materiale crittografico (chiavi API, token di accesso, certificati TLS) che risiedesse sui server esposti. Il principio è semplice: se un utente non fidato ha avuto accesso locale alla macchina, considerare compromesso ogni segreto che la macchina poteva leggere [orca.security].

Azione 3: Applicare la mitigazione temporanea (se il reboot non è immediato)

Se non è possibile riavviare subito, esiste una mitigazione confermata da Qualys e dalle principali distribuzioni che blocca tutti i percorsi di exploit noti:

sudo sysctl -w kernel.yama.ptrace_scope=2

Per renderla permanente (sopravvive al reboot):

echo "kernel.yama.ptrace_scope = 2" | sudo tee /etc/sysctl.d/99-ptrace-mitigation.conf
sudo sysctl -p /etc/sysctl.d/99-ptrace-mitigation.conf

Il valore 2 (admin-only attach) richiede la capability CAP_SYS_PTRACE per qualsiasi operazione di ptrace, bloccando l'accesso a pidfd_getfd() per gli utenti non privilegiati. Il valore 3 (no attach) disabilita completamente ptrace.

Nota sulla difesa in profondità: alcuni sviluppatori del kernel segnalano che ptrace_scope=2 da solo potrebbe non coprire varianti che sfruttano namespace utente non privilegiati. Per una protezione ancora più robusta in attesa della patch, valutare l'aggiunta di:

sudo sysctl -w kernel.unprivileged_userns_clone=0

Questa combinazione (ptrace_scope=2 + unprivileged_userns_clone=0) chiude anche i vettori alternativi identificati dalla comunità kernel, senza dover ricorrere a ptrace_scope=3 che blocca persino il debugging da root [lwn.net].

Effetti collaterali da considerare:

• Debugger: gdb, strace -p e strumenti analoghi non funzioneranno più per utenti non root.
• Container: alcuni tool di debugging per container potrebbero rompersi; i crash reporter dei browser moderni generalmente gestiscono questa configurazione senza problemi.
• Irreversibilità senza reboot: ptrace_scope=2 non può essere abbassato senza riavviare il sistema. È una misura a senso unico.

La mitigazione è una misura temporanea, non una soluzione. Altri percorsi verso lo stesso bug potrebbero esistere. L'aggiornamento del kernel resta l'unica correzione definitiva [almalinux.org].

Confronto: patch definitiva vs mitigazione temporanea

Per aiutare il decisore a scegliere l'approccio corretto in base al contesto operativo, ecco una tabella di confronto:

Criterio	Aggiornamento kernel	ptrace_scope=2
Efficacia	Corregge il bug alla radice	Blocca i PoC noti; non copre varianti future
Richiede riavvio?	Sì	No (applicabile a caldo)
Impatto operativo	Downtime pianificato (1-5 minuti)	Debugger non root smettono di funzionare
Reversibilità	Sì (basta riavviare con kernel precedente)	No senza reboot
Raccomandato per	Tutti i server, il prima possibile	Server critici in attesa di finestra manutenzione

La strategia consigliata per le PMI: applicare ptrace_scope=2 immediatamente su tutti i server esposti, poi programmare l'aggiornamento kernel e il riavvio nella prima finestra di manutenzione utile (entro 48 ore). Dopo il riavvio con kernel patchato, rimuovere la configurazione ptrace_scope=2 se interferisce con i flussi di lavoro — il bug sarà corretto alla fonte e la protezione aggiuntiva non sarà più necessaria.

Oltre la patch: una strategia di difesa stratificata

CVE-2026-46333 è il quarto allarme locale sul kernel Linux in tre settimane. Non sarà l'ultimo. Per le PMI italiane che gestiscono server Linux — come avevamo già segnalato nell'analisi di Copy Fail CVE-2026-31431 — il modello di difesa reattiva («applico la patch quando esce la notizia») non è più sostenibile. Servono tre livelli di protezione:

Livello 1: Ridurre la superficie d'attacco locale

La vulnerabilità richiede esecuzione di codice locale. Ridurre drasticamente chi può accedere ai server è la prima barriera:

• Eliminare account di servizio non utilizzati e applicare il principio del minimo privilegio.
• Disabilitare l'accesso SSH per root (PermitRootLogin no in /etc/ssh/sshd_config).
• Limitare gli utenti con shell interattiva ai soli amministratori che ne hanno reale necessità.
• Separare i workload sensibili su host dedicati: il server del gestionale non dovrebbe condividere la macchina con l'ambiente di test.

Livello 2: Monitorare ciò che conta

Un attacco che sfrutta CVE-2026-46333 lascia tracce rilevabili. Configurare auditd per monitorare l'accesso ai file critici:

# Monitorare accessi alle chiavi SSH
sudo auditctl -w /etc/ssh/ -p r -k ssh_keys_access

# Monitorare accessi a /etc/shadow
sudo auditctl -w /etc/shadow -p r -k shadow_access

# Rendere persistenti le regole
echo '-w /etc/ssh/ -p r -k ssh_keys_access' | sudo tee /etc/audit/rules.d/ssh-monitor.rules
echo '-w /etc/shadow -p r -k shadow_access' | sudo tee -a /etc/audit/rules.d/ssh-monitor.rules

Per ambienti con più server, centralizzare i log con strumenti come Wazuh (open source) o soluzioni SIEM consente di correlare eventi sospetti tra macchine diverse. Un accesso a /etc/shadow da parte di un processo inatteso è un segnale che merita attenzione immediata.

Livello 3: Gestire il ciclo di vita delle credenziali

La lezione più ampia di CVE-2026-46333 riguarda la gestione delle credenziali:

• Rotazione programmata delle chiavi SSH (ogni 90-180 giorni), non solo dopo un incidente.
• Passphrase obbligatorie su tutte le chiavi private SSH, senza eccezioni per quelle «di servizio».
• Limitare la permanenza delle chiavi negli agenti SSH (ssh-agent -t 3600 per un timeout di un'ora).
• Adottare autenticazione hardware (token FIDO2) per gli accessi amministrativi. Come approfondito nella guida completa all'autenticazione a due fattori, l'MFA hardware è oggi il gold standard per bloccare l'uso non autorizzato di credenziali rubate.

Quando basta il fai-da-te e quando serve aiuto

Per una PMI con uno o due server Linux e un sysadmin competente, le tre azioni descritte sono eseguibili internamente in una mattinata di lavoro. La procedura è documentata, gli strumenti sono quelli standard di sistema e non servono competenze specialistiche oltre alla normale amministrazione Linux.

La situazione cambia quando:

• I server da aggiornare sono più di cinque, distribuiti su data center diversi o in cloud.
• Non esiste un inventario aggiornato delle macchine e delle versioni kernel in esecuzione.
• La rotazione delle chiavi SSH impatta pipeline CI/CD, automazioni Ansible o connessioni machine-to-machine che nessuno ha documentato.
• Non c'è un sistema di monitoring centralizzato per verificare che le patch siano state applicate ovunque.
• L'azienda ha obblighi di compliance (GDPR, ISO 27001, NIS2) che richiedono tracciabilità documentata degli interventi di sicurezza.

In questi scenari, affidarsi a un servizio di sicurezza gestita o a un partner tecnologico con competenze specifiche su infrastrutture Linux non è una spesa ma un investimento in velocità di risposta. Il tempo tra la disclosure pubblica e i primi tentativi di exploit nei confronti di bersagli non specifici si è ridotto a ore, non più a giorni. Per la quarta volta in tre settimane, la finestra per applicare una patch prima che gli attaccanti automatizzino lo sfruttamento della vulnerabilità è drammaticamente stretta.

Conclusioni: il lunedì mattina del sysadmin

CVE-2026-46333 è il tipo di vulnerabilità che tiene svegli i sysadmin: silenziosa per quasi un decennio, tecnicamente elegante nella sua semplicità, devastante nell'impatto pratico. Non richiede exploit remoti, zero-click o tecniche avanzate di memory corruption. Basta una shell locale — e in un'epoca in cui container, CI/CD e ambienti condivisi sono la norma, una shell locale non è mai veramente difficile da ottenere.

Il piano d'azione per la PMI italiana è chiaro e misurabile:

1. Oggi: eseguire uname -r su ogni server Linux. Se il kernel non è patchato, applicare ptrace_scope=2 come protezione immediata.
2. Entro 48 ore: aggiornare il kernel e riavviare. Verificare che la patch sia effettivamente attiva con uname -r dopo il reboot.
3. Entro 7 giorni: ruotare le chiavi SSH host e rivedere le credenziali sui server che hanno avuto accessi locali non fidati durante la finestra di esposizione.
4. Entro 30 giorni: mettere in piedi il monitoring degli accessi ai file critici e avviare un ciclo di rotazione programmata delle credenziali.

La cybersecurity per le PMI non si misura dalla capacità di schivare ogni minaccia, ma dalla velocità e dall'efficacia con cui si risponde quando la minaccia si materializza. Nove anni di esposizione sono un problema. Quarantotto ore per risolverlo, con le conoscenze giuste, sono una soluzione.