What is the UEFI firmware flaw affecting most servers — and what should a regular computer owner check?

A code-execution flaw rated 9.5 out of 10 in EDK II, the reference code under most UEFI firmware, can strike machines while they boot over a network — before the operating system or Secure Boot checks begin. Here is why firmware below the OS matters, why servers are the real target, and the short checklist a regular computer owner should run.

Short answer: researchers found a code-execution flaw (tracked as CVE-2026-97631, rated 9.5 out of 10) in EDK II, the open-source reference code underneath most UEFI firmware — the software that runs before your operating system starts. Ars Technica reports it mainly threatens servers and other machines that boot over a network; a home PC that boots from its own disk is outside the reported exposure. Why it matters: UEFI firmware sits below Windows or Linux, so it runs before your antivirus, your sign-in, and most security checks — code that runs there is extraordinarily hard to spot from inside the operating system.

The flaw lives in the PXE network-boot part of the firmware; faulty size-checking there can let crafted network traffic corrupt memory and, at worst, run an attacker’s code at the firmware’s most privileged level. Because AMI, Insyde, Phoenix, and Microsoft’s Project Mu all build on EDK II, one bug echoes across many brands.1. Know whether it touches you.

The reported trigger needs network (PXE) booting. Servers, data-center machines, and office fleets that install systems over the network are the priority; a laptop booting from its own SSD is not the target described in the reporting.2. Check your maker for BIOS/UEFI updates.

Visit the manufacturer’s own support page for your exact model and install firmware updates from there as vendors publish fixes — and watch for your server or Linux vendor’s update if you run one.3. Turn off network boot if you never use it. In firmware setup, disabling PXE/network boot on machines that always start from a local disk removes the listening feature entirely.4.

Keep Secure Boot on. Reporting notes Secure Boot does not stop this particular flaw, because the vulnerable code runs earlier — keep it enabled anyway; it still guards the rest of the boot chain.5. Back up before any firmware update, keep the machine plugged in during the update, and never interrupt it.Pro tip: The common mistake is downloading a “BIOS update” from a forum or driver site.

Firmware comes from your device maker or nobody — a fake firmware file is worse than the bug.Ad’s take: Sixteen years is a long wait for one bug in the world’s most shared starter code. For home users the list is short: maker updates, network boot off if unused, no panic.