Contents (6 sections)
On 22 October, TianoCore published a security advisory for EDK II, the open-source code that most server and PC UEFI firmware is built on. The flaw, CVE-2026-97631, is rated 9.5 out of 10. It sits in the network boot driver, PXE. An attacker can get their code to run during boot, before the operating system and before Secure Boot. Six days later, no major vendor has shipped a fix for all its models. Here is what is at stake, who is really exposed, and what to do in the meantime.
A flaw at the very first moment #
When a server boots from the network, its firmware listens to the messages it receives, including ICMP error messages, the ones that say a host is unreachable. The EDK II PXE driver copies them into a 504-byte area. According to the advisory, it checks their size incorrectly, over IPv4 as well as IPv6: a longer message overflows that area and overwrites the memory next to it.
TianoCore describes two consequences. The simpler one: the boot hangs. The more serious one: an attacker who knows the exact firmware build of the target may get their own bytes executed in the phase where the firmware prepares the machine, with full privileges. They need no account and no password: sending an ICMP error message to the machine's IP address while it boots is enough, and the advisory states this can be done from any distance on the network.
The timing is what makes it serious. Secure Boot checks the operating system loader. The antivirus, the machine's firewall and its logs come later still. Here, everything happens before them. Code planted at this level can survive a complete reinstall of the system.
Disclosure ahead of the fixes #
The timeline explains why fixes are missing. A first change request citing the flaw appears publicly on the EDK II repository on 28 September. The fix is merged into the code on 15 October, and the advisory follows on the 22nd. According to Thomas-Krenn, disclosure was planned for early 2027 and should not have happened this soon.
A fix in EDK II protects no one directly. It must first go through the firmware vendors (AMI, Insyde, Phoenix), then through every motherboard and server maker, board by board, before arriving as a BIOS update. Supermicro has started publishing fixed versions for some X12 and X13 series. Microsoft merged the fix into Project Mu on 28 October. For most others, there is still a wait.
For virtual machines, things are slightly better. Fedora has had fixed packages in testing since 26 October, NixOS has merged the fix, Red Hat says it is working on it. At the time of writing, Debian and SUSE list the package as vulnerable, with no fix.
Who is really exposed #
The flaw only affects a machine that boots from the network, and only during that boot. A running server cannot be attacked this way. Nor can a server that boots straight from its disk without going through the network. Three situations still deserve attention.
The first is dedicated servers at a hosting provider. So that a rescue system can be started remotely, many dedicated servers try a network boot every time they power on, before the disk. Hetzner opened an incident on 28 October: for its dedicated servers, the risk exists at every reboot, and for its cloud machines, when booting the rescue system. Hetzner advises avoiding reboots until the fix is available, and blocking incoming ICMP in its network firewall during the ones that cannot wait.
The second is UEFI virtual machines. Under Proxmox, QEMU or KVM, a virtual machine's UEFI firmware is called OVMF, and OVMF is built on EDK II. A VM with its network card in its boot order can therefore go through the vulnerable driver: if the card comes before the disk, or if the disk fails to boot and the firmware falls back to the network. VMs on SeaBIOS, the other firmware Proxmox offers, are not affected by this flaw. The hypervisor itself is only exposed through its own firmware, like any physical server.
The third is fleets installed over the network: workstations and servers deployed by PXE, computer labs, machines that boot from the network by habit. There, the window opens at every boot.
What to do until the fix arrives #
Start by knowing which machines boot in UEFI mode. On Linux, the presence of the /sys/firmware/efi directory tells you. Then check, in the BIOS or the management console of each server, whether network boot is enabled and where it sits in the boot order. Where it serves no purpose, disable it. Where it is needed, put it after the disk.
On Proxmox, two lines of a VM's configuration answer the question: qm config <id> | grep -E '^(bios|boot):'. If the VM uses ovmf and its network card, net0 for example, is in the boot order, remove it when it is not needed, for instance with qm set <id> --boot order=scsi0. Keep the CD-ROM drive if you need it. The Proxmox firewall can also filter ICMP to the VMs that must keep a network boot.
Next, shrink the windows. Postpone reboots that are not urgent, and for those that cannot wait, block incoming ICMP upstream for the duration of the boot, then restore the rule. At Hetzner, remember to allow Hetzner services in the rule, otherwise the rescue system and the provider's monitoring stop working.
Finally, get ready for the fix. For physical servers, follow your vendor's bulletins (Dell, HPE, Lenovo, Supermicro…): the update will come through the BIOS, and Secure Boot will not spare you from it. For VMs, the fix will come through the hypervisor's OVMF firmware package, pve-edk2-firmware on Proxmox. Once that package is updated, a VM only loads the new firmware after a full shutdown followed by a start: a simple reboot from inside the VM is not enough.
What this flaw says about hosting #
This flaw is not fixed by an update command run one evening. It requires knowing how each machine boots, filtering upstream, choosing when to reboot, then following fixes that will arrive vendor by vendor over weeks. It is a matter of inventory and patience, not reflex.
For the servers we host and maintain, this work is part of handling the alert: boot order of servers and VMs checked, network boot removed where it serves no purpose, reboots scheduled behind upstream filtering, then firmware updated as soon as the vendors and Proxmox ship their fixes.
Are your servers or your Proxmox cluster managed elsewhere, or do you not know which of them boot from the network? We can review it with you: which machines are exposed, what to adjust right now, and how to roll out the fix when it comes.
Sources #
- TianoCore, advisory GHSA-99cj-7hg9-mp4m, Pre-boot RCE in EDK II PXE driver (22 October 2026): description, CVSS 4.0 score of 9.5, credits.
- EDK II, pull request 13200 (28 September 2026) and merged fix, pull request 13302 (15 October 2026).
- Hetzner, CVE-2026-97631 incident (opened on 28 October 2026): risk at reboot, firewall recommendations.
- Thomas-Krenn, Kritische PXE Boot Sicherheitslücke in EDK2 (updated on 30 October 2026, in German): early disclosure, fixed Supermicro BIOS versions.
- Red Hat, CVE-2026-97631 page.
- NixOS, fix merged.
- IT-Connect, Faille UEFI EDK II : un paquet ICMP pour exécuter du code avant Secure Boot (28 October 2026, in French).
