Veeam Appliance: kernel panic on AMD EPYC

Veeam has warned that its Software Appliance can die on boot when the virtual machine sits on a host with an AMD EPYC processor. BleepingComputer reported the advisory on November 6, 2026. The appliance is a Linux virtual machine shipped ready to run Backup & Replication, so a team does not build that stack by hand. On the affected hosts, a reboot can end in a kernel panic, and the VM never finishes coming up. One of the reboots that hits it is the reboot after an update installs a new kernel.

The kernel inside the appliance runs a jitterentropy health test in FIPS mode while boot is still early. That check is part of how the appliance meets corporate and government cryptographic rules. On some EPYC processors the test fails, and the kernel stops. Veeam has named the AMD EPYC 7262, 7302, and 7F72, and it describes the failure as hitting certain EPYC processors, those models among them. The panic line operators are seeing is:

Kernel panic - not syncing: jitterentropy: Initialization failed with host not compliant with requirements: 9

The fault sits in the kernel build the appliance uses. It applies to Software Appliance 13.1 and later. Veeam says that after a successful boot, Backup & Replication itself is operating normally. The outage is the boot. A backup server that never finishes boot is a backup server that missed its window.

What to do with the VM

Veeam’s first mitigation is to place the appliance on a host with a different processor. Where that move cannot happen this week, turn automatic updates off and apply them by hand, with someone watching the reboot. An unattended kernel update is how this panic arrives in the middle of a maintenance window.

If the panic is already on the console, power the virtual machine off and then power it on. Veeam says a restart issued from inside the guest does not recover the machine. A boot that completes should be the end of this error, on the company’s account, and Backup & Replication should run as usual from there. Check the jobs that were due across the failed reboot anyway. A clean console after the second power-on does not recreate a restore point that never ran.

Treat every Software Appliance on an EPYC host as in scope until the CPU model is read from the hypervisor. The three part numbers are cases Veeam has already recorded. They are a floor for the search, and other EPYC models stay on the list until the host is identified.

Keep the other kernel update on its own line

The same week, Veeam said some of its products are affected by CVE-2026-98432, a separate critical flaw in the Linux kernel, and that it is sending a patched kernel to affected components as a private fix or through the Veeam Updater. Take that update on the systems Veeam lists. File it as its own change. A VM that boots cleanly has cleared the EPYC panic for that reboot. It has not, by that fact, installed the CVE-2026-98432 kernel.

Veeam says the products are in use at more than 550,000 customers, including most of the Global 2000 and the Fortune 500. On this appliance the public impact is availability: restores wait on a VM that panicked before the backup service started. Move the EPYC guests, or have a person on the next reboot.

This briefing relies on public reporting by BleepingComputer and on Veeam’s advisory. It does not include exploit procedures.