TianoCore has published a critical advisory for EDK II, the reference code most vendors build their UEFI firmware from. The flaw lets an unauthenticated attacker run code during PXE boot, before the operating system starts and before Secure Boot can enforce anything.

What happened

The PXE driver in NetworkPkg keeps a receive request open for ICMP error messages and copies each message it receives into a fixed 504-byte field. The bounds handling in that copy loop is wrong in both the IPv4 and the IPv6 handler.

A single crafted unicast ICMP error message, sent while a machine is network-booting, corrupts DXE-phase memory. The advisory describes two outcomes: the boot hangs after a CPU exception, or the attacker gets arbitrary code execution at the highest privilege available before the OS loads.

The CVE record rates it 9.5 on CVSS 4.0. Alex Matrosov of Anthropic and Dan Holmes-Mitra of Google found it and had coordinated disclosure set for January; the details surfaced earlier after a vendor pull request exposed the vulnerability and its fix.

Who is affected

Devices that network boot, built from EDK II up to and including edk2-stable202608.

• Servers and workstations provisioned over PXE, the normal case in data centres and imaging benches
• Firmware from vendors that build on the EDK II reference code, including AMI, Insyde and Phoenix
• Project Mu, Microsoft's hardened EDK II fork, which carried the same vulnerable component
• Machines that never boot over the network do not open the vulnerable path

What to do now

Stop PXE booting on untrusted network segments, and confirm with your hardware vendor whether their current firmware carries the corrected driver. The upstream fix is merged, but no stable EDK II release contains it.

• Ask the vendor whether pull request 13302, merged 15 October 2026, is in the firmware they ship; the advisory still lists patched versions as unavailable
• Keep PXE on an isolated provisioning VLAN rather than the general office or server network
• Where network boot is not in use, disable it in firmware setup
• Track firmware as its own patch stream, separate from operating system updates

What this means for South African businesses

The real exposure sits where machines are imaged across the wire: MSP provisioning benches, virtualisation hosts, and sites still using PXE for rollouts. A small office fleet patched through Windows Update changes nothing here, because the code runs before Windows and before disk encryption keys are released. What makes this awkward is that the fix depends on a hardware vendor shipping new firmware, and firmware cycles are measured in quarters rather than weeks.

The primary source is the TianoCore advisory GHSA-99cj-7hg9-mp4m, recorded as CVE-2026-97631.