CISA ha inserito il 18 settembre nel catalogo Known Exploited Vulnerabilities tre falle del kernel Linux, imponendo alle agenzie federali statunitensi la correzione entro il 21 settembre. Nessuna delle tre consente l'esecuzione di codice da remoto: sono tutte vulnerabilità locali. Ed è precisamente questo che le rende degne di attenzione, perché segnala dove si stanno spostando gli attacchi.

Le tre vulnerabilità sono:

  • CVE-2025-39682 (CVSS 9.8, critica) — un difetto logico nel percorso di ricezione TLS del kernel: i record di lunghezza zero accodati per l'elaborazione successiva vengono gestiti in modo errato, e con kTLS attivo tipi diversi di record TLS possono finire elaborati insieme. Red Hat conferma la disponibilità di exploit pubblici.
  • CVE-2026-53266 (CVSS 8.8) — una scrittura fuori dai limiti nell'implementazione SNAT di ebtables: una riscrittura di indirizzo ARP può modificare memoria condivisa mappata su file senza aver prima reso scrivibile l'intervallo del pacchetto interessato. Red Hat conferma anche qui un exploit noto.
  • CVE-2025-39964 (CVSS 7.8) — una race condition nell'interfaccia dei socket crittografici AF_ALG: scritture concorrenti possono corrompere lo stato per-socket, con effetti che vanno dal crash del sistema all'alterazione dei risultati crittografici. La falla era presente nel kernel da quattordici anni.

CISA dichiara che tutte e tre sono state sfruttate in attacchi reali, ma non ha diffuso alcun dettaglio sugli incidenti né sugli attori. Al momento nessuna delle tre risulta impiegata da gruppi ransomware.

Chi le ha trovate, e cosa questo dice sull'impatto

CVE-2025-39964 è stata individuata dalla società di sicurezza offensiva STAR Labs, che ha precisato — dettaglio che nel 2026 è diventato una rivendicazione — di averla trovata senza l'aiuto di sistemi di intelligenza artificiale. I ricercatori l'hanno dimostrata ottenendo escalation di privilegi ed evasione dal container nel kernelCTF di Google. È la parola chiave dell'intera vicenda: evasione dal container.

Su CVE-2026-53266 il ricercatore Kimmo Suominen ha pubblicato un'analisi tecnica e un tracker dello stato delle patch su GitHub, delineando un possibile percorso di escalation dei privilegi basato sulla modifica di memoria mappata su file. Va però riportato con precisione ciò che lo stesso ricercatore dichiara: quella catena di sfruttamento è dedotta per analogia con Dirty Pipe e non è stata dimostrata con codice di exploit pubblico. La conferma di sfruttamento attivo arriva da CISA e da Red Hat, non da quel percorso specifico — una distinzione che conviene mantenere quando si scrive un piano di rimedio, per non giustificarlo con un'ipotesi.

Cosa significa per le aziende italiane

Una vulnerabilità locale non è un problema minore: è un problema di seconda fase. L'attaccante non la usa per entrare, la usa una volta dentro — dopo una credenziale rubata, un webshell su un'applicazione, un container compromesso, un accesso di un fornitore. È l'anello che trasforma un accesso limitato in controllo dell'host. E l'inserimento in KEV significa che qualcuno lo sta già facendo.

Nel panorama italiano i tre difetti colpiscono in punti diversi e ben identificabili.

AF_ALG e la multi-tenancy. L'evasione dal container è il rischio che riguarda più direttamente le architetture moderne: cluster Kubernetes gestiti presso provider italiani, ambienti di CI/CD che eseguono codice di terze parti, piattaforme applicative interne condivise tra team, hosting condiviso su container. In tutti questi casi il confine di sicurezza su cui l'organizzazione fa affidamento è il kernel condiviso. Se cade quel confine, non cade un servizio: cade la separazione fra tenant. Chi ha progettato l'isolamento assumendo che un container compromesso resti un container compromesso deve rivedere quell'assunto. Questo vale in modo particolare per i soggetti che erogano servizi cloud qualificati per la pubblica amministrazione, dove la separazione dei tenant non è un dettaglio architetturale ma un requisito.

ebtables e le reti a bridge. L'SNAT di ebtables opera su bridge Ethernet, ed è la tecnologia che sta sotto le configurazioni di rete predefinite di Docker, di libvirt e dei bridge KVM. In Italia il parco di virtualizzazione on-premise basato su KVM e Proxmox è ampio, soprattutto nelle PMI e negli enti locali che hanno scelto alternative a VMware negli ultimi due anni. Sono ambienti spesso gestiti senza un processo formale di patching del kernel, perché «l'hypervisor non si tocca».

kTLS e i sistemi ad alto throughput. Il TLS nel kernel è meno diffuso, ma è presente esattamente dove conta: reverse proxy e load balancer configurati per l'offload TLS, sistemi di distribuzione contenuti, storage con NFS su TLS. Sono nodi ad alto valore, che vedono traffico in chiaro e conservano chiavi.

La parte che verrà ignorata: il triage forense

CISA ha marcato tutte e tre le vulnerabilità come richiedenti «forensic triage». Significa che per ogni asset interessato non basta applicare la patch: va esaminato alla ricerca di segni che lo sfruttamento sia già avvenuto.

È l'indicazione più importante del bollettino e quella che, nella pratica italiana, verrà sistematicamente salvata per dopo. La logica è però elementare: se una falla è sfruttata attivamente da tempo imprecisato — e nel caso di CVE-2025-39964 «da tempo imprecisato» può significare molto, dato che il difetto è nel kernel da quattordici anni — la patch chiude la porta ma non dice nulla su chi sia già passato. Un attaccante che ha ottenuto root su un host prima dell'aggiornamento non viene rimosso dall'aggiornamento: ha lasciato chiavi SSH, unit systemd, task pianificati, credenziali estratte dalla memoria e sessioni cloud ancora valide.

Per i soggetti rientranti in NIS2 questo ha un risvolto formale, non solo tecnico. Il decreto legislativo 138/2024 richiede all'articolo 21 misure di gestione delle vulnerabilità e di gestione degli incidenti, e in caso di incidente significativo impone la pre-notifica al CSIRT Italia entro 24 ore e la notifica entro 72. L'obbligo di notifica presuppone la capacità di accorgersi: non si può notificare un incidente che non si è mai cercato. Un'organizzazione che applica la patch, archivia il ticket e non verifica nulla si trova, in caso di accertamento successivo, nella posizione peggiore possibile — quella di aver saputo della vulnerabilità, saputo che era sfruttata attivamente, e deciso di non guardare.

Vale anche la pena ricordare che il catalogo KEV non ha efficacia vincolante in Italia: la Binding Operational Directive di CISA obbliga le agenzie federali statunitensi, non le imprese europee. Ma usarlo come lista di priorità è gratuito e ragionevole. In un mondo in cui si pubblicano oltre quarantamila CVE all'anno, «questa è già usata negli attacchi» è il criterio di selezione più solido a disposizione, e coincide con la logica risk-based che NIS2 richiede.

L'insidia delle versioni

Un ultimo punto operativo, e non è un dettaglio. Verificare la propria esposizione confrontando il numero di versione del kernel con quello della correzione upstream è un errore frequente e fuorviante.

Le distribuzioni enterprise — RHEL e derivate, Oracle Linux, SLES, Ubuntu LTS — mantengono kernel con numerazione congelata e applicano le correzioni tramite backport. Il numero di versione resta basso per anni mentre le patch vengono integrate. L'unico riferimento valido è l'advisory del proprio fornitore per la propria versione, non il changelog di kernel.org. Vale anche il contrario: un kernel «recente» installato mesi fa può essere privo di correzioni pubblicate dopo. La verifica va fatta sul canale del vendor.

Cosa fare subito

  • Applicare gli aggiornamenti del kernel forniti dalla propria distribuzione e verificare l'esposizione consultando gli advisory del fornitore per CVE-2025-39682, CVE-2026-53266 e CVE-2025-39964, non il numero di versione upstream.
  • Riavviare i sistemi. Un aggiornamento del kernel installato e non riavviato non protegge. Verificare con needs-restarting -r su RHEL e derivate o controllando /var/run/reboot-required su Debian e Ubuntu. È il punto in cui la maggior parte delle organizzazioni si ferma.
  • Dare priorità agli host multi-tenant: nodi worker Kubernetes, runner di CI/CD, hypervisor KVM e Proxmox, hosting condiviso. Sono i sistemi in cui l'evasione dal container o l'escalation locale ha il massimo impatto.
  • Verificare dove è attivo kTLS (configurazioni di offload TLS su reverse proxy e sistemi di distribuzione contenuti) e dove si usano bridge con ebtables — quindi, di fatto, ogni host Docker o libvirt con configurazione di rete predefinita.
  • Eseguire il triage forense richiesto da CISA sui sistemi esposti: nuove chiavi in ~/.ssh/authorized_keys, unit systemd e timer aggiunti o modificati, task in cron e at, binari con SUID comparsi di recente, moduli del kernel caricati non previsti, utenti con UID 0. Confrontare con una linea di base, se esiste.
  • Controllare i log di autenticazione e di audit per escalation di privilegi anomale e per processi in esecuzione con privilegi superiori a quelli attesi, nella finestra precedente l'aggiornamento.
  • Dove la patch non è applicabile a breve, ridurre la superficie: disabilitare i moduli del kernel non utilizzati (ebtables, algif_*), limitare la creazione di user namespace non privilegiati, applicare profili seccomp restrittivi ai container.
  • Se emergono indizi di compromissione su un host multi-tenant, trattare come compromesse anche le credenziali e i token presenti sui carichi di lavoro ospitati, non solo l'host: chiavi di service account, token di cloud provider, segreti montati nei container.
  • Per i soggetti NIS2: documentare la valutazione svolta e le date, anche in caso di esito negativo. È la prova che l'obbligo dell'articolo 21 è stato assolto, ed è ciò che si presenta in caso di verifica.

Il filo conduttore di questi tre bollettini non sta nei punteggi CVSS. Sta nel fatto che gli attaccanti stanno investendo nelle falle locali del kernel perché il perimetro non è più il problema: dentro le reti ci si arriva, e il valore si crea nel passaggio da accesso limitato a controllo completo. Un CVSS 7.8 su una race condition dimenticata da quattordici anni vale, per chi attacca, più di molte vulnerabilità critiche esposte su internet — perché nessuno la sta guardando.