Sophos Firewall: Kernel-Lücke CVE-2026-98432 mit Hotfix schliessen

Sophos hat für CVE-2026-98432 einen Kernel-Hotfix bereitgestellt. Für den Betrieb entscheidend: Ein heruntergeladenes Update schützt die Firewall erst nach dem erforderlichen Neustart. Wer auf die automatische Hotfix-Verteilung vertraut, sollte deshalb den Installationsstatus kontrollieren und ein Wartungsfenster einplanen.

Dieser Beitrag trennt die technische Sicherheitslücke vom konkreten Updateweg für Sophos-Geräte. Stand der Quellenprüfung: 11. November 2026. Die verlinkten Herstellerseiten können später weitere Firmware-Versionen ergänzen.

Welche Sophos-Versionen benötigen Aufmerksamkeit?

Für die folgenden Produkte und SFOS-Versionen stehen diese Korrekturen bereit:

Produkt / Version	Verfügbare Abhilfe
SFOS 22.0 MR3	Hotfix HF110626.1, Neustart erforderlich
SFOS 23.0 GA	Hotfix HF110626.1, Neustart erforderlich
SFOS 23.0 EAP1	Hotfix HF110626.1, Neustart erforderlich
Andere SFOS-Versionen	Keine weiteren Hotfix-Zielversionen in der geprüften Meldung genannt; Sophos empfiehlt Upgrade auf 22.0 MR3 oder 23.0
Sophos SD-RED 20 / SD-RED 60	Separate RED-Firmware 3.0.012

Das ist eine Tabelle der verfügbaren Korrekturen, keine vollständige Liste aller verwundbaren Builds. Sophos veröffentlicht dort keine lückenlose Betroffenheitsmatrix mit frühester und letzter verwundbarer SFOS-Version. Aus einem fehlenden Tabelleneintrag lässt sich deshalb keine Entwarnung ableiten. Das betrifft beispielsweise die Einordnung einer Installation mit SFOS 21.5 oder 22.0 MR2.

Vor einem Versionswechsel sollten der unterstützte Upgradepfad und die Hardwarekompatibilität geprüft werden. Der Beitrag zu SFOS 22.0 MR3 ordnet das Maintenance Release ein; der Überblick zu Sophos Firewall v23 beschreibt die neue Hauptversion. Für ein Produktivsystem sollte die Wahl bewusst auf eine passende freigegebene Version fallen. Dass EAP1 einen Hotfix erhält, ist kein Grund, für diese Korrektur auf eine Vorabversion zu wechseln.

Wie lässt sich die Kernel-Lücke ausnutzen?

CVE-2026-98432 betrifft einen Use-after-free-Fehler in der IPv4-TCP-Verarbeitung des Linux-Kernels. Dabei greift ein Verarbeitungspfad auf Speicher zu, der bereits freigegeben wurde. Die zugrunde liegende Race Condition entsteht durch folgende parallele Abläufe:

Beim Aufbau einer TCP-Verbindung werden IPv4-Optionsdaten zwischen internen Socket-Strukturen weitergereicht.
Parallel kann ein anderer Prozessorkern einen erneut eintreffenden SYN verarbeiten und eine SYN-ACK-Antwort vorbereiten.
Wird die zugehörige Struktur währenddessen freigegeben, kann die parallele Verarbeitung noch auf deren Optionsdaten zugreifen.

Eine Race Condition ist ein Fehler, dessen Auftreten vom zeitlichen Zusammenspiel paralleler Abläufe abhängt. Für einen erfolgreichen Angriff müssen Netzwerkverarbeitung und Speicherzustand passend zusammentreffen. Ein gewöhnlicher Verbindungsaufbau allein belegt daher keine erfolgreiche Ausnutzung.

Unter bestimmten Bedingungen ist laut Sophos Codeausführung aus der Ferne ohne Anmeldung mit Kernel-Rechten möglich. Der öffentlich beschriebene Labornachweis gelang gegen einen Server mit einem Multipath-TCP-Listener (MPTCP). Das ist kein veröffentlichter Nachweis einer erfolgreichen Übernahme einer Sophos Firewall. Ebenso wenig lässt sich daraus ableiten, dass allein das Abschalten von MPTCP die zugrunde liegende Lücke beseitigt.

Sophos stuft seine Meldung als High ein und nennt unterschiedliche CVSS-Bewertungen: 9,8 durch die Linux-Kernel-CNA, 5,9 durch Red Hat wegen der Race Condition. Nach Kenntnisstand der zuletzt am 6. November aktualisierten Meldung waren Sophos keine öffentlichen Berichte über aktive Ausnutzung bekannt. Diese datierte Aussage garantiert nicht, dass Angriffe ausbleiben.

Für die Praxis sollten Erreichbarkeit und Patchstatus getrennt bewertet werden. Ein eingeschränkter Verwaltungszugang ist sinnvoll, liefert aber keinen Nachweis, dass die betroffene Kernel-Verarbeitung unerreichbar ist. Auch eine erfolgreiche Anmeldung mit MFA sagt nichts über den Schutz vor einem Angriff ohne Anmeldung aus.

Anleitung: Hotfix auf der Firewall installieren

1. Wartung vorbereiten

Vor dem Eingriff ein aktuelles Konfigurationsbackup erstellen und die Wiederherstellungsmöglichkeiten klären. Bei entfernten Standorten sollte ein alternativer Verwaltungszugang oder eine erreichbare Person vor Ort eingeplant werden. Das ist besonders wichtig, wenn die einzige Verbindung zur Firewall über den VPN-Tunnel läuft, der beim Neustart unterbrochen wird.

Für die Nachkontrolle eine kurze Liste der geschäftskritischen Verbindungen anlegen: Internetzugang, DNS, Site-to-Site-VPN, Fernzugriff und veröffentlichte Anwendungen. Ein erfolgreicher Ping nach der Wartung ersetzt keinen Funktionstest dieser Dienste.

Läuft eine andere als die oben genannte SFOS-Version, zuerst das Firmware-Upgrade planen. Die Bedienung beschreibt die Anleitung SFOS-Firmware aktualisieren. Das Upgrade und die Hotfix-Installation als getrennte Arbeitsschritte einplanen.

2. Download und Installation prüfen

Im WebAdmin anmelden und im Control center die Meldung zum heruntergeladenen Kernel-Hotfix mit erforderlichem Neustart suchen.
Falls automatische Hotfixes deaktiviert sind, in der CLI 4 – Device Console öffnen und aktivieren:
```
system hotfix enable
```
Den Download abwarten. Nach einem notwendigen Firmware-Upgrade muss der Hotfix erst anschliessend verfügbar werden; zur Anwendung ist ein weiterer Neustart erforderlich.
Die Firewall im Wartungsfenster neu starten. Dabei wird der Datenverkehr unterbrochen.
Anschliessend in der Device Console prüfen:
```
system hotfix list
```

Entscheidend ist der Eintrag HF110626.1 mit dem Status Installed. Die blosse Auflistung des Hotfixes reicht nicht. Unter SFOS 23.0 kann die Seite Hotfix: Security updates trotz Installation noch leer sein; Sophos verweist für diesen Fall auf die CLI-Prüfung.

3. Ergebnis dokumentieren

Als Betriebsnachweis sollten Gerätename, SFOS-Version, Wartungszeitpunkt und der geprüfte Hotfixstatus festgehalten werden. Anschliessend die vorbereiteten Verbindungstests durchführen. So wird zwischen erfolgreicher Installation und wiederhergestelltem Geschäftsbetrieb unterschieden.

Fehlt der Hotfix oder bleibt sein Status unklar, die Wartung nicht als abgeschlossen verbuchen. Zuerst Firmwarestand, Hotfix-Einstellung und Downloadmeldung miteinander abgleichen. Bei fortbestehendem Problem den Hersteller-Support mit diesen Angaben einbeziehen. Wiederholte Neustarts ohne neue Erkenntnis sind keine verlässliche Fehlerbehebung.

HA-Cluster: beide Geräte aktualisieren

Sophos gibt eine feste Reihenfolge vor: Downloadmeldung auf beiden Geräten prüfen, zuerst das Auxiliary-Gerät neu starten, dessen Rückkehr abwarten und danach das Primary-Gerät neu starten. Beide Geräte benötigen den Hotfix. Der CLI-Befehl zur Hotfixliste steht laut Anleitung derzeit nur auf dem jeweiligen Primary zur Verfügung.

Auch bei Verwaltung über Sophos Fusion muss das Auxiliary-Gerät berücksichtigt werden. Nach dem Failover kann die Meldung erneut erscheinen, weil sie das nun aktive andere Gerät betrifft.

Vor dem zweiten Neustart sollte zusätzlich geprüft werden, dass der Partner wieder betriebsbereit ist und der Cluster einen gesunden Zustand zeigt. Ein HA-Paar ist kein Grund, die Wartung als garantiert unterbrechungsfrei anzukündigen: Failover und Sitzungsverhalten müssen in die Planung einfliessen. Für den Abschluss beide Geräte im Wartungsprotokoll einzeln erfassen und die Anwendungen über den Cluster testen.

SD-RED 20 und SD-RED 60 separat aktualisieren

Der Firewall-Hotfix ersetzt das RED-Update nicht. Für SD-RED 20 und SD-RED 60 nennt Sophos die am 5. November veröffentlichte Firmware 3.0.012:

Im WebAdmin Backup & Firmware > Pattern Updates öffnen.
Ist die SD-RED-Firmware älter als 3.0.012, Update Pattern Now ausführen.
Mit Install die Firmware auf die verbundenen SD-RED-Geräte verteilen. Diese starten während der Installation neu.

Sophos Firewall Pattern Updates: RED Firmware 3.0.012 ist verfügbar, die Schaltfläche Install ist hervorgehoben — RED nicht vergessen: Unter Backup & Firmware > Pattern Updates muss die verfügbare RED-Firmware mit Install auf die Geräte verteilt werden. Der Firewall-Hotfix allein aktualisiert die SD-RED-Geräte nicht.

Für die Verteilung nennt Sophos als Voraussetzungen SFOS 20.0 MR3 und neuer beziehungsweise SFOS 21.0 MR1 und neuer. Diese Angaben betreffen die Verteilung des RED-Updates und dürfen nicht mit den Zielversionen des Firewall-Hotfixes verwechselt werden. Alte RED-Modelle nach Supportende erhalten diese Korrektur nicht.

Für jeden Aussenstandort sollte nach dem Neustart eine Anwendung über die RED-Verbindung geprüft werden. Bei mehreren Geräten hilft eine Standortliste mit Firmwarestand und Prüfergebnis: Ein erfolgreich aktualisiertes Gerät belegt nicht den Zustand aller anderen Standorte.

Häufige Fragen zur Wartung

Ist ein Neustart ohne sichtbare Hotfixmeldung ausreichend?

Ein Neustart allein ist kein belastbarer Installationsnachweis. Für den Abschluss zählt der kontrollierte Status von HF110626.1. Fehlt dieser Nachweis, bleibt die Installation ungeklärt.

Kann man Linux-Workarounds auf der Sophos Firewall anwenden?

Für Sophos-Geräte sollte der Herstellerweg verwendet werden. Sophos trennt seine allgemeinen Linux-Hinweise ausdrücklich von der produktspezifischen Abhilfe. Eigene Kernelparameter oder Paketfilteränderungen aus einer Linux-Anleitung sollten deshalb nicht auf die Appliance übertragen werden.