bk99.de entertain the web since 1997

bk99.de
TianoCore · SecurityCurated

PXE boot as an entry point: buffer overflow in EDK II hits server firmware before Secure Boot

Summary

In security advisory GHSA-99cj-7hg9-mp4m, the TianoCore project describes a buffer overflow in the PXE driver of EDK II, found by Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google). A crafted ICMP error message during network boot can execute code in the firmware before Secure Boot or measured boot have verified anything. Because a public pull request broke the embargo months early, the fix is available in the source code, while it is unclear when vendors will ship firmware updates.

What goes wrong in the driver

EDK II is the open source reference implementation of UEFI. Firmware vendors such as AMI, Insyde and Phoenix build their firmware on it, as do Microsoft's fork Project Mu and the OVMF firmware for virtual machines. The affected driver, NetworkPkg/UefiPxeBcDxe, handles network boot via PXE over IPv4 and IPv6.

While a machine boots via PXE, the driver keeps a receive request open for ICMP error messages and copies each message it receives into the field Mode.IcmpError, which is exactly 504 bytes long. The copy loop in both handlers (PxeBcIcmpErrorDpcHandle for IPv4, PxeBcIcmp6ErrorDpcHandle for IPv6) checks the bounds incorrectly: a longer message is copied anyway, and the destination pointer advances by the cumulative length instead of the length of the individual fragment. As a result, attacker-controlled bytes end up past the field. Nothing earlier on the receive path limits the message length.

The fix checks the bounds, calculates the offsets correctly, truncates oversized messages and clears the buffer before every copy. It also adds unit tests that fail before the change and pass after it.

What an attacker can achieve

According to the advisory, there are two levels. A crash is reliably achievable: the next ICMP error message corrupts the driver's data, a CPU exception in the DXE core hangs the boot, and the machine can be neither provisioned nor recovered. If the attacker knows the exact firmware build, the same packet can carry a counterfeit event that CoreSignalEvent() dispatches. The code then runs in ring 0 of the DXE phase, before any operating system protection exists.

Ars Technica puts this in context: the payload does not survive a reboot, but in that time it can install further components that run early on every boot. HD Moore (Dragos) points out that the firmware still has access to the TPM at this point, which can undermine disk encryption that relies on the TPM, even with brief network access and more easily still with a stolen device. According to Ars, such exploits also bypass attestation, which is meant to prove cryptographically to a remote service that a server's hardware is unchanged. Jesse Michael (Eclypsium) adds a caveat: an exploit needs to know addresses in the target system and therefore has to be adapted for every model, version and configuration.

As far as is known, the flaw is not suited as a first step into someone else's network: Ars sees no evidence of that. Likely users are insiders or attackers already inside the network, such as state actors or ransomware gangs looking to escalate their privileges.

Who is affected

Only a machine that is currently booting via PXE is vulnerable, and only for the duration of that boot. Machines that boot from SSD or hard disk are not affected by this flaw. According to Ars Technica, however, PXE is enabled by default in EDK II based firmware, and network boot for provisioning and recovery is common in data centres.

Intel told Ars that none of its commercial products currently under security support are known to be affected, but board vendors may have integrated the code themselves. Arm calls the flaw “not directly applicable” to its portfolio. AMD, AMI, Phoenix, Microsoft and Amazon had not responded by publication. On 28 October, Debian lists the edk2 package, the source of OVMF, as vulnerable in bookworm, trixie and sid.

Context: the next firmware flaw before the operating system

Ars Technica places the flaw in a series with LogoFail (bugs in rendering vendor logos in the firmware), PKFail (test platform keys that were public for over a decade and present in hundreds of device models), BootHole and the BlackLotus bootkit. The closest relative is PixieFail: in January 2024, Quarkslab described nine vulnerabilities in the IPv6 network stack of EDK II, which is also used during PXE boot.

One difference makes remediation easier. Jesse Michael (Eclypsium) stresses that, unlike BootHole, BlackLotus or Baton Drop, no revocation lists, no PK, KEK, db or dbx updates and no new boot or installation media are needed; a BIOS or UEFI update is enough. HD Moore nevertheless expects a “forever bug” that will remain in systems without vendor support.

How the embargo broke

The finders had agreed on a coordinated disclosure in January 2027. On 28 September 2026, however, a developer at AMI submitted the fix as public pull request #13200, with a description of the root cause and the CVE number in the title. Michael Kinney (Intel) reworked it as #13302, which was merged into the master branch on 15 October. The advisory followed on 22 October. Golem gives as the reason for the earlier disclosure that attackers could now quickly build an exploit from the public patch, also with the help of AI; comparing the old and new code is enough.

On 27 October, TianoCore confirmed in the pull request that the embargo had been broken by mistake. In the same thread, another reporter complains that private security reports have gone unanswered for months while public pull requests are reviewed quickly. TianoCore acknowledges a backlog and plans to prioritise reports that come with a ready patch.

Checking for yourself: Linux, Proxmox, libvirt

On a Linux machine with UEFI, efibootmgr -v lists the boot entries in NVRAM. Network boot shows up as entries such as “UEFI PXEv4” or “PXEv6”, or as device paths containing MAC(…)/IPv4(…) or IPv6(…). If no such entry exists, the firmware may still have its network stack enabled through a setup option; that can only be checked in the setup or via iLO, iDRAC or Redfish.

dmidecode -s bios-vendor and dmidecode -s bios-version show the firmware supplier and version. AMI, Insyde or Phoenix suggest EDK II code but do not prove it; Intel points out that board vendors may integrate the driver themselves. Only the vendor's answer is authoritative.

On Proxmox, qm config <vmid> | grep -E '^(bios|boot)' shows whether a VM runs with bios: ovmf and has net0 in its boot order. Only this combination can be affected, because only OVMF brings the EDK II network stack; VMs with SeaBIOS boot via iPXE and are not affected by this flaw. Proxmox ships the firmware in the package pve-edk2-firmware. Under libvirt, virsh dumpxml <vm> reveals the loader (OVMF) and a <boot dev='network'/> or a boot order on the network device.

Ideas

  • A flaw before the operating system bypasses Secure Boot because nothing has been verified yet.
  • During network boot, the PXE driver accepts ICMP error messages without authentication.
  • Only machines currently booting via PXE are vulnerable; booting from SSD is not.
  • An exploit has to be adapted to model, firmware build and configuration.
  • The fix only needs a firmware update, no Secure Boot revocation lists.
  • An accidentally public pull request can cut an embargo short by months.
  • Virtual machines with OVMF also ship the EDK II network stack.

Insights

  • When almost all firmware vendors use the same reference code, a flaw in it becomes a problem for an entire industry. How quickly it disappears is decided by the slowest vendor; servers without support remain vulnerable for good.
  • Secure Boot and measured boot only protect what is loaded after them. The firmware's own network stack sits before that; PixieFail already hit the same area of EDK II in 2024, and the fuzzing campaigns that followed did not find this flaw.
  • If public pull requests are reviewed faster than confidential reports, a project rewards exactly the path that undermines coordinated disclosure.

Quotes

  • “The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance; the exposure window is the duration of the PXE boot.” (TianoCore advisory GHSA-99cj-7hg9-mp4m)
  • “In this particular GHSA example, embargo was violated due to a mistake, resulting in the PR being created in the open.” (TianoCore in pull request #13302 on 27 October 2026)

Facts

  • CVE-2026-97631 is rated 9.5 (critical) under CVSS v4; the advisory was published on 22 October 2026.
  • The affected driver is NetworkPkg/UefiPxeBcDxe; the field Mode.IcmpError is 504 bytes, and both IPv4 and IPv6 are affected.
  • Public pull request #13200 dates from 28 September 2026; the fix (#13302) was merged into master on 15 October.
  • On 28 October 2026, Debian lists edk2 as vulnerable in bookworm, trixie and sid (Debian bug 1151853).
  • According to Ars Technica, coordinated disclosure had been planned for January 2027.

References

Critique

  • Golem, heise, Dr. Web and Ars Technica write that the attacker needs access to the local network. The advisory, in contrast, speaks of a unicast message “from any network distance”. What matters is whether the address of the booting machine is reachable; restricting this to the LAN describes typical networks, not the flaw itself.
  • On 28 October, the advisory still lists “Not patched currently” under “Patched versions”, although the fix has been in the master branch since 15 October. Anyone reading only the advisory will misjudge the state of things.

Remarks

  • The “16 years” figure comes from Ars Technica and was adopted by Golem and heise; neither the advisory nor the pull requests state the age of the flaw. heise (based on t3n) dates the public fix to mid-October; pull request #13200 was already public on 28 September, and mid-October only saw the merge into master.
  • Debian rates the flaw as a “minor issue” for trixie without a dedicated security update, so OVMF users have to wait for a regular package update.

Recommendations

  • Take stock: on Linux, efibootmgr -v shows whether PXE entries for IPv4 or IPv6 are in the boot order; for servers, also check via iLO, iDRAC or Redfish.
  • Disable network boot or remove it from the boot order where it is not needed; put required PXE installations into a dedicated provisioning network that workstations and guest network devices cannot send packets to and that ICMP error messages from outside cannot reach.
  • Ask the server or mainboard vendor for a firmware update for CVE-2026-97631; tenants of dedicated servers should ask their hosting provider for the date. Treat devices without support as permanently vulnerable and remove them from the boot network before an exploit exists for their model; organisations under NIS2 track the flaw in their vulnerability management under section 30 of the German BSI Act (BSIG).
  • On Proxmox or libvirt, check which VMs with OVMF boot from the network, and update the edk2 or OVMF package as soon as the distribution fixes it.

Read the security advisory

Search the Web Archive

Matthew Garrett · 2014

Secure Boot in practice: How firmware bugs undermine the protection

Matthew Garrett summarises MITRE’s research from SyScan 2014: on many computers, Secure Boot can be bypassed from within the running operating system. The cause is not the cryptography but wrongly stored policies and missing lock bits in the chipset. Garrett still considers Secure Boot a real security gain whose obvious flaws will only disappear over several hardware generations.

Matthew Garrett · 2011

UEFI Secure Boot: Why signed firmware could lock out Linux

Shortly before Windows 8, Matthew Garrett explains the key model of UEFI Secure Boot and warns that computers with only OEM and Microsoft keys will no longer boot a generic Linux. According to Garrett’s analysis, signed Linux versions fail because of GPL bootloaders, self-built kernels and the lack of a central signing authority. The assessment: it is too early to panic, but not too early to be concerned.

Own project · 2026

SYN-ACK reflection: when your own web server works for someone else’s attack

In October 2026 the firewall log of my home network suddenly showed hundreds of connection attempts to my reverse proxy, all from two networks of a Polish provider. The analysis revealed crafted SYN packets whose replies nobody ever answered, so most likely not an attack on me but on the network of the supposed senders. This post shows how to recognise SYN-ACK reflection, why my country block did not apply and how I drop the packets in OPNsense for a limited time.