Most servers running today — in data centres, cloud providers, and enterprise racks — are vulnerable to a critical flaw that lets an attacker run arbitrary code before the operating system even loads. That's the finding from researchers who disclosed a bug in EDK II, the open-source codebase that virtually every major hardware vendor uses to build UEFI firmware.

UEFI is the software that wakes up when you hit the power button — it runs before Windows, Linux, or anything else, and it has more trust than any software layer above it. Code executed at this level is invisible to endpoint detection tools, can survive OS reinstalls, and can subvert Secure Boot itself. The flaw has apparently been sitting in EDK II for 16 years.

The attack path requires network access during a network boot (PXE boot) sequence, which limits the exposure somewhat. You can't trigger it from a browser or a phishing email. But in data centre environments — where servers routinely boot over the network, and where Volt Typhoon-style actors have already demonstrated they can reach internal management interfaces — that's a meaningful attack surface, not a theoretical one.

Why this matters more than a typical patch advisory

Most vulnerabilities live in userspace or the OS kernel. Patch them, and you're clean. UEFI flaws are different: they're hard to detect, hard to remediate, and can persist through the kinds of incident response steps that defenders rely on. A threat actor who plants a bootkit at the firmware level effectively owns the machine underneath every security control stacked above it.

The timing is pointed. Separately, Lumen Technologies' Black Lotus Labs published research this week exposing Volt Typhoon's "Silent Train" infrastructure — a rotating network of compromised SOHO routers, IoT devices, and enterprise gear the Chinese state-sponsored group has used to pivot into critical infrastructure targets across four separate zero-day exploitation campaigns since late 2023. Firmware-level persistence is exactly what a patient, long-dwell actor like Volt Typhoon would prize.

What defenders should do right now

First, audit which systems in your environment are configured to allow network booting — and whether that access is appropriately restricted. Most production servers don't need PXE boot enabled after initial provisioning; disable it where possible. Second, check with your hardware vendor for EDK II firmware updates and expedite that patch cycle. Firmware updates are slow, painful, and often deprioritised — this one shouldn't be.

Third, treat this as a supply chain risk, not just a patching task. EDK II is the common ancestor for a huge range of vendor-specific firmware forks. The original patch may not flow automatically to every downstream implementation.

The Australian angle

Australian critical infrastructure operators subject to the SOCI Act have mandatory cyber incident reporting obligations — but detection of a firmware-level compromise is genuinely hard. The Australian Signals Directorate's Essential Eight includes firmware patching under its application control and patching frameworks, but UEFI patching cadences are rarely as tight as OS-level patching. If your organisation hasn't reviewed its firmware patch status recently, this is the prompt.