Veeam-Appliance: Kernel-Fix gegen CVE-2026-98432, Bootfehler auf AMD EPYC
Veeam liefert den Fix für die Linux-Kernel-Lücke CVE-2026-98432 seit dem 2. November 2026 für Software Appliance und Infrastructure Appliance 13.1 aus. Für Veeam Backup & Replication 13.1 unter Windows gibt es einen Private Fix, für 12.3 soll er bald folgen. Parallel warnt Veeam vor Kernel Panics der Software Appliance unter anderem auf AMD EPYC 7262, 7302 und 7F72, auch nach Kernel-Updates.
Veeam hat am 6. November 2026 beschrieben, welche seiner Produkte von der Linux-Kernel-Lücke CVE-2026-98432 betroffen sind und wie der korrigierte Kernel sie erreicht. Für die Veeam Software Appliance und die Veeam Infrastructure Appliance 13.1 liegt das Update seit dem 2. November im Veeam-Repository. Zwei Tage zuvor, am 4. November, hatte Veeam ein Bootproblem der Software Appliance auf Hosts mit AMD-EPYC-Prozessoren dokumentiert, das sporadisch bei Neustarts auftritt, auch nach einem Update mit neuem Kernel.
Betroffen sind Veeam-Komponenten, die einen eigenen Linux-Kernel mitbringen: die Appliances, Hilfs-Appliances von Veeam Backup & Replication, Worker der Hypervisor-Plug-ins und Recovery-Medien. Veeam Kasten for Kubernetes ist nicht betroffen, für selbst verwaltete Linux-Server verweist Veeam auf die Hinweise der Distribution. Wer die Appliance auf AMD EPYC betreibt, sollte das Update nicht unbeaufsichtigt laufen lassen.
Was ist passiert?
CVE-2026-98432 ist laut Veeam ein Use-after-free im TCP/IPv4-Verbindungsaufbau des Linux-Kernels mit CVSS 9.8, der zu Dienstausfall oder Speicherbeschädigung führen kann. S-EDV hat über die Kernel-Lücke Ende Oktober berichtet. Für die Appliances 13.1 liefert Veeam den Kernel 5.14.0-570.60.1+27.2.el9_6_ciq über den Veeam Updater. Für Veeam Backup & Replication 13.1 unter Windows gibt es für die Linux-basierten Hilfs-Appliances einen Private Fix, für Version 12.3 soll er bald folgen.
Das Bootproblem beschreibt Veeam so: Der Kernel der Software Appliance führt im FIPS-Modus beim frühen Start einen Gesundheitstest für jitterentropy aus. Auf bestimmten AMD-EPYC-Prozessoren, darunter EPYC 7262, 7302 und 7F72, schlägt dieser Test sporadisch fehl, der Start bricht mit einer Kernel Panic ab. Für die verwendete Kernel-Version gibt es derzeit keinen Fix.
Wer ist betroffen?
Von der Kernel-Lücke sind nach Veeams Tabelle unter anderem die Software Appliance 13.1, die Infrastructure Appliance 13.1 in Rollen wie Proxy, gehärtetes Repository oder WAN-Beschleuniger, Cloud-Connect-Gateways, die Appliances der Plug-ins für AWS, Azure und Google Cloud sowie Recovery-Medien für Veeam Agent for Linux betroffen, die vor dem Update erstellt wurden. Das Bootproblem betrifft die Software Appliance ab Version 13.1 auf Hosts mit bestimmten AMD-EPYC-Prozessoren, darunter EPYC 7262, 7302 und 7F72.
Wie kritisch ist das?
Die Lücke selbst ist schwerwiegend, betrifft aber den Netzwerkstack und nicht Veeam-Code. Heikel ist das Zusammenspiel: Mit der Standardeinstellung prüft der Veeam Updater alle zwölf Stunden und installiert Pflicht-Updates automatisch am nächsten Sonntag um 14 Uhr in der Zeitzone des Backup-Servers. Ein Neustart kann nötig sein. Auf betroffenen EPYC-Hosts bleibt die Appliance nach so einem Neustart laut Veeam unter Umständen hängen, bis jemand die VM manuell aus- und wieder einschaltet, ein Neustart des Gastsystems reicht nicht. Nach einem erfolgreichen Start sind laut Veeam keine weiteren Fehler zu erwarten, der Betrieb von Veeam Backup & Replication ist nicht beeinträchtigt.
Was sollten Admins jetzt tun?
- Inventar: alle Veeam-Appliances, Proxys, Repositories und Hilfs-Appliances mit Version erfassen, dazu den Prozessor des Hosts.
- Patchstand prüfen: in der Veeam Host Management Console des Backup-Servers unter „Updates“ nach Updates suchen und im Reiter „History“ nachsehen, ob der Kernel schon installiert ist. Komponenten mit eigener Update-Konfiguration einzeln prüfen, bei einem lokalen Mirror kommt das Update erst nach dessen Synchronisierung.
- Auf AMD EPYC: automatische Updates abschalten, das Update manuell einspielen und den Neustart beobachten. Die Meldung mit „jitterentropy: Initialization failed“ ist je nach Hypervisor nur über die serielle Konsole oder im Ereignisprotokoll des Hypervisors sichtbar. Erscheint sie, die VM aus- und wieder einschalten.
- Als Lösung nennt Veeam, die Appliance auf einem Host mit anderem Prozessor neu bereitzustellen.
- Virtuelle Labs und Hilfs-Appliances in Azure neu bereitstellen, Recovery-Medien für Veeam Agent for Linux nach dem Update neu erstellen, für die Agent-Version aus Veeam Backup & Replication 12.3 erst mit dem angekündigten Private Fix.
- Unter Windows mit Veeam Backup & Replication 13.1 den Private Fix einspielen (Voraussetzung ist Build 13.1.2.57, neue Installationen nutzen das neu gepackte ISO von 13.1.2), bei 12.3 die Veröffentlichung im Blick behalten.
Einordnung für Unternehmen
Automatische Updates sind für Backup-Appliances grundsätzlich sinnvoll, weil sie oft vergessen werden. Der Fall zeigt die Kehrseite: Bleibt die Appliance nach dem Sonntagsupdate im Bootvorgang hängen, fällt das womöglich erst auf, wenn die nächste Sicherung fehlt. Monitoring für Backup-Jobs und eine Benachrichtigung bei fehlgeschlagenen Läufen sind deshalb Pflicht. Wer die Appliance auf den genannten EPYC-Modellen betreibt, sollte den nächsten Neustart als geplante Wartung behandeln.
Passende Anleitungen auf S-EDV
- Veeam Backup & Replication: Grundlagen und erster Backup-Job
- Veeam Backup & Replication 13.1.2 schließt kritische CDP-Lücke
