Sophos Firewall Hotfix CVE-2026-98432: Neustart nötig – Grams IT

Sophos hat am 6. November 2026 einen Hotfix für Sophos Firewall veröffentlicht, der die Linux-Kernel-Lücke CVE-2026-98432 schließt. Anders als die meisten Sophos-Hotfixes wirkt dieser nicht von allein: Die Firewall lädt ihn zwar automatisch herunter, installiert wird er aber erst beim nächsten Neustart. Wer den Hinweis im Control Center übersieht, hat den Hotfix auf der Platte liegen und den verwundbaren Kernel weiter im Speicher.

Dieser Artikel erklärt, warum es den Hotfix gibt, welche Versionen ihn bekommen, wie Sie ihn installieren und prüfen und was bei Hochverfügbarkeits-Clustern (HA) anders läuft. Grundlage sind der Sophos-Knowledgebase-Artikel KBA-000049730 und das zugehörige Sophos Security Advisory.

Warum Sophos den Kernel-Hotfix ausliefert

CVE-2026-98432 ist ein Use-after-free-Fehler im IPv4-TCP-Code des Linux-Kernels, also ein Zugriff auf Speicher, der bereits freigegeben wurde. Laut NVD-Eintrag übergibt die Funktion tcp_v4_syn_recv_sock() die IP-Optionen einer Verbindungsanfrage an den neuen Socket, ohne sie zu kopieren. Verarbeitet ein anderer CPU-Kern gleichzeitig ein wiederholtes SYN-Paket für dieselbe Anfrage und baut daraus ein SYN-ACK, kann der neue Socket samt Optionen schon freigegeben sein. Der Zugriff landet dann in ip_options_build() auf freigegebenem Speicher. Ein ähnliches Problem besteht bei der Migration von Request-Sockets (net.ipv4.tcp_migrate_req=1 oder ein BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE).

Die Korrektur ist unspektakulär: Der Kernel gibt die Optionen jetzt über kfree_rcu() frei, also erst nach einer RCU-Wartezeit, in der laufende Leser fertig werden. IPv6 ist vom ersten Fehler nicht betroffen, weil tcp_v6_syn_recv_sock() die Optionen kopiert. Betroffen sind laut NVD Kernel ab Version 4.4.

Wie gefährlich die Lücke ist

Die CVE-Stelle des Linux-Kernels bewertet die Lücke mit CVSS 3.1 9.8 (kritisch): Angriff über das Netz, keine Anmeldung, keine Nutzerinteraktion. Nach der Analyse von Akamai braucht ein Angreifer nur Netzwerkzugang zu einem IPv4-TCP-Dienst auf einem ungepatchten Kernel. Ausgelöst wird der Fehler durch eine Verbindungsanfrage mit IPv4-Optionen und eine Wiederholung derselben Anfrage. Verliert der Angreifer das Rennen, scheitert nur der Handshake, und er kann es erneut versuchen.

Brisant wurde die Lücke am 27. Oktober. Anthropic, dessen Forscher den Fehler gemeldet hatte, beschrieb einen Exploit, der unangemeldet Befehle mit Root-Rechten auf Linux-Servern ausführt, die einen Multipath-TCP-Listener (MPTCP) betreiben. Veröffentlicht hat Anthropic den Exploit laut Akamai nicht. Das Go-Sicherheitsteam wies auf der Mailingliste oss-security darauf hin, dass der Fehler selbst nicht an MPTCP gebunden ist und Systeme ohne MPTCP-Listener ebenfalls angreifbar sein können. Zudem schalten Go-Programme seit Go 1.24 MPTCP für Linux-Listen-Sockets standardmäßig ein, ohne dass jemand das bewusst konfiguriert.

Zeitleiste zu CVE-2026-98432: Upstream-Fix am 5.10., CVE am 15.10., Anthropic-Exploit am 27.10., Go-Warnung am 29.10., Sophos-Advisory am 2.11., SD-RED-Firmware am 5.11., Hotfix HF110626.1 am 6.11.2026

Zwischen dem Fix im Upstream-Kernel am 5. Oktober und dem Sophos-Hotfix am 6. November liegen 32 Tage, ab Veröffentlichung der CVE am 15. Oktober noch 22 (eigene Rechnung nach den Daten von Akamai, NVD und Sophos). Andere Hersteller waren nicht schneller: Ubuntu und Red Hat Enterprise Linux hatten laut Akamai am 30. Oktober noch keine korrigierten Kernel, und auf der Ubuntu-Sicherheitsseite standen die Kernel von 24.04 LTS und 22.04 LTS mit Stand 9. November noch auf „in Arbeit“.

Sophos bewertet die Lücke niedriger

Sophos selbst stuft das Advisory als „High“ ein, nicht als kritisch, und führt dazu an, Red Hat bewerte die Lücke mit 5,9, weil der Angriff ein gewonnenes Rennen voraussetze. Diese Angabe ist überholt. Auf der Red-Hat-Seite zur CVE steht heute „Critical“ mit 9,8, letzte Änderung am 2. November. Red Hat begründet das damit, dass ein Angreifer über normalen IPv4-TCP-Verkehr ohne lokale Rechte oder Nutzerinteraktion Speicherkorruption oder einen sofortigen Absturz auslösen könne, auch wenn zuverlässige Codeausführung präzise Kontrolle über den Heap erfordere.

Fairerweise: Das Argument mit dem Race ist nicht falsch, und Sophos schreibt, dass ihm keine Angriffe in freier Wildbahn bekannt seien. Wie sich die Lücke konkret auf SFOS ausnutzen ließe, beschreibt Sophos nicht. Für mich ändert das wenig: Eine Firewall steht am Rand des Netzes und nimmt dort TCP-Verbindungen an. Schon ein von außen ausgelöster Absturz legt die ganze Anbindung lahm.

Voraussetzungen für den Sophos-Firewall-Hotfix

Sophos liefert den Hotfix HF110626.1 nur für drei Versionen aus:

Sophos Firewall 23.0 GA
Sophos Firewall 23.0 EAP1
Sophos Firewall 22.0 MR3

Läuft Ihre Firewall auf einer anderen Version, bekommt sie den Hotfix vorerst nicht. Sophos empfiehlt, auf 22.0 MR3 oder 23.0 zu aktualisieren. Kurz nach dem Upgrade wird der Hotfix auf der Firewall verfügbar, und dann ist ein weiterer Neustart nötig, um ihn zu aktivieren. Wer also von einer älteren Version kommt, plant zwei Neustarts ein. Sophos kündigt an, das Advisory zu aktualisieren, sobald Hotfixes für weitere Versionen erscheinen.

Die zweite Voraussetzung ist die Einstellung „Allow automatic installation of hotfixes“. Sie ist laut Sophos standardmäßig aktiv, und dann lädt die Firewall den Hotfix selbst herunter. Wer sie abgeschaltet hat, muss sie wieder einschalten, sonst kommt der Hotfix nicht an.

Ebenfalls betroffen sind die Sophos SD-RED 20 und SD-RED 60. Für sie ist die Lücke in der SD-RED-Firmware 3.0.012 behoben, die Sophos am 5. November als Pattern-Update über die Firewall verteilt hat. Einen Workaround nennt Sophos für keines der Produkte.

Sophos Firewall Hotfix installieren

Die Installation besteht im Kern aus einem Neustart. Die Schritte nach KBA-000049730:

Prüfen, ob die automatische Hotfix-Installation aktiv ist. Falls nicht, auf der CLI einschalten:

system hotfix enable

Danach warten, bis der Hotfix heruntergeladen ist. Ob er da ist, sehen Sie im Control Center oder auf der CLI.

In der Web-Admin-Konsole anmelden und im Control Center nach dem Hinweis suchen, dass ein kritischer Hotfix mit Neustartbedarf heruntergeladen wurde und vor CVE-2026-98432 schützt. Zusätzlich kann ein Sophos-Help-Pop-up erscheinen.
Die Firewall neu starten. Beim Hochfahren wird der Hotfix automatisch installiert.
Optional, aber empfehlenswert: den Installationsstatus auf der CLI prüfen (siehe unten).

Der Neustart unterbricht den Datenverkehr. Sophos rät deshalb zu einem Wartungsfenster. Ich würde dieses Fenster aber nicht erst in drei Wochen ansetzen, sondern in den nächsten Tagen, notfalls am Abend.

Installation auf der CLI prüfen

Hier gibt es eine Falle. Unter SFOS 23.0 bleibt die Seite „Hotfix: Security updates“ in der Web-Oberfläche auch nach dem Neustart leer. Sophos erklärt das damit, dass dieser Hotfix eine manuelle Aktion erfordert und sein Status deshalb noch nicht in der Oberfläche erscheint. Das soll in den kommenden Wochen nachgereicht werden.

Bis dahin gilt die CLI. Melden Sie sich an, wählen Sie 4 für die Device Console und geben Sie ein:

console> system hotfix list

In der Liste muss HF110626.1 auftauchen, mit dem Status „Installed“. Andere Hotfixes in der Liste sind normal. Steht HF110626.1 dort, aber noch nicht als installiert, fehlt der Neustart.

Sophos Firewall im HA-Betrieb: Reihenfolge beachten

Bei einem Hochverfügbarkeits-Paar müssen beide Geräte neu gestartet werden, und zwar nacheinander. Sophos gibt diese Reihenfolge vor:

Prüfen, dass der Hotfix-Hinweis im Control Center auf beiden Geräten erscheint, auf dem primären und auf dem Auxiliary-Gerät.
Zuerst das Auxiliary-Gerät neu starten.
Erst wenn es wieder verfügbar ist, das primäre Gerät neu starten.

Ein Detail, das bei der Kontrolle Zeit kosten kann: system hotfix list funktioniert derzeit nur auf dem primären HA-Gerät. Den Hinweis im Control Center zeigen dagegen beide Geräte an. Wer auf dem Auxiliary-Gerät per CLI nachsehen will, wird dort also nicht fündig.

HA-Cluster, die über Sophos Fusion verwaltet werden

Für HA-Paare, die zentral über Sophos Fusion verwaltet werden, betont Sophos, dass auch das Auxiliary-Gerät neu gestartet werden muss. Dazu ein Hinweis, der sonst für Verwirrung sorgt: Nach dem Neustart des primären Geräts kann der Hotfix-Hinweis im Control Center erneut auftauchen. Er gehört dann zum bisherigen Auxiliary-Gerät, das beim Neustart des primären per Failover zum aktuellen primären Gerät geworden ist.

In den Kommentaren unter dem Bericht von Born City berichten Leser, dass die Firewall nur einen kleinen Hinweis in der Web-Oberfläche zeigte, ohne E-Mail oder Pop-up. Das sind Erfahrungsberichte, keine Herstellerangaben. Sie passen aber zum Gesamtbild: Wer seine Firewalls nicht regelmäßig im Control Center ansieht, bekommt von diesem Hotfix womöglich nichts mit.

Was Sie jetzt tun sollten

Für Sophos-Firewalls ist die Lage klar. Prüfen Sie die Version, bringen Sie ältere Geräte auf 22.0 MR3 oder 23.0, kontrollieren Sie die automatische Hotfix-Installation, starten Sie neu und prüfen Sie mit system hotfix list, ob HF110626.1 als „Installed“ erscheint. Bei HA-Paaren zuerst das Auxiliary-Gerät, dann das primäre.

Die Lücke betrifft aber nicht nur Sophos. Das Advisory gibt selbst Hinweise für Linux-Systeme, die Sie anderweitig betreiben: Systeme mit TCP-Diensten für nicht vertrauenswürdige Netze zuerst prüfen, internetseitige Systeme vorziehen, den laufenden Kernel gegen den Security-Tracker der Distribution abgleichen und bei Linux-basierten Appliances anderer Hersteller nachfragen. MPTCP abzuschalten verkleinert laut Sophos den bekannten Angriffsweg, beseitigt die Lücke aber nicht und ersetzt den gepatchten Kernel nicht.

Fazit

HF110626.1 schließt eine Kernel-Lücke, die aus dem Netz erreichbar ist und für die ein funktionierender Root-Exploit beschrieben wurde. Der Hotfix kommt automatisch, wirkt aber erst nach einem Neustart, und unter SFOS 23.0 zeigt die Web-Oberfläche nicht einmal an, ob er installiert ist. Dass Sophos die Lücke mit einer inzwischen überholten Red-Hat-Bewertung herunterstuft, halte ich für unglücklich, weil es dazu verleiten kann, den Neustart aufzuschieben.

Planen Sie den Neustart diese Woche ein, und prüfen Sie danach auf der CLI. Ein Hotfix, der nur heruntergeladen ist, schützt nicht.

Quellen: