Tracked as CVE-2026-97631 and carrying a critical severity rating of 9.5 out of 10, a memory-corruption flaw in open-source boot-time firmware threatens enterprise servers worldwide. Discovered by security researchers Alex Matrosov of Anthropic and Dan Holmes of Google, the vulnerability resides within the ICMP component of the TianoCore EDK II codebase, exposing machines that boot from local networks or Internet-connected resources.
The TianoCore EDK II Architecture Vulnerability
Defenders across the world face the burden of responding to yet another botched code-execution vulnerability, Ars Technica reported. The flaw targets the TianoCore EDK II, an open-source codebase that hardware makers and cloud providers use to build the Unified Extensible Firmware Interface (UEFI) firmware running during the boot-up sequence. Last year, a representative of the UEFI Forum called EDK2 the preeminent solution and implementation of the UEFI specifications. Virtually all UEFI suppliers, including AMI, Insyde, and Phoenix, use the reference code extensively. Even Project Mu, which is Microsoft’s hardened EDK2 fork, used the code containing the vulnerable component.
With this vulnerability, malicious actors are able to run unauthorized code prior to the operating system and firmware activating protections such as Secure Boot. Secure Boot normally establishes a chain of trust for all code loaded during boot, including the Trusted Platform Module. While final payloads delivered by CVE-2026-97631 have no persistence and run only once, they give attackers a wide opening to install other payloads that execute each time early in the boot process.
Scope of Impact Across Hardware Vendors and Cloud Providers
The flaw does not affect home and small office users, or users who boot their devices solely from disk drives. Instead, it applies exclusively to organizations with machines that boot from local networks or conceivably from Internet-connected resources. In those scenarios, the targeted systems must utilize EDK2 rather than an alternative reference implementation, alongside the PXE feature which remains enabled by default.
Intel stated in an email that none of its commercial products currently under security support are known to be affected. Intel stated further that while its reference code excludes the vulnerable EDK2 feature, system manufacturers or OEM board vendors might incorporate it, and therefore recommended that customers consult their system maker for precise instructions. Publicly available Intel reference code, however, makes reference to EDK2. Moreover, TianoCore notes that every UEFI development kit provided by Intel serves as a fully verified implementation tailored to a specific version of the EDK II source code, with numerous other Intel publications similarly mentioning EDK2.
Arm responded to a list of questions by stating that CVE-2026-97631 is not directly applicable to Arm’s product portfolio. Like Intel, firmware the company makes available also borrows heavily from EDK2, and TianoCore has documented Arm’s reliance on EDK2. While it’s possible some platforms are free of EDK2 code, it remains prudent for users of all servers to investigate if CVE-2026-97631 affects them. When the original post went public, inquiries directed toward AMD, Phoenix Technologies, AMI, Microsoft, and Amazon—likely among the other principal organizations impacted—received no response.
Coordinated Disclosure Timeline and Public Patch Availability
The researchers who discovered CVE-2026-97631 had arranged for it to stay under wraps until a coordinated disclosure scheduled for January. However, AMI published a pull request last month detailing the vulnerability and including a code fix. As soon as the discovering researchers became aware of the publication, members of the TianoCore Project released a public advisory. With publicly available patch code now accessible, it will be trivial for advanced hackers to learn how the vulnerability is triggered and build working exploits. Remedying UEFI code vulnerabilities across millions of devices deployed by thousands of hardware manufacturers and cloud operators is an arduous and time-consuming process, which only adds to the gravity of the situation.
