Are my servers exposed to the UEFI PXE flaw CVE-2026-97631, and is there a firmware fix?

By Brandon Da Costa, founder of Digiton Dynamics

Published 28 October 2026Updated 28 October 2026Editorial policy

If your servers boot over the network, possibly yes. CVE-2026-97631 is a memory corruption bug in the PXE driver of TianoCore EDK II, code that Ars Technica says most server firmware builds on. TianoCore rates it 9.5 and lists no patched release. The fix is in source, not yet in firmware you can install.

Who should act: Anyone who runs bare-metal servers, hypervisors or provisioning systems that PXE boot, and anyone who hasn't asked their server maker whether its firmware is built on EDK II.

Update log

28 October 2026: Published.

What happened

TianoCore published advisory GHSA-99cj-7hg9-mp4m on 22 October 2026. While a machine PXE boots over IPv4 or IPv6, an unauthenticated attacker who can deliver an ICMP error message to it can corrupt memory and run code before the operating system loads and before Secure Boot or measured boot checks anything. The PXE driver copies each message into a fixed 504 byte field and miscounts the bounds. The advisory credits Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google).

The fix surfaced early. An AMI engineer opened a public pull request with it on 28 September. That request was closed on 14 October and a revised version, pull request 13302, was merged on 15 October. Ars Technica (27 October) says the discoverers had planned a coordinated disclosure for January. The advisory still lists no patched version, and EDK II's newest tagged release dates from 21 August, before the fix (GitHub).

Sources disagree on reach and severity. TianoCore scores it 9.5 on CVSS 4.0 with a network vector and says the packet can come from any network distance. Red Hat scores it 8.8 on CVSS 3.1 with an adjacent network vector. TianoCore names EDK II master as of 14 September 2026 as affected. Debian marks its edk2 package vulnerable in bookworm, trixie and sid with no fixed version, and Ars calls the bug 16 years old. Ars quotes Eclypsium that an exploit must be tuned to each firmware build.

Vendors are quiet. Intel told Ars none of its supported commercial products are known to be affected, and Arm said the CVE isn't directly applicable. AMD, Phoenix, AMI, Microsoft and Amazon hadn't answered Ars when it published. My searches on 28 October found trackers from Red Hat and Debian and no advisory from a server maker.

Who is affected

Machines whose firmware is built on EDK II and that PXE boot. Ars says PXE is on by default in the affected code.
Hosts that run virtual machines on OVMF firmware, since Debian lists its edk2 source package, which builds OVMF, as vulnerable.
Not machines that boot only from local disks, per Ars.

Secure Boot and a TPM don't stop it. The advisory says the injected code runs before either checks anything.

What we checked

Run on 28 October 2026 on the Mac that builds this site. Each command and its output are copied as they ran.

$ curl -s https://api.github.com/repos/tianocore/edk2/pulls/13302 | grep -E '^  "(merged|merged_at)"'
  "merged_at": "2026-10-15T00:09:15Z",
  "merged": true,

$ curl -s https://api.github.com/repos/tianocore/edk2/releases/latest | grep -E '"(tag_name|published_at)"'
  "tag_name": "edk2-stable202608",
  "published_at": "2026-08-21T08:12:44Z",

The upstream fix, pull request 13302, was merged on 15 October. The newest tagged EDK II release is from 21 August, so no tagged release carries the fix yet. This Mac has no EDK II firmware to inspect.

What to do now

Find the machines that PXE boot. Ask your provisioning system for every host with network boot enabled, then check each server's boot entries.
```
sudo efibootmgr -v | grep -i -E 'pxe|ipv4|ipv6'
```

Record the firmware vendor and version for each server class.

sudo dmidecode -t bios | grep -E 'Vendor|Version|Release Date'

Ask each server maker for an advisory that names CVE-2026-97631 and the BIOS version that fixes it. Ars advises asking the firmware maker for guidance. Subscribe to their security feeds.
Until firmware ships, boot from disk first and turn network boot off where you don't provision. A host that falls back to PXE after a failed disk boot is exposed again, so remove the network entry in firmware setup where you can.
```
ipmitool chassis bootdev disk options=efiboot,persistent
```
Keep hosts that must PXE on a provisioning VLAN that untrusted networks can't route to. Watch for hung boots, since the advisory says the denial of service shows up as one.
On hypervisors, track your distribution's edk2 or OVMF update.
```
dpkg -l | grep -E 'ovmf|edk2'
rpm -qa | grep edk2
```

What should have been in place

A firmware inventory with vendor, version and base code, kept like the OS package list.
Network boot off by default and on only during a provisioning window.
A provisioning network that untrusted networks can't reach.
A named contact at each server maker who tells you the day a firmware advisory ships.
Alerts on hung or unexpected PXE boots.

Questions people ask

Does CVE-2026-97631 affect laptops and home PCs?

Ars says it doesn't reach home and small office users or anyone who boots only from disks. It applies to machines that boot from the network and run EDK II based firmware.

Is there a patched firmware version?

Not that I found on 28 October. TianoCore lists no patched version, the upstream fix is in no tagged release, and Debian lists the edk2 package as unfixed. Server makers have to build and ship updated firmware.

Do Secure Boot and a TPM protect me?

No. TianoCore says the injected code runs before either checks anything, and Ars says those defenses don't cover this flaw.

Is this a remote attack from the internet?

The sources disagree. TianoCore says the packet can come from any network distance, Red Hat rates the vector adjacent, and Ars says the attacker needs some control over a local network. TianoCore and Ars agree the target must be mid-PXE boot.

Digiton's production review lists what runs where, firmware and runtimes included, and the checks it runs are on the vibe coded app audit page.

How this brief was made: researched from the sources below, drafted with AI assistance and checked against each source on the dates shown. See the editorial policy.

Sources

TianoCore, Pre-boot RCE in EDK II PXE driver (GHSA-99cj-7hg9-mp4m), 22 October 2026, read 28 October 2026. https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m
GitHub, tianocore/edk2 pull request 13302, the merged fix, 14 October 2026, read 28 October 2026. https://github.com/tianocore/edk2/pull/13302
GitHub, tianocore/edk2 pull request 13200, the first public fix, 28 September 2026, read 28 October 2026. https://github.com/tianocore/edk2/pull/13200
GitHub, edk2-stable202608 release, 21 August 2026, read 28 October 2026. https://github.com/tianocore/edk2/releases/tag/edk2-stable202608
Red Hat, CVE-2026-97631, read 28 October 2026. https://access.redhat.com/security/cve/cve-2026-97631
Debian security tracker, CVE-2026-97631, read 28 October 2026. https://security-tracker.debian.org/tracker/CVE-2026-97631
Ars Technica, code-execution flaw in UEFI firmware affects most servers on planet Earth, 27 October 2026, read 28 October 2026. https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/
Hacker News, discussion of the Ars Technica report, 27 October 2026, read 28 October 2026. https://news.ycombinator.com/item?id=50265393

More briefs

Is my server exposed to PHP2Shell, and which PHP version fixes it?Does my Mac, CI runner or server still trust the compromised eMudhra certificates?What should I rotate and move before Zeabur shuts down on 31 December?

How these briefs are sourced and corrected. All AI and security briefs

Building something that has to hold up in production?

Start with a free 25-minute scoping call. If it fits, the first paid step is a production review: five working days on your real repository, scored against ten layers, with a costed fix list.

Book a 25-minute scoping call