Network-Booting Servers Can Run Attacker Code Before Security Starts

A critical flaw in widely used server firmware can let a network attacker run code before the operating system loads, when its security controls are not yet running. ^[1][2]

TianoCore, the project behind the open-source EDK II firmware codebase, disclosed the vulnerability on October 22, 2026. Its advisory rates the flaw, identified as CVE-2026-97631, at 9.5 out of 10 and lists patched versions as unavailable. The affected component handles network boot, the process of starting a computer with instructions downloaded from another machine. ^[2]

The exposure reaches across a shared foundation of server hardware. Firmware suppliers including AMI, Insyde and Phoenix extensively reuse EDK II, according to Ars Technica. ^[1] But a machine must contain the affected code and be booting over a network for this flaw to be triggered. ^[1][2] The number of vulnerable systems is unknown, and Ars reported no evidence of exploitation as of its October 27 article. ^[1]

An attacker also needs access to the local network, according to Ars. ^[1] This vulnerability does not, by itself, give someone outside an organisation a way into that network. It could give an intruder already inside, or an insider, a route into a much earlier stage of a machine's operation. ^[1]

A small field with a large consequence

Firmware is the low-level software that starts a device and prepares it to load its operating system. UEFI is a standard for that startup process. EDK II provides code that hardware makers can adapt into their own UEFI firmware. ^[3]

The vulnerable component supports PXE, a method of starting computers over a network rather than from their own disks. During that startup sequence, the driver processes network error messages called ICMP messages. ^[2] It sets aside a fixed 504-byte field for them, but fails to stop copying when a message is larger. ^[2] Attacker-controlled data can spill beyond the field and overwrite other firmware memory. ^[2]

An unauthenticated attacker can trigger that overwrite by sending a specially constructed error message to the booting machine's IP address. ^[2] The advisory describes exposure during network boot over either IPv4 or IPv6, the two main versions of the internet addressing system. ^[2] No login is required. ^[2]

One possible result is a stalled boot. ^[2] The more serious outcome requires knowledge of the target's firmware build: the attacker can construct a packet containing a counterfeit firmware event that causes the machine to execute attacker-supplied code. ^[2]

That code runs during DXE, a firmware stage before the operating system takes over. ^[2] According to TianoCore, execution can happen before Secure Boot, a check that only trusted startup software runs, or measured boot, a record of startup steps, has checked or recorded operating-system components. ^[2] Those protections help establish that a machine starts with trusted software, but they do not protect against this particular flaw. ^[1][2]

The security problem is the order of events. An operating system's controls cannot supervise an attack that has already executed before they become active.

Shared code, conditional exposure

The researchers credited with finding the vulnerability and providing the recommended fix are Alex Matrosov of Anthropic and Dan Holmes of Google. ^[1][2]

TianoCore says the UEFI specifications have been adopted by more than 200 companies and shipped on millions of devices, although that figure measures adoption of the standard, not deployment of this vulnerable component. ^[3]

The practical dividing line is network boot. Ars says machines that start solely from disk, including the home and small-office devices it describes, fall outside the reported exposure. ^[1]

Nor does knowing how to cause the memory overwrite automatically give an attacker a working code-execution attack against every affected machine. Eclypsium researcher Jesse Michael told Ars that an exploit must be tuned to the firmware model, version and configuration because memory addresses differ. ^[1]

Ars also reports that the resulting attack code does not persist by itself. ^[1] An attacker could, however, use that access to install other code that runs early in subsequent boots. ^[1] That makes successful exploitation a possible starting point for a more durable compromise.

Intel told Ars that none of its commercial products currently under security support were known to be affected. Its reference code does not contain the vulnerable EDK II functionality, Intel said, though a system maker might add it. ^[1] Arm said the vulnerability was not directly applicable to its product portfolio. ^[1] Neither statement settles the status of every finished server built around those companies' technology.

A fix must travel through the hardware chain

A code correction and an update ready to install are different milestones. Ars reports that an AMI pull request published the previous month described the vulnerability and included a fix, exposing it before the planned coordinated disclosure. ^[1] TianoCore subsequently published its advisory, which still lists no patched versions. ^[1][2]

For operators, repair may require an update to the motherboard's basic startup software, commonly called BIOS or UEFI, from the system or motherboard maker. Firmware suppliers adapt shared code into their own products, so a correction must work its way through that distribution chain. ^[1] Michael told Ars the basic fix could be delivered in such an update. ^[1] Ars described distribution across vendors and devices as cumbersome. ^[1]

Ars advises affected organisations to ask their firmware maker for guidance and, where possible, temporarily disable network boot. ^[1] It also recommends monitoring logs for signs of attempted exploitation. ^[1] Secure Boot and TPM, a security chip that stores keys and records startup measurements, remain worthwhile, it says, even though they do not stop this vulnerability. ^[1]

The immediate task for operators is to establish which machines contain the affected component and depend on PXE. The next delivery that matters is a firmware update they can install on those machines. ^[1][2]