In questo articolo Indice dei contenuti 2 sezioni
Tre vulnerabilità Linux sono finite nel catalogo Known Exploited Vulnerabilities di CISA, l’agenzia statunitense per la sicurezza informatica, dopo che sono emersi segnali concreti di sfruttamento attivo. Non si tratta quindi di falle teoriche o di scenari da laboratorio, ma di difetti che qualcuno sta già usando contro sistemi reali. I tre bug toccano aree molto diverse del kernel: la gestione del traffico TLS, il filtraggio di rete sui bridge Ethernet e l’interfaccia che permette ai processi di accedere alle funzioni crittografiche. Componenti lontani tra loro, eppure tutti capaci di creare grattacapi seri su macchine esposte o condivise tra più utenti.
Al momento non circolano dettagli pubblici su come stiano avvenendo gli attacchi, né elementi che permettano di capire se le tre falle facciano parte di un’unica catena di sfruttamento. Red Hat, però, ha aggiornato i propri advisory confermando sia lo sfruttamento attivo sia l’esistenza di exploit già disponibili pubblicamente.
Cosa fanno esattamente le tre falle
La prima è CVE-2025-39682 e riguarda il percorso di ricezione di kTLS. Il problema nasce dal modo in cui vengono gestiti i record TLS di lunghezza zero presenti nella rxlist: in una sequenza specifica, il codice può interpretare male il record successivo durante le operazioni di ricezione e zero copy. Curiosità non da poco, il punteggio assegnato cambia parecchio a seconda di chi lo calcola. NVD indica un CVSS 3.1 pari a 7.1, mentre kernel.org arriva a 9.8, differenza che deriva dall’uso di vettori di valutazione diversi. I rami interessati comprendono il 6.1 precedente alla 6.1.149 e il 6.12 precedente alla 6.12.44.
Poi c’è CVE-2026-53266, che colpisce ebtables, il sottosistema usato per filtrare il traffico Ethernet nei bridge. Qui il difetto è una scrittura fuori dai limiti nel percorso di riscrittura SNAT legato ad ARP. Un attaccante locale può provocare comportamenti anomali, mandare giù il sistema oppure alzare i propri privilegi. Il CVSS indicato è 8.8. Il fatto che serva un accesso locale restringe lo scenario di partenza, certo, ma rende il bug ancora più interessante per chi ha già messo le mani su una sessione con permessi limitati e cerca il salto di qualità.
La terza, CVE-2025-39964, riguarda AFALG, l’interfaccia socket con cui i processi raggiungono le primitive crittografiche del kernel. Una race condition permette scritture concorrenti sullo stesso socket, con conseguenze che vanno dal crash alla corruzione dei risultati delle operazioni crittografiche. In gioco ci sono quindi sia la disponibilità sia l’integrità dei dati elaborati. Il punteggio riportato è 7.8. Tre classi tecniche completamente diverse, insomma: gestione anomala dei record, accesso oltre i limiti e problemi di sincronizzazione.
Perché conviene muoversi subito
L’inclusione nel catalogo KEV è il dettaglio che cambia tutto. Significa che l’agenzia ha prove di attacchi reali, non semplici ipotesi sulla possibilità di sfruttamento. Per chi gestisce infrastrutture Linux la priorità si sposta: non basta guardare il numero di versione, bisogna capire quali host usano davvero i componenti coinvolti, quali sono raggiungibili dall’esterno e quali log possono raccontare eventuali attività sospette.
Per le agenzie del Federal Civilian Executive Branch la direttiva BOD 26-04 ha fissato il 21 settembre 2026 come termine consigliato per applicare le correzioni. Red Hat, dal canto suo, ha invitato a trattare le tre CVE con alta priorità. Negli altri ambienti il punto di partenza restano gli advisory del proprio distributore, perché confrontare solo il numero del kernel upstream può portare fuori strada: i vendor spesso integrano le patch nei loro pacchetti senza cambiare la numerazione.
C’è un ultimo aspetto che pesa più dell’aggiornamento in sé, ed è la gestione dell’incidente. Se una macchina è rimasta vulnerabile durante una finestra in cui lo sfruttamento era possibile, applicare la patch non dimostra affatto che non sia successo nulla. Log di autenticazione, telemetria dei processi, eventi del kernel e variazioni inattese nei privilegi restano gli strumenti per ricostruire cosa è accaduto prima. E poiché mancano informazioni pubbliche sulle tecniche usate dagli aggressori, attribuire una catena di attacco precisa a queste tre falle sarebbe azzardato.
Fonte: TecnoAndroid
