Critical UEFI Flaw Exposes Millions Of Servers To Hijacking Threat

A newly-revealed UEFI exploit has entered the public sphere as CVE-2026-97631, and since it targets the TianoCore EDK2 open source codebase used by virtually all major manufacturers for their servers' UEFI firmware, enterprise and datacenter customers should be on high alert.

Before I dig further into the details of the newly-revealed CVE-2026-97631 exploit, I do want to dispel some potential hysteria surrounding it. While on paper, an exploit impacting every major UEFI provider (and even Microsoft's hardened EDK2 fork, Project Mu) sounds like a five-alarm fire for everybody, the exploit relies on specific network boot configurations to function at all.

Given that, if you're a typical home user, or you're an office user who is using a full-fat PC instead of a thin client connecting to server, this exploit is not an immediate cause for concern for you. However, for larger enterprise and data center environments, where thin clients and network boot configurations are common, this exploit can allow users to execute malicious code within UEFI during boot time.

Those factors make the true likelihood of exploitation surprisingly low, despite how scary the CVE-2026-97631 exploit would seem to be based on its ability to hijack a PC before Secure Boot can even start protecting it. A patch has also already been released for the issue by the open source Tianocore community, though it'll be up to UEFI providers to update their firmware to match.

While the original disclosure date for CVE-2026-97631 was intended for January of next year, manufacturers are already aware of it. Per Ars Technica, Intel and Arm alike have both seemingly already patched the exploit or implemented EDK2 differently enough that the exploit does not impact them.

However, AMD, Microsoft, Amazon, and AMI, among others, did not respond to a request for comment, which suggests the possibility that these vendors have yet to apply the necessary patches to their firmware. We and Ars highly recommend any potentially-impacted organization contact its firmware provider as soon as possible regarding patching.

Otherwise, if like most enterprise systems, yours is set up to run 24/7 with only scheduled reboots, I'd recommend simply holding off on restarts for until either a patch with the fix is available or you simply must reboot for maintenance purposes. In those cases, you can probably secure your boot process from this exploit by simply disabling network boot capabilities, provided your infrastructure allows for it.