Sophos Firewall : corriger la faille noyau CVE-2026-98432

Sophos a publié un correctif noyau pour CVE-2026-98432. Le point essentiel en exploitation : une mise à jour téléchargée ne protège le firewall qu’après le redémarrage requis. Même lorsque la distribution automatique des correctifs est activée, il convient donc de vérifier leur état d’installation et de prévoir une fenêtre de maintenance.

Cet article distingue la vulnérabilité technique de la procédure de mise à jour propre aux équipements Sophos. Sources vérifiées le 11 novembre 2026. Les pages du fabricant citées peuvent être complétées ultérieurement avec d’autres versions de firmware.

Quelles versions Sophos nécessitent une vérification ?

Les corrections suivantes sont disponibles pour ces produits et versions SFOS :

Ce tableau présente les corrections disponibles, et non une liste exhaustive de tous les builds vulnérables. Sophos n’y publie pas de matrice complète indiquant la première et la dernière version SFOS vulnérable. L’absence d’une version dans le tableau ne permet donc pas de conclure qu’elle est à l’abri. Cela concerne notamment l’évaluation d’une installation sous SFOS 21.5 ou 22.0 MR2.

Avant de changer de version, il convient de vérifier le chemin de mise à niveau pris en charge et la compatibilité matérielle. L’article consacré à SFOS 22.0 MR3 présente cette version de maintenance ; l’aperçu de Sophos Firewall v23 décrit la nouvelle version majeure. Pour un système de production, le choix doit se porter délibérément sur une version validée et adaptée. La disponibilité d’un correctif pour EAP1 ne justifie pas à elle seule le passage à une préversion.

Comment la faille du noyau peut-elle être exploitée ?

CVE-2026-98432 concerne une erreur de type use-after-free dans le traitement TCP IPv4 du noyau Linux. Un chemin de traitement accède alors à une zone mémoire déjà libérée. La condition de concurrence sous-jacente résulte des opérations parallèles suivantes :

1. Lors de l’établissement d’une connexion TCP, les données des options IPv4 sont transmises entre des structures de socket internes.
2. En parallèle, un autre cœur du processeur peut traiter un SYN retransmis et préparer une réponse SYN-ACK.
3. Si la structure associée est libérée entre-temps, le traitement parallèle peut encore accéder aux données de ses options.

Une condition de concurrence est une erreur dont l’apparition dépend de l’enchaînement temporel d’opérations parallèles. Pour qu’une attaque réussisse, le traitement réseau et l’état de la mémoire doivent coïncider de façon particulière. Un simple établissement de connexion ne démontre donc pas une exploitation réussie.

Selon Sophos, certaines conditions peuvent permettre une exécution de code à distance, sans authentification, avec les privilèges du noyau. La démonstration publique en laboratoire a été réalisée contre un serveur disposant d’un listener Multipath TCP (MPTCP). Il ne s’agit pas d’une preuve publiée de prise de contrôle réussie d’un Sophos Firewall. On ne peut pas davantage en déduire que la seule désactivation de MPTCP élimine la vulnérabilité sous-jacente.

Sophos classe son avis au niveau High et cite des scores CVSS différents : 9,8 selon la CNA du noyau Linux, 5,9 selon Red Hat en raison de la condition de concurrence. Dans la dernière mise à jour de l’avis, datée du 6 novembre, Sophos indiquait ne connaître aucun rapport public d’exploitation active. Cette déclaration datée ne garantit pas l’absence d’attaques.

En pratique, l’accessibilité réseau et l’état des correctifs doivent être évalués séparément. Restreindre l’accès à l’administration est utile, mais ne prouve pas que le traitement vulnérable du noyau est inaccessible. Une authentification MFA réussie ne démontre pas non plus une protection contre une attaque sans authentification.

Procédure : installer le correctif sur le firewall

1. Préparer la maintenance

Avant l’intervention, créer une sauvegarde de configuration à jour et clarifier les possibilités de restauration. Pour les sites distants, prévoir un accès d’administration alternatif ou une personne joignable sur place. C’est particulièrement important lorsque le seul accès au firewall passe par le tunnel VPN qui sera interrompu lors du redémarrage.

Pour les vérifications après intervention, dresser une courte liste des connexions critiques : accès Internet, DNS, VPN site à site, accès distant et applications publiées. Un ping réussi après la maintenance ne remplace pas un test fonctionnel de ces services.

Si une autre version SFOS que celles mentionnées ci-dessus est installée, commencer par planifier la mise à niveau du firmware. Les opérations sont décrites dans la procédure de mise à jour du firmware SFOS. Prévoir la mise à niveau et l’installation du correctif comme deux étapes distinctes.

2. Vérifier le téléchargement et l’installation

1. Se connecter au WebAdmin et rechercher dans Control center le message indiquant qu’un correctif noyau a été téléchargé et nécessite un redémarrage.

2. Si les correctifs automatiques sont désactivés, ouvrir 4 – Device Console dans la CLI et les activer :

   system hotfix enable
   

3. Attendre le téléchargement. Après une mise à niveau nécessaire du firmware, le correctif doit d’abord devenir disponible ; un redémarrage supplémentaire est requis pour l’appliquer.

4. Redémarrer le firewall pendant la fenêtre de maintenance. Le trafic est interrompu pendant cette opération.

5. Vérifier ensuite dans la Device Console :

   system hotfix list
   

L’élément déterminant est la présence de HF110626.1 avec l’état Installed. La simple apparition du correctif dans la liste ne suffit pas. Sous SFOS 23.0, la page Hotfix: Security updates peut encore être vide malgré l’installation ; Sophos renvoie alors à la vérification par CLI.

3. Documenter le résultat

Pour conserver une trace d’exploitation, consigner le nom de l’équipement, la version SFOS, la date et l’heure de la maintenance ainsi que l’état vérifié du correctif. Effectuer ensuite les tests de connexion préparés. Cela permet de distinguer une installation réussie du rétablissement effectif des services métier.

Si le correctif est absent ou si son état reste incertain, ne pas considérer la maintenance comme terminée. Comparer d’abord la version du firmware, le paramétrage des correctifs et le message de téléchargement. Si le problème persiste, contacter le support du fabricant avec ces informations. Des redémarrages répétés sans nouvel élément ne constituent pas une méthode de dépannage fiable.

Cluster HA : mettre à jour les deux équipements

Sophos impose un ordre précis : vérifier le message de téléchargement sur les deux équipements, redémarrer d’abord l’équipement Auxiliary, attendre son retour, puis redémarrer l’équipement Primary. Les deux équipements doivent recevoir le correctif. Selon la procédure, la commande CLI affichant la liste des correctifs n’est actuellement disponible que sur l’équipement qui joue le rôle Primary.

Même avec une administration via Sophos Fusion, l’équipement Auxiliary doit être pris en compte. Après le basculement, le message peut réapparaître parce qu’il concerne l’autre équipement, devenu actif.

Avant le second redémarrage, vérifier également que le partenaire est à nouveau opérationnel et que le cluster est sain. La présence d’une paire HA ne permet pas d’annoncer une maintenance garantie sans interruption : le basculement et le comportement des sessions doivent être intégrés à la planification. Pour clôturer l’intervention, consigner séparément les deux équipements dans le compte rendu de maintenance et tester les applications à travers le cluster.

Mettre à jour séparément les SD-RED 20 et SD-RED 60

Le correctif du firewall ne remplace pas la mise à jour RED. Pour les SD-RED 20 et SD-RED 60, Sophos indique le firmware 3.0.012, publié le 5 novembre :

1. Dans le WebAdmin, ouvrir Backup & Firmware > Pattern Updates.
2. Si le firmware SD-RED est antérieur à 3.0.012, exécuter Update Pattern Now.
3. Cliquer sur Install pour distribuer le firmware aux équipements SD-RED connectés. Ceux-ci redémarrent pendant l’installation.

Pour la distribution, Sophos indique comme prérequis SFOS 20.0 MR3 et versions ultérieures, ou SFOS 21.0 MR1 et versions ultérieures. Ces indications concernent la distribution de la mise à jour RED et ne doivent pas être confondues avec les versions destinataires du correctif du firewall. Les anciens modèles RED arrivés en fin de support ne reçoivent pas cette correction.

Après le redémarrage, tester une application via la connexion RED sur chaque site distant. En présence de plusieurs équipements, une liste des sites avec la version du firmware et le résultat du contrôle facilite le suivi : la mise à jour réussie d’un équipement ne prouve pas que les autres sites sont à jour.

Questions fréquentes sur la maintenance

Un redémarrage sans message de correctif visible suffit-il ?

Un redémarrage seul ne constitue pas une preuve fiable d’installation. Pour clôturer l’intervention, il faut avoir vérifié l’état de HF110626.1. Sans cette preuve, l’installation reste incertaine.

Peut-on appliquer des mesures de contournement Linux sur Sophos Firewall ?

Pour les équipements Sophos, suivre la procédure du fabricant. Sophos distingue explicitement ses conseils Linux généraux de la correction propre au produit. Il ne faut donc pas transposer sur l’appliance des paramètres du noyau ou des modifications du filtrage de paquets provenant d’une procédure Linux.

Sources

• Sophos : correctif pour CVE-2026-98432 – installation et vérification
• Ubuntu : description technique de CVE-2026-98432
• Sophos : avis de sécurité relatif à CVE-2026-98432
• Sophos : firmware SD-RED 3.0.012 pour CVE-2026-98432