Tre falle sfruttate del kernel Linux entrano nel catalogo KEV della CISA

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Sicurezza delle infrastrutture per team enterprise negli USA e nell'UE

La risposta breve

Cosa ha segnalato la CISA

Il 18 settembre 2026 l'agenzia statunitense per la cybersicurezza e la sicurezza delle infrastrutture (CISA) ha aggiunto tre vulnerabilità del kernel Linux al suo catalogo delle vulnerabilità sfruttate note (KEV), citando prove di sfruttamento in circolazione. In base alla Binding Operational Directive 26-04, le agenzie civili federali devono correggerle tutte e tre entro il 21 settembre — e, cosa insolita, la CISA ha contrassegnato ciascuna come soggetta a triage forense: le agenzie devono indagare attivamente gli asset esposti alla ricerca di segni di compromissione, senza considerare l'installazione della patch come la fine del lavoro.

La più grave è CVE-2025-39682, valutata CVSS 9.8. È un controllo improprio di una condizione eccezionale nel percorso di ricezione di Kernel TLS (kTLS): un caso limite in cui un record di lunghezza zero recuperato dalla rx_list interna aggira la gestione prevista del tipo di record in recvmsg(), con conseguente divulgazione di memoria o denial of service. L'avviso di Red Hat classifica il problema come ad alto rischio e segnala che esistono già exploit pubblici che lo sfruttano. CVE-2026-53266 (CVSS 8.8) è una scrittura fuori limite nel percorso Source NAT di ebtables del bridge netfilter, innescata durante le operazioni di riscrittura dell'indirizzo hardware del mittente ARP, che può causare comportamenti imprevisti, un crash o un'escalation locale dei privilegi. CVE-2025-39964 (CVSS 7.8) è una race condition che consente scritture concorrenti sullo stesso socket AF_ALG — l'interfaccia crypto-da-userspace del kernel — che può mandare in crash il sistema o corrompere il risultato di un'operazione crittografica, creando sia un rischio di disponibilità sia di integrità dei dati.

Le tre falle non sono correlate tra loro e non vi è alcuna prova di un'unica catena d'attacco coordinata; sono tre debolezze indipendenti del kernel che hanno ottenuto una voce KEV lo stesso giorno. Le distribuzioni hanno reagito rapidamente — Red Hat, ad esempio, ha aggiornato i propri avvisi il 19 settembre — e la correzione è la stessa per tutte e tre: installare il kernel corretto della propria distribuzione e riavviare, oppure applicare un live-patch dove supportato.

Perché «locale» non significa «basso rischio»

Due di queste falle richiedono accesso locale, e la terza interessa utenti locali autenticati, il che può sembrare rassicurante — finché non si ricorda cosa significhi «locale» in un parco cloud-native. Un container da cui un attaccante è evaso, un punto d'appoggio ottenuto da un exploit di applicazione web, una dipendenza compromessa in esecuzione in un job CI o un account di servizio a bassi privilegi sono tutti «locali». In pratica, l'intrusione iniziale è raramente l'obiettivo; lo è l'escalation da quel punto d'appoggio fino a root sull'host. La scrittura fuori limite di CVE-2026-53266 è esattamente questo tipo di primitiva di escalation, e la capacità di CVE-2025-39964 di corrompere i risultati crittografici mina le garanzie di integrità su cui si basano altri controlli.

La falla kTLS solleva un segnale diverso. Kernel TLS sposta la cifratura dei flussi di rete nel kernel per motivi di prestazioni ed è usata da servizi e proxy ad alto throughput. Un percorso raggiungibile da remoto che si conclude con una divulgazione di memoria o un crash di questo sottosistema è il tipo di primitiva che gli attaccanti concatenano in campagne più ampie, il che spiega probabilmente il 9.8 e la nota sugli exploit pubblici esistenti. La lezione che ricorre con le CVE del kernel: la gravità dipende da ciò che un attaccante può raggiungere da dove si trova già — e in un'infrastruttura multi-tenant, «già dentro un container su un nodo condiviso» è un punto di partenza comune, non remoto.

Cosa significa per i team software in Italia

Primo, una CVE del kernel è un evento di flotta, non di server. Il kernel è l'unico componente che VM, container e runner CI condividono tutti: l'esposizione cresce con la vostra infrastruttura, non con una singola applicazione. Questo cambia la forma della remediation: non state applicando la patch a un servizio, state distribuendo kernel su ogni host e nodo, ricostruendo le immagini di base dei container che ereditano quel kernel tramite l'host, e riavviando o applicando live-patch senza perdere traffico di produzione. I team la cui piattaforma cloud e DevOps tratta già gli aggiornamenti del kernel come una pipeline automatizzata e testata assorbiranno tutto in un giorno; chi applica le patch a mano scoprirà quanti host aveva dimenticato.

Secondo, l'orologio di tre giorni è un test di inventario e orchestrazione, non di buona volontà. Quando la CISA associa un triage forense a una voce KEV, applicare la patch da sola non basta esplicitamente — dovete poter dire quali host erano interessati, quando sono stati aggiornati e se qualcuno è stato toccato in precedenza. Ciò richiede dati asset aggiornati, logging centralizzato e la capacità di pianificare un riavvio fuori banda sull'intero parco con breve preavviso. Sono capacità che si costruiscono in anticipo; non si improvvisano dentro una finestra di 72 ore.

Terzo, per i team regolamentati questo è un evento di conformità e notifica. Una falla del kernel che consente di ottenere root, con sfruttamento confermato, ricade nell'UE direttamente sotto le aspettative di NIS2 e DORA in materia di sicurezza del trattamento e remediation tempestiva e documentata — e in Italia sotto il quadro recepito (obblighi per soggetti essenziali e importanti ai sensi del D.lgs. 138/2024, notifica allo CSIRT Italia) nonché, per i dati personali, sotto i requisiti del Garante ai sensi del GDPR in caso di violazione. Poter produrre la cronologia delle patch, l'elenco degli asset interessati e le conclusioni del triage è la prova che auditor e autorità chiedono per prima — e assai più facile da generare quando la gestione delle patch e il logging sono già progettati anziché ricostruiti a posteriori.

Cosa fare ora

1. Inventariate la flotta. Enumerate ogni host Linux, nodo del cluster e runner CI e mappate le versioni del kernel in esecuzione. Le macchine assenti dal vostro inventario sono quelle che restano senza patch oltre la scadenza.
2. Applicate la patch e riavviate. Installate il kernel corretto della vostra distribuzione e riavviate, oppure applicate un live-patch dove la vostra piattaforma lo supporta. Date priorità ai nodi multi-tenant, agli host esposti a Internet e ai runner CI che eseguono codice non attendibile.
3. Ricostruite le immagini dei container. I container ereditano il kernel dell'host, ma le immagini di base e di nodo vanno comunque rinnovate dove fissano componenti accoppiati al kernel; ricostruite e ridistribuite affinché nulla venga eseguito su una vecchia immagine di nodo.
4. Applicate mitigazioni provvisorie se dovete attendere. Dove un riavvio immediato è impossibile, riducete l'esposizione: disattivate kTLS se inutilizzato, rimuovete le regole SNAT ebtables di riscrittura ARP, limitate la capability CAP_NET_ADMIN e bloccate il modulo af_alg dopo aver valutato l'impatto. Sono palliativi, non correzioni.
5. Cercate, poi testate. Seguite il requisito di triage della CISA — esaminate i log degli host esposti alla ricerca di tracce di sfruttamento precedente, non solo dello stato della patch — e aggiungete i percorsi del kernel e di escalation dei privilegi al perimetro del vostro prossimo penetration test, così da sondare deliberatamente l'escalation da un punto d'appoggio.

Domande frequenti

Fonti

The Hacker News — CISA Flags Three Linux Kernel Vulnerabilities Exploited in the Wild
CISA — Known Exploited Vulnerabilities Catalog
Cyber Security News — CISA Warns of Linux Kernel Vulnerabilities Actively Exploited in Attacks