Tre vulnerabilità del kernel Linux sono state inserite il 19 settembre 2026 da CISA nel catalogo KEV, l’elenco delle falle per cui esistono prove di sfruttamento reale. Per le aziende significa una cosa semplice: se avete server, appliance, firewall, NAS o piattaforme virtuali basati su Linux, il rischio non è teorico e gli aggiornamenti vanno trattati con priorità alta.
Cosa è successo
La U.S. Cybersecurity and Infrastructure Security Agency (CISA) ha aggiunto tre falle del kernel Linux al proprio catalogo Known Exploited Vulnerabilities (KEV), indicando che risultano già sfruttate “in the wild”, cioè in attacchi reali.
Le vulnerabilità segnalate sono:
- CVE-2025-39682 — punteggio CVSS 9.8. Riguarda un controllo non corretto nel percorso di ricezione TLS e può consentire a un utente locale autenticato di provocare divulgazione di memoria o un denial of service.
- CVE-2026-53266 — punteggio CVSS 8.8. È una vulnerabilità di scrittura fuori dai limiti nel percorso di riscrittura ARP di ebtables SNAT, con possibili effetti come comportamento imprevisto del sistema, denial of service o escalation di privilegi locale.
- CVE-2025-39964 — punteggio CVSS 7.8. Si tratta di una race condition che può permettere scritture concorrenti sullo stesso socket AF_ALG, con rischio di crash del sistema, corruzione dei risultati delle operazioni crittografiche, denial of service e problemi di integrità dei dati.
Secondo quanto riportato, al momento non sono stati diffusi dettagli pubblici sulla catena d’attacco usata né se le tre falle vengano sfruttate insieme. Questo però non riduce l’urgenza: quando una vulnerabilità entra nel KEV, il segnale operativo è chiaro.
Perché questa notizia conta anche fuori dal mondo Linux
Molte aziende pensano di “non usare Linux” solo perché il personale lavora su PC Windows o Mac. In pratica, però, Linux è spesso presente dove non si vede:
- server interni o in cloud;
- firewall e appliance di sicurezza;
- NAS e sistemi di backup;
- host di virtualizzazione e container;
- software gestionali o applicativi distribuiti come appliance;
- piattaforme di rete o dispositivi embedded.
In altre parole, una PMI può essere esposta anche senza avere amministratori Linux dedicati in organico. Il problema riguarda soprattutto i sistemi che eseguono servizi critici o che permettono accessi locali, diretti o mediati da altri software.
Cosa sappiamo finora sul rischio reale
L’elemento più importante non è solo il punteggio CVSS, ma il fatto che esistano evidenze di sfruttamento attivo. Inoltre, Red Hat ha aggiornato i propri advisory il 19 settembre 2026 alle 2:00 UTC, riconoscendo l’esistenza di sfruttamento attivo e indicando almeno per una delle falle che si tratta di un rischio elevato con exploit pubblici noti.
CISA, in base alla direttiva BOD 26-04, ha indicato per le agenzie federali statunitensi una scadenza di remediation al 21 settembre 2026. Anche se questa obbligazione non riguarda direttamente le aziende italiane, il messaggio è utile: la finestra di reazione consigliata è molto breve.
Un altro elemento da non sottovalutare è la natura delle tre vulnerabilità. Due aspetti le rendono particolarmente sensibili in ambiente aziendale:
- possono avere impatti che vanno oltre il semplice blocco del servizio, arrivando a escalation di privilegi o integrità dei dati;
- colpiscono il kernel, cioè il livello più delicato del sistema operativo.
Quando un problema tocca il kernel, il perimetro di rischio è più ampio: stabilità del sistema, affidabilità dei servizi, coerenza dei processi crittografici e possibilità di ottenere privilegi superiori.
Il contesto: settembre 2026 è un mese molto denso per Linux
La segnalazione di CISA arriva nello stesso momento in cui il ricercatore Asim Manizada ha reso pubblici altri quattro difetti di local privilege escalation nel kernel Linux: CVE-2026-80844 (DirtyAH6), CVE-2026-81000 (TUNderflow), CVE-2026-68121 (PPPoEject) e CVE-2026-74469 (DiagSpill).
Questo non significa automaticamente che tutte queste falle siano usate negli stessi attacchi, ma indica un quadro preciso: il kernel Linux è sotto osservazione intensa da parte di ricercatori e attaccanti, e il volume di vulnerabilità ad alto impatto sta aumentando. Per chi gestisce infrastrutture aziendali, il rischio oggi non è tanto “avere una CVE”, quanto non sapere abbastanza in fretta dove si trovi davvero il sistema vulnerabile.
Dove un’azienda può essere esposta senza accorgersene
Nella pratica, i casi più comuni sono questi:
- server applicativi ospitati da un fornitore o in cloud, dove il sistema sottostante viene dato per scontato;
- macchine virtuali dimenticate, ancora accese ma fuori inventario operativo;
- appliance di rete o sicurezza che usano kernel Linux personalizzati e dipendono dagli aggiornamenti del produttore;
- ambienti di sviluppo o test con patching meno rigoroso rispetto alla produzione;
- sistemi con accessi locali o shell applicative usati da consulenti, fornitori o tecnici interni.
Il punto critico è che le tre vulnerabilità descritte richiedono in vari casi un accesso locale o autenticato, ma questo non deve tranquillizzare. Nelle intrusioni reali, un accesso iniziale limitato è spesso sufficiente per muoversi lateralmente o aumentare i privilegi.
Cosa significa per la tua azienda
Se la tua organizzazione usa anche indirettamente sistemi Linux, le azioni da intraprendere sono molto concrete.
1. Fai subito un censimento dei sistemi coinvolti
Non limitarti ai server “ufficiali”. Verifica anche firewall, NAS, appliance, VM in cloud, host di virtualizzazione e ambienti di test. Se non hai un inventario aggiornato, questa è la vera urgenza.
2. Controlla gli advisory dei vendor
Per i sistemi standard verifica gli aggiornamenti del distributore Linux. Per appliance e dispositivi integrati controlla invece le comunicazioni del produttore: spesso il kernel è personalizzato e non basta confrontare solo il numero di versione generico.
3. Applica le patch con priorità alta
La presenza nel catalogo KEV è un criterio pratico di priorità. Se non puoi aggiornare immediatamente in produzione, programma una finestra straordinaria e documenta i sistemi esposti.
4. Riduci il rischio finché la patch non è disponibile
Se un aggiornamento dipende dal fornitore o richiede test, applica misure temporanee: limitazione degli accessi locali, revisione degli account tecnici, segmentazione di rete, controllo dei privilegi e monitoraggio dei log di sistema.
5. Verifica backup e capacità di ripristino
Un kernel compromesso o instabile può causare interruzioni improvvise. È il momento giusto per controllare che i backup dei server siano recenti, isolati e testati. Se volete rafforzare questo aspetto, una soluzione di remote backup aiuta a ridurre i tempi di fermo e il rischio operativo.
6. Rafforza il processo di gestione endpoint e server
Nelle PMI il problema non è solo tecnico, ma organizzativo: sapere chi aggiorna cosa, con quali tempi e con quali verifiche. Un servizio strutturato di desktop e IT management può aiutare a standardizzare aggiornamenti, inventario e controlli periodici.
7. Considera la sicurezza come continuità operativa
Una vulnerabilità del kernel non è solo un tema “da sistemisti”: può bloccare ERP, file server, VPN, backup o applicativi di reparto. Per questo ha senso trattarla come parte della continuità del business e non come semplice manutenzione tecnica. In quest’ottica, un supporto specialistico sulla sicurezza informatica può fare la differenza soprattutto se non avete risorse interne dedicate.
Come decidere le priorità senza farsi travolgere dagli alert
Ogni settimana emergono nuove CVE, ma non tutte richiedono la stessa urgenza. In questo caso ci sono tre fattori che giustificano una priorità elevata:
- sfruttamento attivo confermato;
- impatto sul kernel;
- possibili effetti su disponibilità, privilegi e integrità dei dati.
Per una PMI la regola più utile è semplice: non rincorrere ogni notizia, ma reagire subito quando coincidono gravità tecnica e sfruttamento reale. È esattamente il motivo per cui il catalogo KEV di CISA è osservato con attenzione anche fuori dagli Stati Uniti.
Un promemoria importante per i responsabili aziendali
Il rischio cyber oggi passa spesso da componenti invisibili all’utente finale. Un dipendente non si accorge se un host Linux sottostante è vulnerabile, ma l’azienda se ne accorge eccome quando si fermano servizi, backup, accessi remoti o procedure interne.
La domanda giusta non è “abbiamo Linux?”, ma “sappiamo dove Linux è presente nella nostra infrastruttura e con quale livello di aggiornamento?”. Se la risposta non è immediata, la notizia di oggi riguarda già la vostra azienda.
Domande frequenti
Se usiamo Windows sui PC, possiamo ignorare questa notizia?
No. Molti servizi aziendali, firewall, NAS, appliance e server cloud usano Linux anche se gli utenti lavorano solo su Windows.
Le vulnerabilità richiedono per forza accesso fisico al server?
Dalle informazioni pubbliche si parla di attaccanti locali o utenti autenticati, ma in uno scenario reale un accesso iniziale limitato può arrivare anche da altri sistemi già compromessi.
Conviene aspettare maggiori dettagli tecnici prima di aggiornare?
No. Il fatto che CISA abbia inserito queste CVE nel KEV e che Red Hat abbia riconosciuto lo sfruttamento attivo è già sufficiente per dare priorità alta alla remediation.