Linux-Kernel-TCP-Sicherheitslücke CVE-2026-98432: Proxmox-Kernel-Update, Debian und Ubuntu patchen

Kernel-Updates für Proxmox und Linux-Server nicht selbst planen müssen? WZ-IT prüft Kernelstände, spielt Updates ein und koordiniert Neustarts, siehe Managed Linux-Server-Betreuung, Managed Proxmox und CVE-Monitoring. Termin vereinbaren

Am 15. Oktober 2026 hat die Linux-Kernel-CNA die Sicherheitslücke CVE-2026-98432 veröffentlicht: ein Use-after-free im IPv4-TCP-Verbindungsaufbau, bewertet mit CVSS 3.1 9.8. Betroffen sind Kernel ab Version 4.4 ohne den Fix. Ein Forschungsbericht vom 27. Oktober beschreibt einen Exploit, der auf Servern mit MPTCP-Listener ohne Zugangsdaten Befehle als root ausführt. Exploit-Code, Kernel-Version und Testkonfiguration nennt der Bericht nicht.

Für Admins zählt zuerst der Patchstand. Proxmox VE enthält den Fix seit dem Kernel 7.0.14-25, Debian seit dem 16. Oktober, RHEL seit dem 1. November, AlmaLinux (Produktion) seit dem 2. und Rocky Linux seit dem 3. November. Bei Ubuntu liegt der Fix für 22.04, 24.04 und 26.04 seit dem 5. bzw. 6. November im Pocket -updates, aber noch nicht in -security. Dieser Beitrag fasst Lücke, Patchstand, Prüfbefehle, den Ablauf im Proxmox-Cluster und Übergangsmaßnahmen zusammen. Alle Angaben haben den Stand 9. November 2026. Den strategischen Rahmen zu Kernel-Updates beschreibt der Beitrag Linux-Kernel-Schwachstellen 2026: Patch-Management als Chefsache; hier geht es um diesen einen Fall.

Inhaltsverzeichnis

1. Die Lücke in Kürze
2. Wie die Lücke funktioniert
3. Ist MPTCP Voraussetzung für den Angriff?
4. Patchstand je Distribution (Stand 9. November 2026)
5. Betroffenheit prüfen: Befehle für Debian, Ubuntu, Proxmox und RHEL
6. Proxmox-Cluster aktualisieren: Knoten nacheinander
7. Was bis zum Reboot hilft und was nicht
8. Wird die Lücke ausgenutzt?
9. Unser Vorgehen bei WZ-IT
10. Weiterführende Guides

Die Lücke in Kürze

Quellen: CVE-Record, NVD, Red Hat, AlmaLinux, Akamai.

Die Bewertungen der Hersteller wichen anfangs ab. Laut einer Analyse von Phoenix Security veröffentlichte Red Hat zunächst 5.9, dann 8.1; heute führt Red Hat die Lücke selbst mit 9.8 und Schweregrad Critical. Nach unserer Einschätzung kann ein Scanner, der Patch-Fristen am Score eines einzelnen Herstellers festmacht, die Lücke deshalb zu niedrig einstufen.

Wie die Lücke funktioniert

Der Fehler steckt in der Übergabe von IP-Optionen zwischen zwei Kernel-Objekten (CVE-Beschreibung):

1. Ein Client sendet an einen offenen IPv4-TCP-Port ein SYN-Paket mit IP-Optionen. Laut Szenario der CNA sind das Record Route oder Timestamp. Der Kernel speichert die Optionen am Request-Socket (ireq_opt).
2. Mit dem Abschluss des Handshakes übergibt tcp_v4_syn_recv_sock() diese Optionen ohne Kopie an das Kind-Socket (inet_opt).
3. Eine zweite CPU verarbeitet parallel ein erneut gesendetes SYN und baut daraus ein SYN-ACK, das dieselben Optionen liest.
4. Wird das Kind-Socket in diesem Moment freigegeben, löscht inet_sock_destruct() die Optionen mit einem einfachen kfree(). ip_options_build() liest dann freigegebenen Speicher.

Ein zweiter Pfad entsteht bei der Migration von Request-Sockets, also mit net.ipv4.tcp_migrate_req=1 oder einem BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE. Der Standardwert von tcp_migrate_req ist 0 (Kernel-Dokumentation); ein geladenes BPF-Migrationsprogramm ist am Sysctl nicht erkennbar. Der Fix gibt die Optionen erst nach einer RCU-Schonfrist frei (kfree_rcu() in inet_sock_destruct() und tcp_v4_reqsk_destructor()).

Als Folgen nennt die CNA ein Informationsleck (zusätzliche Heap-Bytes im SYN-ACK), Schreibzugriffe außerhalb der Grenzen und einen Absturz über skb_under_panic(). Der im Forschungsbericht beschriebene Exploit nutzt das in zwei Stufen: Zuerst wird die Kernel-Adresslayout-Randomisierung (KASLR) über einen geleakten Kernel-Zeiger ausgehebelt, danach ein Callback-Zeiger überschrieben, sodass der Kernel einen Shell-Befehl als root ausführt. Laut Bericht lässt ein verlorener Wettlauf bei diesem Exploit nur den einzelnen Handshake scheitern, der Angreifer kann also wiederholen. Im einen beschriebenen Nachweis dauerte der Leak 48 Minuten, die Befehlsausführung weitere fünf Minuten; das sind keine allgemeinen Angriffszeiten. Exploit-Code, Kernel-Version und Konfiguration des Tests nennt der Bericht nicht.

Ist MPTCP Voraussetzung für den Angriff?

Für den bisher beschriebenen Exploit ja, für die Lücke nein. Red Hat hält fest, dass MPTCP keine Voraussetzung ist: Die nötige Eingabe sind IPv4-Optionen an einer eingehenden Verbindungsanfrage in Verbindung mit einem der beiden Wettläufe. Canonical, das Go Security Team und ein Proxmox-Mitarbeiter sagen dasselbe. Als Weg zum betroffenen Code nennt PSA-2026-00080-1 neben SYN-Paketen mit IPv4-Optionen auch CIPSO/NetLabel-Konfigurationen.

Ob MPTCP-Sockets auf einem System überhaupt möglich sind, hängt vom Kernel ab:

Der Standardwert 1 stammt aus der Kernel-Dokumentation zu MPTCP; vor Ort entscheidet sysctl net.mptcp.enabled. Ein MPTCP-Listener entsteht trotzdem nur, wenn ein Programm ihn beim Anlegen des Sockets anfordert (MPTCP-Projekt). Go-Programme tun das seit Go 1.24 für Listener standardmäßig, sofern nichts anderes eingestellt ist (etwa GODEBUG=multipathtcp=0). ss -Mlnp listet vorhandene MPTCP-Listener samt Prozess; es listet nicht alle Go-Dienste und sagt nichts über deren Go-Version (siehe unten).

Ein leeres Ergebnis ist keine Entwarnung und nur eine Momentaufnahme des geprüften Netzwerk-Namespace: Red Hat schreibt, ein Fehlen von MPTCP-Listenern sei als Information zu behandeln, nicht als Beruhigung. Der Patch bleibt auch ohne MPTCP nötig.

Patchstand je Distribution (Stand 9. November 2026)

Proxmox VE, Proxmox Backup Server und Mail Gateway

Die Quellen für 7.0.14-25 wurden am 17. Oktober 2026 auf den Ubuntu-Stand 7.0.0-43.43 gehoben (Changelog-Eintrag Ubuntu-7.0.0-43.43i1, Commit). Ein Proxmox-Mitarbeiter bestätigte am 30. Oktober, dass der Fix-Commit aus der CVE-Ankündigung in 7.0.14-25 und -26 enthalten ist und beide Versionen im Enterprise-Repository liegen. Der Paketindex des No-Subscription-Repositorys von Proxmox VE (Trixie) trägt das Änderungsdatum 6. November und enthält Builds bis 7.0.14-28. In den No-Subscription-Paketindizes von Proxmox Backup Server und Mail Gateway stehen am 9. November 7.0.14-25 und -26 (eigene Prüfung der Indizes). Proxmox VE 8 ist laut Proxmox-FAQ seit August 2026 ausgelaufen und hat keinen Fix-Kernel; dort ist das Upgrade auf Proxmox VE 9 mit Kernel 7.0 nötig. Auf einem bereits vorhandenen Proxmox VE 9 mit älterem Kernel (6.17, 6.14) genügt grundsätzlich der Wechsel auf einen Fixkernel der Serie 7.0, ein weiteres Major-Upgrade entfällt.

Debian

Der Tracker führt für trixie-security aktuell 6.12.116-1; in der Reihe 6.12 der offiziellen Debian-Pakete enthält jede Version ab 6.12.113-1 den Fix.

Ubuntu

Quellen: Ubuntu-CVE-Seite (zuletzt aktualisiert am 9. November 2026), Canonical-Blog vom 2. November und das Archiv (veröffentlichte Quellpakete von 22.04, 24.04 und 26.04). Die Changelogs dieser Pakete enthalten den Fix "ipv4: free inet_opt and ireq_opt after an RCU grace period" (eigene Prüfung am 9. November 2026). Laut Veröffentlichungsverlauf von Launchpad (UTC) erschien 22.04 am 5. November um 23:22 Uhr in -updates, 24.04 und 26.04 am 6. November um 01:14 Uhr. In -security standen am 9. November noch 5.15.0-202.212, 6.8.0-147.147 und 7.0.0-42.42.

Drei Punkte zu Ubuntu:

• Die CVE-Seite hinkt hinterher. Sie führt die LTS-Releases am 9. November noch als "pending", obwohl die Kernel bereits in -updates liegen. Der Tracker listet bisher keine Ubuntu Security Notice zu dieser CVE.
• Hosts, die nur aus -security aktualisieren, bekommen den Kernel nicht automatisch. Die Standardvorlage von unattended-upgrades bezieht aus <codename>, <codename>-security und den ESM-Ursprüngen (soweit vorhanden); -updates ist auskommentiert. Eine solche Konfiguration installiert den Kernel erst nach Freigabe in -security. Bis dahin ist ein manueller Lauf von apt full-upgrade möglich (setzt -updates in den APT-Quellen voraus) oder die Aufnahme von -updates in Allowed-Origins; lokale Konfigurationen, Pins und Holds können abweichen.
• HWE-, Cloud- und ältere LTS-Kernel haben eigene Stände. Laut Tracker ist für linux-hwe-6.17 (24.04) noch nichts vorgesehen, linux-hwe-7.0 (24.04) und linux-hwe-6.8 (22.04) sind "pending". Kernel wie linux-aws, linux-azure oder linux-gcp sind eigene Pakete und je Release im Tracker zu prüfen. Für Ubuntu 14.04 gilt "nicht betroffen" nur für das Paket linux; linux-lts-xenial, linux-aws und linux-azure führt der Tracker dort als verwundbar.

RHEL, AlmaLinux und Rocky Linux

RHEL 6 und 7 führt Red Hat in den Red-Hat-Sicherheitsdaten zur CVE als nicht betroffen. Für weitere Produktzweige mit eigenen Kernelständen hat Red Hat zusätzliche Errata veröffentlicht (2. bis 4. November), etwa für Extended Update Support (EUS), Advanced Mission Critical Update Support (AUS), Telecommunications Update Service (TUS) und Update Services for SAP Solutions (E4S); die vollständige Liste steht in denselben Sicherheitsdaten.

Betroffenheit prüfen: Befehle für Debian, Ubuntu, Proxmox und RHEL

Debian und Ubuntu

# laufender Kernel
uname -r
# Debian-Kernel: die Versionszeile enthält die Paketversion (z. B. "Debian 6.1.190-1"); verbindlich ist die Paketliste von dpkg
uname -v
# installierte Kernelpakete
dpkg -l 'linux-image*' | grep ^ii
# Update einspielen, zieht neue Kernelpakete nach
sudo apt update && sudo apt full-upgrade
# zeigt, ob der laufende Kernel hinter dem installierten zurückliegt (Paket needrestart)
sudo needrestart -k

Ubuntu zeigt die Kernelversion als ABI-Nummer: 6.8.0-149-generic entspricht 6.8.0-149.149. Gefixt sind 22.04 ab 5.15.0-203, 24.04 ab 6.8.0-149 und 26.04 ab 7.0.0-43. Ubuntu beschreibt im Blog uname -r und dpkg -l 'linux-image*' | grep ^ii als Prüfweg. Für Debian gelten die Versionen der Tabelle oben.

Proxmox VE und Proxmox Backup Server

# zeigt u. a. "running kernel: 7.0.14-25-pve"
pveversion
uname -r
# Pins und installierte Kernel
proxmox-boot-tool kernel list
# Paketstand auf Backup Server
proxmox-backup-manager versions --verbose
sudo apt update && sudo apt full-upgrade

Gefixt ist 7.0.14-25-pve oder neuer. Ein gesetzter Pin (proxmox-boot-tool kernel pin) hält den Host nach dem Update auf dem alten Kernel; proxmox-boot-tool kernel unpin hebt ihn auf. Bei Systemen, die ihre Boot-Partitionen (ESP) mit proxmox-boot-tool synchronisieren, folgt danach proxmox-boot-tool refresh (Proxmox-Dokumentation). Ohne ein eingerichtetes Repository mit den aktuellen Proxmox-Kernelpaketen (Enterprise oder No-Subscription; ein Forumsnutzer nennt auch das Test-Repository) liefert apt den Fixkernel nicht; ein Forumsbeitrag beschreibt diesen Fall bei einer frisch installierten Version 9.2, gelöst durch das No-Subscription-Repository.

RHEL, AlmaLinux, Rocky Linux

uname -r
rpm -q kernel
sudo dnf clean metadata && sudo dnf upgrade
# Rückgabewert 1 = Neustart nötig; benötigt das Paket dnf-plugins-core
sudo dnf needs-restarting -r

MPTCP, Migration und Erreichbarkeit (alle Systeme)

sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
# MPTCP-Listener mit Prozess
ss -Mlnp
# alle IPv4-Listener, die aus Netzen erreichbar sein könnten
ss -4 -ltnp

Ältere iproute2-Versionen lehnen die Option -M ab (TuxCare). ss -Mlnp listet MPTCP-Listener mit Prozess und beantwortet nur, ob der bisher beschriebene Exploit-Weg offen ist, nicht, ob der Kernel verwundbar ist; es zeigt weder alle Go-Dienste noch deren Go-Version. Die Ausgabe gilt für den Netzwerk-Namespace, in dem der Befehl läuft (net.mptcp.enabled gilt pro Namespace); Container mit eigenem Namespace sind getrennt zu prüfen. sysctl net.ipv4.tcp_migrate_req zeigt nur den Sysctl, ein geladenes BPF-Programm vom Typ BPF_SK_REUSEPORT_SELECT_OR_MIGRATE zeigt es nicht. Akamai stellt zusätzlich ein Prüfskript unter MIT-Lizenz bereit, dessen Standardmodus nur liest; wie bei jedem fremden Skript gilt: vor dem Einsatz den Code lesen.

Proxmox-Cluster aktualisieren: Knoten nacheinander

Pro Knoten genügt ein Neustart, sofern der Fixkernel installiert ist und startet und das Quorum erhalten bleibt. Der Ablauf pro Knoten:

1. Vorher prüfen. Aktuelles Backup, Quorum (pvecm status), bei Ceph der Zustand (ceph -s), Repositories und Pins (proxmox-boot-tool kernel list).
2. Gäste verlagern. Für HA-Dienste den Wartungsmodus setzen: ha-manager crm-command node-maintenance enable pve1. Der Knoten wird für HA als nicht verfügbar markiert, und die Dienste ziehen je nach HA-Regeln und verfügbaren Zielknoten auf andere Knoten um (Proxmox-Dokumentation zu HA). Der Status maintenance erscheint, sobald der Befehl aufgenommen wurde, also vor Abschluss aller Umzüge; vor dem Neustart warten, bis keine HA-Dienste mehr auf dem Knoten laufen (ha-manager status) und im Log watchdog closed (disabled) steht. Laufende VMs ohne HA wandern mit qm migrate <vmid> pve2 --online, sofern keine lokal gebundenen Geräte wie Passthrough konfiguriert sind, der Zielknoten im selben Cluster liegt, per Netzwerk zuverlässig erreichbar ist, dieselben oder neuere Proxmox-Pakete hat und eine kompatible CPU besitzt (Proxmox-Dokumentation zu VMs). Laufende LXC-Container lassen sich nicht live migrieren; pct migrate <ctid> pve2 --restart stoppt den Container, verschiebt ihn und startet ihn auf dem Zielknoten (Proxmox-Dokumentation zu Containern).
3. Aktualisieren und neu starten. Sobald keine HA-Dienste und Gäste mehr auf dem Knoten laufen: sudo apt update && sudo apt full-upgrade, danach reboot.
4. Kernel kontrollieren. uname -r zeigt 7.0.14-25-pve oder neuer, pveversion nennt den laufenden Kernel.
5. Wartungsmodus beenden. ha-manager crm-command node-maintenance disable pve1. Die Dokumentation weist darauf hin, dass der Modus beim Neustart nicht automatisch endet; erst danach ziehen die Dienste zurück.
6. Erst dann den nächsten Knoten. Quorum bestätigen und bei Ceph auf einen gesunden Zustand warten.

Danach bleiben die Gäste:

• VMs haben einen eigenen Kernel. Linux-Gäste mit einem betroffenen Kernel werden wie die Debian-, Ubuntu- oder RHEL-Systeme oben aktualisiert, unabhängig vom Host. Im Forum schreibt ein Proxmox-Mitarbeiter auf die Frage, ob gepatchte Gäste genügen, der Fix auf dem Host sei ausdrücklich empfohlen.
• LXC-Container nutzen den Kernel des Hosts. Sie sind geschützt, sobald der Host auf einem gefixten Kernel läuft; die Proxmox-Dokumentation hält fest, dass Container den Kernel des Hosts direkt verwenden.
• Proxmox Backup Server läuft auf denselben Kernelpaketen und gehört in den Plan. Neustart erst, wenn keine Sicherung oder Wiederherstellung läuft.

Was bis zum Reboot hilft und was nicht

Als einzige vollständige Lösung nennt Red Hat das Einspielen der Kernel-Sicherheitsupdates, AWS für EC2 Kernel-Update und Neustart. Bis zum Neustart gilt:

Die Regel aus dem Red-Hat-Bulletin, die auch die Ubuntu-CVE-Seite führt, lautet:

sudo tee /etc/cve-2026-98432.nft >/dev/null <<'EOF'
table inet cve_2026_98432 {
  chain input {
    type filter hook input priority -310; policy accept;
    ip protocol tcp ip hdrlength > 5 counter drop
  }
}
EOF
sudo nft -c -f /etc/cve-2026-98432.nft && sudo nft -f /etc/cve-2026-98432.nft
sudo nft list table inet cve_2026_98432
# entfernen, sobald der gefixte Kernel läuft
sudo nft delete table inet cve_2026_98432

ip hdrlength > 5 trifft jeden IPv4-Header, der länger als 20 Bytes ist, also jedes Paket mit IP-Optionen. Die Regel vorher in einer Testumgebung ausprobieren, so verlangt es auch Red Hat. Für Container mit eigenem Netzwerk-Namespace gilt die Regel des Hosts nicht; die Ubuntu-CVE-Seite weist darauf hin, dass sie dort separat gesetzt werden muss. VMs brauchen ohnehin den Kernel-Fix im Gast. Die vollständige Anleitung mit Persistenz steht in der Mitigation-Sektion der Ubuntu-CVE-Seite.

Live-Patching: Ein passender, installierter und aktiver Live-Patch des Herstellers kann den Neustart ersetzen; AWS erwähnt das für Ubuntu-WorkSpaces. In den geprüften Quellen von Canonical, Debian und Proxmox steht keine Aussage zu einem Live-Patch für diese CVE. TuxCare nennt in seinem Beitrag einen KernelCare-Patch für Debian 13; das ist eine Herstellerangabe, die vor dem Einsatz am eigenen Kernel zu prüfen ist.

Wird die Lücke ausgenutzt?

Stand 9. November 2026 ist in den geprüften Quellen keine Ausnutzung bestätigt:

• Die CVE steht nicht im KEV-Katalog der CISA (Katalogversion 2026.11.06, geprüft am 9. November 2026).
• AWS schreibt im Bulletin 2026-160-AWS (aktualisiert am 6. November), es gebe keine Hinweise auf Ausnutzung.
• Akamai kennt Stand 2. November keinen öffentlichen, funktionierenden Exploit.
• Der im Forschungsbericht beschriebene Exploit ist nicht veröffentlicht. Das Kernel-Team von CloudLinux konnte die Remote-Root-Behauptung (Stand 3. November) nicht reproduzieren.
• Auf GitHub liegt ein Nachweis-Programm eines Dritten, das nach eigener Beschreibung den Wettlauf auslöst und Speicherinhalte im SYN-ACK nachweist, aber keine Befehle ausführt (die Beschreibung des Autors, nicht von uns geprüft). Code aus fremden Exploit-Repositories gehört vor jeder Ausführung gelesen und nur in einer isolierten Testumgebung ausgeführt.
• Berichte über Scans nach MPTCP-Listenern liegen vor (ThreatDefence), stammen aber von Dritten und sind nicht unabhängig bestätigt.

Google nennt im GKE-Bulletin GCP-2026-078 vom 4. November außerdem einen lokalen Auslösepfad: Ein unprivilegierter Prozess in einem Container könne die Lücke ohne besondere Fähigkeiten auslösen, bis hin zu Root auf dem Node. In den geprüften Herstellerquellen findet sich dazu bisher keine Bestätigung. Nach unserer Einschätzung ist das für Hosts, auf denen Container mit fremdem Code laufen, ein Grund, sie vor reinen Management-Hosts zu patchen.

Unsere Einschätzung zur Reihenfolge nach Exposition (keine Herstellervorgabe): zuerst Hosts mit IPv4-TCP-Diensten aus dem Internet, dann Hosts mit MPTCP-Listenern (darunter Go-Dienste ab Go 1.24) und Hosts mit Containern fremder Mandanten, danach interne Systeme.

Unser Vorgehen bei WZ-IT

WZ-IT betreut Linux-Server mit der Managed Linux-Server-Betreuung (ab 149,90 € netto pro Monat für den ersten Server) und Proxmox-Umgebungen mit Managed Proxmox. Bei einer Kernel-Lücke wie CVE-2026-98432 gliedert sich das Vorgehen in fünf Schritte:

1. Betroffenheit feststellen. Laufender Kernel, Repositories, Pins und MPTCP-Listener aller Hosts erfassen, Gäste und Container einzeln.
2. Nach Exposition ordnen. Hosts mit Zugang aus dem Internet oder fremden Netzen zuerst, Container-Hosts mit mehreren Mandanten vor Management-Systemen.
3. Übergang absichern, falls nötig. Erreichbarkeit begrenzen und die Filterregel der Hersteller dokumentiert einsetzen, mit Rückbau nach dem Update.
4. Patchen. Proxmox-Knoten nacheinander mit Migration und Neustart, danach den laufenden Kernel kontrollieren; Gäste im vereinbarten Wartungsfenster.
5. Dauerhaft überwachen. Das CVE-Monitoring gleicht die NVD, Hersteller-Advisories, die Security-Tracker von Debian und Ubuntu sowie CERT-Bund ab, prüft Betroffenheit, priorisiert nach Risiko und steuert Patches dokumentiert. Ein Server-Audit erfasst vorab den Bestand und die offenen Kernelstände.

Zur Einordnung der Wartung selbst: Proxmox-Wartung und Proxmox-Absicherung beschreiben, was zum laufenden Betrieb einer Proxmox-Umgebung gehört.

Weiterführende Guides

• Linux-Kernel-Schwachstellen 2026: Patch-Management als Chefsache, der strategische Rahmen zu Kernel-Updates und Verantwortung.
• pedit COW und DirtyClone: zwei Linux-Kernel-Lücken 2026, lokale Rechteausweitung und Container-Eskalation.
• CVE-Monitoring für Self-Hosted Software, wie Schwachstellen strukturiert verfolgt werden.
• Proxmox-Expertise von WZ-IT, der Überblick über Beratung, Betrieb und Wartung.
• Proxmox-Wartung, Updates, Kernel und Betrieb von Proxmox-Umgebungen.
• Proxmox-Absicherung, Härtung, Patching und Zugriffsschutz für Proxmox.
• Managed Linux-Server-Betreuung, laufender Serverbetrieb mit Patching und Monitoring.
• CVE-Monitoring, Schwachstellen verfolgen, bewerten und Patches steuern.
• Server-Audit, Bestand, Angriffsfläche und priorisierte Maßnahmen.
• SSHole (CVE-2026-123158): OpenSSH bei Alpine prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• APT-Lücke CVE-2026-109518 in Debian und Ubuntu - weiterer aktueller Sicherheitsfall (Stand November 2026)
• CWPdoor: Hintertür im Control Web Panel prüfen - weiterer aktueller Sicherheitsfall (Stand November 2026)
• Node-RED-Editor ohne adminAuth: CVE-2026-58115 (Siemens IoT2050) - weiterer aktueller Sicherheitsfall (Stand November 2026)

Kernelstand der Server und Proxmox-Knoten prüfen lassen? Wir erfassen Kernelversionen, Repositories und Reboot-Bedarf und planen die Updates für Hosts, Gäste und Container, siehe Managed Linux-Server-Betreuung. Termin vereinbaren

Quellen

• CVE-Record CVE-2026-98432, cve.org
• NVD: CVE-2026-98432
• Linux-Kernel: Fix-Commit e3f33b0a1d89 (ipv4: free inet_opt and ireq_opt after an RCU grace period)
• Linux-Kernel-CNA: CVE-Ankündigung CVE-2026-98432
• Kernel-Dokumentation: MPTCP-Sysctls
• Kernel-Dokumentation: IP-Sysctls (tcp_migrate_req)
• MPTCP-Projekt: Setup
• Anthropic: Discovering and exploiting vulnerabilities in critical, real-world software with Claude (27. Oktober 2026)
• Akamai: CVE-2026-98432, A Remote Use-After-Free in the Linux Kernel's TCP Stack (2. November 2026)
• Akamai: Prüf- und Mitigationsskript auf GitHub
• Go Security Team: Protecting against CVE-2026-98432 when using Go programs (oss-security)
• Go 1.24 Release Notes
• oss-security: Antwort von CIQ zu init_on_free=1
• Red Hat: CVE-2026-98432
• Red Hat: Security Bulletin RHSB-2026-016
• Red Hat: Sicherheitsdaten zu CVE-2026-98432 (Errata je Produkt)
• Red Hat: RHSA-2026:93414 (RHEL 8)
• Red Hat: RHSA-2026:93412 (RHEL 9)
• Red Hat: RHSA-2026:93413 (RHEL 10)
• AlmaLinux: CVE-2026-98432, Patched kernels released
• Rocky Linux: RLSA-2026:93414
• Debian Security Tracker: CVE-2026-98432
• Debian: DSA-6568-1
• Debian: DLA-4841-1
• Debian: DLA-4850-1
• Ubuntu: CVE-2026-98432
• Canonical: Fixes available in -proposed pocket for CVE-2026-98432
• Ubuntu-Archiv: linux 6.8.0-149.149 (24.04)
• Canonical: Kernel-Konfiguration (annotations), Branch jammy
• Canonical: Kernel-Konfiguration (annotations), Branch noble
• Canonical: Kernel-Konfiguration (annotations), Branch resolute
• unattended-upgrades: Standardkonfiguration für Ubuntu
• Proxmox: PSA-2026-00080-1
• Proxmox-Forum: CVE-2026-98432 in Proxmox VE
• pve-kernel: Commit 7.0.14-25
• pve-kernel: Branches
• Proxmox-Forum: Kernel is not updated
• Proxmox VE: FAQ mit Support-Zeiträumen
• Proxmox VE: High Availability und Wartungsmodus
• Proxmox VE: Linux-Container
• Proxmox VE: Virtuelle Maschinen und Live-Migration
• Proxmox: Paketindex pve-no-subscription (Trixie)
• Proxmox: Paketindex pbs-no-subscription (Trixie)
• Proxmox: Paketindex pmg-no-subscription (Trixie)
• Proxmox VE: Host-Administration, Bootloader und Kernel-Pinning
• AWS: Bulletin 2026-160-AWS
• Google Cloud: Sicherheitsbulletin GCP-2026-078
• CISA: Known Exploited Vulnerabilities Catalog
• CloudLinux: CVE-2026-98432, Status for CloudLinux
• MikroTik: CVE-2026-98432
• TuxCare: CVE-2026-98432 und KernelCare
• ThreatDefence: Mitigation, Hunting, Patching
• Phoenix Security: Bewertungen von 5.9 bis 9.8