Sophos Firewall: hotfix per la falla kernel CVE-2026-98432

Sophos ha reso disponibile un hotfix del kernel per CVE-2026-98432. Un aspetto è decisivo per il funzionamento: un aggiornamento scaricato protegge il firewall soltanto dopo il riavvio richiesto. Chi si affida alla distribuzione automatica degli hotfix dovrebbe quindi controllare lo stato dell’installazione e pianificare una finestra di manutenzione.

Questo articolo distingue la vulnerabilità tecnica dalla procedura di aggiornamento specifica dei dispositivi Sophos. Fonti verificate l'11 novembre 2026. Le pagine del produttore collegate potrebbero successivamente aggiungere altre versioni del firmware.

Quali versioni Sophos richiedono attenzione?

Per i prodotti e le versioni SFOS seguenti sono disponibili queste correzioni:

Questa è una tabella delle correzioni disponibili, non un elenco completo di tutte le build vulnerabili. Sophos non vi pubblica una matrice esaustiva che indichi la prima e l’ultima versione SFOS vulnerabile. L’assenza di una voce nella tabella non consente quindi di considerare un sistema al sicuro. Questo vale, ad esempio, per la valutazione di un’installazione con SFOS 21.5 o 22.0 MR2.

Prima di cambiare versione occorre verificare il percorso di aggiornamento supportato e la compatibilità hardware. L’articolo su SFOS 22.0 MR3 illustra questa Maintenance Release; la panoramica di Sophos Firewall v23 descrive la nuova versione principale. Per un sistema di produzione, la scelta dovrebbe ricadere consapevolmente su una versione stabile adatta. Il fatto che EAP1 riceva un hotfix non è un motivo per passare a una versione preliminare per ottenere questa correzione.

Come si può sfruttare la vulnerabilità del kernel?

CVE-2026-98432 riguarda un errore use-after-free nell’elaborazione TCP IPv4 del kernel Linux. In questo caso, un percorso di elaborazione accede a memoria già liberata. La race condition alla base del problema nasce dai seguenti processi paralleli:

1. Durante l’apertura di una connessione TCP, i dati delle opzioni IPv4 vengono trasferiti tra strutture socket interne.
2. Parallelamente, un altro core del processore può elaborare un SYN ritrasmesso e preparare una risposta SYN-ACK.
3. Se nel frattempo la struttura associata viene liberata, l’elaborazione parallela può ancora accedere ai suoi dati delle opzioni.

Una race condition è un errore il cui verificarsi dipende dalla temporizzazione di processi paralleli. Perché un attacco riesca, l’elaborazione di rete e lo stato della memoria devono coincidere nel modo opportuno. Il semplice avvio di una normale connessione non dimostra quindi che la vulnerabilità sia stata sfruttata con successo.

Secondo Sophos, in determinate condizioni è possibile eseguire codice da remoto senza autenticazione con privilegi del kernel. La dimostrazione di laboratorio descritta pubblicamente è riuscita contro un server con un listener Multipath TCP (MPTCP). Non si tratta di una prova pubblicata di compromissione riuscita di un Sophos Firewall. Allo stesso modo, non se ne può dedurre che la sola disattivazione di MPTCP elimini la vulnerabilità sottostante.

Sophos classifica il proprio avviso come High e cita valutazioni CVSS differenti: 9,8 da parte della CNA del kernel Linux, 5,9 da parte di Red Hat a causa della race condition. Secondo lo stato delle conoscenze riportato nell’avviso aggiornato per l’ultima volta il 6 novembre, Sophos non era a conoscenza di segnalazioni pubbliche di sfruttamento attivo. Questa affermazione riferita a una data precisa non garantisce che non si verifichino attacchi.

Nella pratica, raggiungibilità e stato delle patch devono essere valutati separatamente. Limitare l’accesso amministrativo è utile, ma non dimostra che l’elaborazione del kernel interessata sia irraggiungibile. Anche un accesso riuscito con MFA non dice nulla sulla protezione contro un attacco senza autenticazione.

Procedura: installare l’hotfix sul firewall

1. Preparare la manutenzione

Prima dell’intervento, creare un backup della configurazione aggiornato e chiarire le possibilità di ripristino. Per le sedi remote, prevedere un accesso amministrativo alternativo o una persona reperibile sul posto. Questo è particolarmente importante quando l’unico collegamento al firewall passa attraverso il tunnel VPN che verrà interrotto dal riavvio.

Per la verifica successiva, preparare un breve elenco delle connessioni critiche per l’attività: accesso a Internet, DNS, VPN site-to-site, accesso remoto e applicazioni pubblicate. Un ping riuscito dopo la manutenzione non sostituisce una prova funzionale di questi servizi.

Se è in esecuzione una versione SFOS diversa da quelle sopra indicate, iniziare dalla pianificazione dell’aggiornamento firmware. La guida Aggiornare il firmware SFOS descrive i passaggi operativi. Pianificare l’aggiornamento e l’installazione dell’hotfix come attività distinte.

2. Verificare download e installazione

1. Accedere al WebAdmin e cercare nel Control center l’avviso relativo all’hotfix del kernel scaricato che richiede un riavvio.

2. Se gli hotfix automatici sono disattivati, aprire 4 – Device Console nella CLI e attivarli:

   system hotfix enable
   

3. Attendere il download. Dopo un eventuale aggiornamento firmware necessario, l’hotfix diventerà disponibile soltanto in seguito; per applicarlo è richiesto un ulteriore riavvio.

4. Riavviare il firewall durante la finestra di manutenzione. Il traffico viene interrotto.

5. Verificare quindi nella Device Console:

   system hotfix list
   

È decisiva la presenza della voce HF110626.1 con stato Installed. La sola comparsa dell’hotfix nell’elenco non basta. In SFOS 23.0, la pagina Hotfix: Security updates può essere ancora vuota nonostante l’installazione; per questo caso Sophos rimanda alla verifica tramite CLI.

3. Documentare il risultato

Come evidenza operativa, registrare nome del dispositivo, versione SFOS, momento della manutenzione e stato dell’hotfix verificato. Eseguire quindi i test di connessione preparati. In questo modo si distingue tra installazione riuscita e ripristino dell’operatività aziendale.

Se l’hotfix manca o il suo stato resta incerto, non registrare la manutenzione come completata. Confrontare prima versione del firmware, impostazione degli hotfix e avviso di download. Se il problema persiste, coinvolgere il supporto del produttore fornendo queste informazioni. Riavvii ripetuti senza nuove informazioni non costituiscono una soluzione affidabile.

Cluster HA: aggiornare entrambi i dispositivi

Sophos prescrive una sequenza precisa: verificare l’avviso di download su entrambi i dispositivi, riavviare prima il dispositivo Auxiliary, attendere il suo ritorno in servizio e riavviare poi il dispositivo Primary. Entrambi i dispositivi richiedono l’hotfix. Secondo la guida, il comando CLI per l’elenco degli hotfix è attualmente disponibile soltanto sul dispositivo che in quel momento è Primary.

Anche nella gestione tramite Sophos Fusion occorre includere il dispositivo Auxiliary. Dopo il failover, l’avviso può ricomparire perché riguarda l’altro dispositivo, ora attivo.

Prima del secondo riavvio, verificare inoltre che il partner sia nuovamente operativo e che il cluster presenti uno stato regolare. Una coppia HA non è un motivo per annunciare una manutenzione sicuramente priva di interruzioni: failover e comportamento delle sessioni devono rientrare nella pianificazione. Per completare l’intervento, registrare separatamente entrambi i dispositivi nel verbale di manutenzione e testare le applicazioni attraverso il cluster.

Aggiornare separatamente SD-RED 20 e SD-RED 60

L’hotfix del firewall non sostituisce l’aggiornamento RED. Per SD-RED 20 e SD-RED 60, Sophos indica il firmware 3.0.012, pubblicato il 5 novembre:

1. Nel WebAdmin aprire Backup & Firmware > Pattern Updates.
2. Se il firmware SD-RED è precedente alla versione 3.0.012, eseguire Update Pattern Now.
3. Con Install, distribuire il firmware ai dispositivi SD-RED collegati. Questi si riavviano durante l’installazione.

Per la distribuzione, Sophos indica come requisiti SFOS 20.0 MR3 e versioni successive oppure SFOS 21.0 MR1 e versioni successive. Queste indicazioni riguardano la distribuzione dell’aggiornamento RED e non devono essere confuse con le versioni destinatarie dell’hotfix del firewall. I vecchi modelli RED oltre la fine del supporto non ricevono questa correzione.

Per ogni sede remota, dopo il riavvio occorre verificare un’applicazione attraverso il collegamento RED. In presenza di più dispositivi, è utile un elenco delle sedi con versione del firmware ed esito della verifica: l’aggiornamento riuscito di un dispositivo non dimostra lo stato di tutte le altre sedi.

Domande frequenti sulla manutenzione

È sufficiente riavviare senza un avviso di hotfix visibile?

Un riavvio da solo non è una prova attendibile dell’installazione. Per completare l’intervento conta lo stato verificato di HF110626.1. In assenza di questa evidenza, l’installazione resta da chiarire.

Si possono applicare workaround Linux al Sophos Firewall?

Per i dispositivi Sophos occorre seguire la procedura del produttore. Sophos separa esplicitamente le proprie indicazioni generali per Linux dalla correzione specifica del prodotto. Non si dovrebbero quindi applicare all’appliance parametri del kernel o modifiche ai filtri dei pacchetti ricavati da una guida Linux.

Fonti

• Sophos: hotfix per CVE-2026-98432 – installazione e verifica
• Ubuntu: descrizione tecnica di CVE-2026-98432
• Sophos: avviso di sicurezza su CVE-2026-98432
• Sophos: firmware SD-RED 3.0.012 per CVE-2026-98432