Wer eine Sophos Firewall betreibt, kommt um einen Neustart nicht herum. Seit dem 6. November 2026 verteilt Sophos den Hotfix HF110626.1 gegen CVE-2026-98432, eine Use-after-free-Lücke im IPv4-TCP-Code des Linux-Kernels, der auch im Firewall-Betriebssystem SFOS steckt. Der Hotfix kommt zwar über den gewohnten Mechanismus automatisch aufs Gerät, installiert wird er aber erst beim nächsten Neustart. Bis dahin bleibt die Firewall angreifbar, obwohl die Korrektur schon auf der Platte liegt.

Sophos hat sein Advisory am 2. November veröffentlicht und zuletzt am 6. November aktualisiert. Angriffe in freier Wildbahn sind dem Hersteller nach eigenen Angaben bislang nicht bekannt. Harmlos ist der Fehler trotzdem nicht: Er lässt sich ohne Anmeldung über das Netz auslösen, und Forscher haben im Labor bereits gezeigt, dass sich darüber auf einem Server mit MPTCP-Listener Befehle mit Root-Rechten ausführen lassen.

Race Condition beim TCP-Verbindungsaufbau

Die Ursache liegt im Drei-Wege-Handshake. Schickt ein Client im SYN-Paket IPv4-Optionen wie Record Route oder Timestamp mit, merkt sich der Kernel diese an der halb offenen Verbindung, dem Request Socket. Ist der Handshake abgeschlossen, übergibt die Funktion tcp_v4_syn_recv_sock() die Optionen an den neuen Socket, ohne sie zu kopieren. Verarbeitet ein anderer CPU-Kern gleichzeitig ein wiederholtes SYN derselben Verbindung, baut er ein SYN-ACK und liest dabei dieselben Optionen. Nichts hindert den Kernel daran, den neuen Socket in diesem Moment schon wieder abzubauen – und dabei gibt er die Optionen mit einem einfachen kfree() frei, während der andere Kern noch darauf zugreift. Ein ähnliches Problem besteht bei der Migration von Request Sockets, etwa mit net.ipv4.tcp_migrate_req=1.

Was daraus folgen kann, beschreibt der CVE-Eintrag ungewöhnlich ausführlich: Gelingt es, den freigegebenen Speicher neu zu belegen, schickt der Kernel benachbarte Heap-Inhalte im SYN-ACK direkt an den Angreifer, schreibt außerhalb der vorgesehenen Grenzen oder stürzt ab. Die Korrektur gibt die Optionen erst nach einer RCU-Wartefrist frei (kfree_rcu()), wie es andere Codepfade bereits tun. Betroffen sind Kernel ab Version 4.4, behoben ist der Fehler unter anderem in 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.56, 7.2.10 und 7.3.

Das CVE-Team des Linux-Kernels, das als CNA für den Eintrag zuständig ist, bewertet die Lücke nach CVSS 3.1 mit 9,8 von 10 Punkten: Angriff über das Netz, geringe Komplexität, weder Rechte noch Mitwirkung eines Nutzers nötig. Red Hat hatte zunächst nur 5,9 Punkte vergeben, weil ein Angreifer ein Wettrennen zwischen zwei CPU-Kernen gewinnen muss, wie BleepingComputer am 30. Oktober berichtete. Inzwischen führt Red Hat die Lücke ebenfalls als „Critical“ mit 9,8 Punkten. Sophos selbst stuft sein Advisory als „High“ ein.

Exploit gegen MPTCP-Server in knapp einer Stunde

Wie ernst die Lücke ist, machte ein Bericht des Frontier Red Team von Anthropic vom 27. Oktober 2026 deutlich. Darin beschreibt das Team, wie ein unveröffentlichtes KI-Modell nach anfänglicher Anleitung einen Exploit für einen Linux-Server mit MPTCP-Listener (Multipath TCP) schrieb. Der Angriff läuft in zwei Stufen: Zuerst bringt er den Kernel dazu, über ein manipuliertes Längenfeld mehr Bytes zurückzuschicken als vorgesehen, bis darin ein Kernel-Zeiger steckt und die Adressraum-Randomisierung KASLR ausgehebelt ist. Danach nutzt er denselben Fehler für einen Pufferüberlauf, überschreibt einen Callback-Zeiger und führt einen beliebigen Befehl als root aus. Im Proof of Concept dauerte das Auslesen des Zeigers 48 Minuten, die Codeausführung rund fünf weitere. Ein verlorenes Wettrennen lässt laut Bericht nur den Handshake scheitern, ohne das System abstürzen zu lassen – ein Angreifer kann es also immer wieder versuchen.

Der Fehler selbst ist allerdings nicht auf MPTCP beschränkt. Das Go-Sicherheitsteam weist in einer Warnung vom 29. Oktober darauf hin, dass auch Systeme ohne MPTCP-Listener für ähnliche Angriffe anfällig sein können. Dass MPTCP trotzdem im Fokus steht, hat einen praktischen Grund: Seit Go 1.24 schalten Go-Programme unter Linux für lauschende Sockets standardmäßig MPTCP ein. In Go geschriebene Dienste bieten den demonstrierten Angriffsweg also womöglich an, ohne dass ihre Betreiber davon wissen.

Hotfix vorerst nur für drei Firmware-Stände

HF110626.1 gibt es laut Sophos für Sophos Firewall 23.0 GA, 23.0 EAP1 und 22.0 MR3. Wer eine andere Version betreibt, muss zuerst auf einen dieser Stände aktualisieren. Kurz nach dem Upgrade steht der Hotfix bereit, und die Firewall muss ein zweites Mal neu starten. Ist die Option „Allow automatic installation of hotfixes“ aktiv, lädt das Gerät den Hotfix selbst herunter. Im Control Center erscheint dann ein Hinweis, dass ein kritischer Hotfix gegen CVE-2026-98432 heruntergeladen wurde, der einen Neustart erfordert. Für die SD-RED-Geräte 20 und 60 hat Sophos die Lücke bereits am 5. November mit der Firmware 3.0.012 geschlossen, die als Pattern-Update über die Firewall verteilt wird.

Symbolbild: Netzwerkschrank mit Ethernet-Switches, Patchfeldern und einem Router

Bild: Symbolbild – Netzwerkschrank mit Switches und Patchfeldern. Foto: Dsimic, Lizenz CC BY-SA 4.0, via Wikimedia Commons

Einen Haken hat die Statusanzeige: Weil dieser Hotfix eine manuelle Aktion verlangt, taucht er in SFOS 23.0 auf der Seite „Hotfix: Security updates“ auch nach dem Neustart nicht auf. Sophos will das in den kommenden Wochen nachrüsten. Bis dahin lässt sich die Installation nur auf der Kommandozeile prüfen.

Was du jetzt tun solltest

  1. Version prüfen: In der Weboberfläche zeigt „Backup & firmware“ › „Firmware“ die aktive Version. Läuft dort nicht 22.0 MR3, 23.0 GA oder 23.0 EAP1, plane zuerst das Upgrade ein.
  2. Automatische Hotfixes einschalten: Ist die automatische Hotfix-Installation abgeschaltet, aktiviere sie in der Device Console (CLI, Menüpunkt 4) mit system hotfix enable und warte, bis der Hotfix heruntergeladen ist.
  3. Neustart einplanen: Der Neustart unterbricht den Datenverkehr, gehört also in ein Wartungsfenster – aufschieben solltest du ihn aber nicht.
  4. Hochverfügbarkeit beachten: In HA-Paaren zuerst das Auxiliary-Gerät neu starten und erst danach, sobald es wieder verfügbar ist, das Primary-Gerät. Die Statusabfrage per CLI funktioniert derzeit nur auf dem Primary-Gerät.
  5. Installation kontrollieren: In der Hotfix-Liste muss HF110626.1 mit dem Status „Installed“ stehen. Weitere Hotfixes in der Liste sind normal.
# Sophos Firewall: Device Console (CLI-Menü 4)
console> system hotfix enable
console> system hotfix list

Die Lücke betrifft nicht nur Sophos. Auch andere Linux-basierte Appliances und eigene Server, die TCP-Verbindungen aus nicht vertrauenswürdigen Netzen annehmen, brauchen einen korrigierten Kernel; Sophos rät ausdrücklich, Geräte von Drittherstellern mit einzubeziehen und internetexponierte Systeme zuerst anzugehen. Auf eigenen Linux-Systemen hilft ein Blick auf die laufende Kernel-Version und auf lauschende MPTCP-Sockets:

uname -r                  # Kernel-Version mit dem Security-Tracker der Distribution abgleichen
ss -Mln                   # lauschende MPTCP-Sockets anzeigen
sysctl net.mptcp.enabled  # 1 = MPTCP-Sockets erlaubt

MPTCP abzuschalten, etwa mit sysctl -w net.mptcp.enabled=0 oder für einzelne Go-Programme mit GODEBUG=multipathtcp=0, verkleinert nach Einschätzung von Sophos die Angriffsfläche für den demonstrierten Angriffsweg, behebt den Fehler aber nicht. Das Go-Team nennt das Abschalten pro Programm selbst eine fragile Maßnahme. Es taugt also nur als Übergang bis zum Kernel-Update samt Neustart.

Quellen

Bildnachweis