A reported code-execution flaw in TianoCore EDK II, the open-source codebase used to create UEFI firmware, is rattling the server-security world. Ars Technica reports the bug carries the identifier CVE-2026-97631 and a severity rating of 9.5 out of 10. It is a memory-corruption flaw in an ICMP component, and it can give an attacker code execution before the operating system starts.
The headline version of this story says the UEFI vulnerability affects most servers on planet Earth. The reporting itself is more careful. Ars Technica says the reference code is used by most of the world’s server vendors and data centers, but the coverage reviewed here gives no affected-server count and no percentage. This article keeps those two things apart: what is confirmed, and what is still a claim.
A 9.5 score lands in the top tier of severity ratings, yet a score alone never tells a defender how fast to move. Our breakdown of EPSS vs CVSS vs CISA KEV vs SSVC explains why exploit likelihood and known-exploitation status matter as much as the raw number. For this flaw, the coverage reviewed does not establish either signal.
Don't miss new tech stories on Google
Add Tech Insider once in the Google app and our stories appear in your news suggestions.
What Ars Technica Reports About CVE-2026-97631
The core facts are short. Ars Technica identifies the vulnerable software as TianoCore EDK II, the open-source reference code that firmware makers build on. The flaw sits in an ICMP component, the part of a network stack that handles control messages such as echo requests. A memory-corruption bug there can let an attacker run code during boot.
Ars Technica also names three UEFI suppliers that use the reference code extensively: AMI, Insyde and Phoenix. It adds that Project Mu, described as Microsoft’s hardened EDK2 fork, used the vulnerable component too. That detail matters because hardened forks usually exist to cut exactly this kind of exposure.
The reported exploit runs code before protections such as Secure Boot and the Trusted Platform Module (TPM) can be applied. That timing is the reason the severity score sits so high. The table below lists every point the available reporting confirms.
| Detail | What is reported | Source |
|---|---|---|
| Affected codebase | TianoCore EDK II, open-source code used to create UEFI firmware | Ars Technica |
| Identifier | CVE-2026-97631 | Ars Technica |
| Bug class | Memory corruption in an ICMP component | Ars Technica |
| Severity | 9.5 out of 10 | Ars Technica |
| Suppliers named | AMI, Insyde, Phoenix | Ars Technica |
| Microsoft fork | Project Mu used the vulnerable component | Ars Technica |
| Execution timing | Before Secure Boot and TPM protections apply | Ars Technica |
| Payload behavior | Final payloads have no persistence and run once | Ars Technica |
UEFI Vulnerability Basics: Why Firmware Bugs Hit Harder
UEFI is the firmware layer that wakes a machine, initializes hardware and hands control to a bootloader. It runs first and holds the most privilege. Anything that executes there sits beneath the operating system, the endpoint agent and the disk encryption stack.
That position changes the math for defenders. A bug in a web app can be fenced in by the OS. A bug in firmware has no outer fence, because the firmware builds the environment everything else trusts. Security tools that load later cannot inspect what already ran.
Firmware also updates slowly. Server fleets get BIOS and BMC updates on maintenance windows, and many teams delay them for stability. Even when a fix exists, rolling it across thousands of hosts takes weeks of planning. A pre-boot flaw therefore tends to outlive the news cycle that announced it.
Inside the EDK II ICMP Memory-Corruption Flaw
ICMP is a small protocol, and that is part of the lesson. Network code in firmware handles untrusted input from the wire, yet it is often written in C with manual memory handling. A memory-corruption bug in that path means crafted network data can overwrite memory the firmware did not intend to expose.
Ars Technica describes the result as code execution before the operating system starts. The available reporting does not publish the exact trigger conditions, the required network position or the affected build ranges. Treat any claim of a precise exploit recipe as unverified until a vendor advisory or the CVE record says so.
One point deserves care. Network components in firmware usually matter when a machine uses network boot or other pre-boot networking features. Whether a given server exposes this component depends on its configuration and build. The reporting reviewed does not say, so defenders should check their own firmware settings rather than assume either way.
Why a 9.5 Severity Score Matters for Servers
Severity scores weigh impact, attack complexity and required privileges. A 9.5 reflects a flaw with deep impact, since firmware control reaches everything above it. Ars Technica reports the rating, but the available coverage does not break out the scoring vector, so the reasons behind each sub-score remain unclear.
Servers raise the stakes beyond what a laptop bug would. A single data center holds many machines running the same firmware family. One working technique can scale across a rack, a cluster or a region, if the exposed component is reachable in each case. That scaling potential is why reporters lean on phrases like most of the world’s server vendors.
Still, a high score is a starting point. The vulnerabilities that hurt most are the ones attackers actually use. Our report on the Arista VeloCloud zero-day that hit CVSS 9.9 and joined the KEV list shows how a confirmed-exploited entry changes priorities overnight. No such listing is reported for CVE-2026-97631 in the material reviewed.
The Most-Servers-on-Earth Claim: What Is and Is Not Established
The viral framing says this flaw touches most servers on the planet. Ars Technica’s wording is narrower. It says the reference code is used by most of the world’s server vendors and data centers. That describes reach across the supplier base. It does not count vulnerable machines.
The gap between those two statements is large. A vendor can ship the reference code without enabling the vulnerable path, or can ship a patched build, or can use a different network stack entirely. Shared lineage creates risk. It does not prove every machine is exploitable.
Here is what the reviewed reporting does not provide:
- A precise count or percentage of affected servers
- Specific affected server models
- Named cloud providers that are exposed
- Firmware versions that carry the bug
- Patch availability or fixed builds
- Evidence of exploitation in the wild
- Attribution to any attacker or group
Until those items appear in vendor advisories, the safest summary is this: a severe, widely shared firmware component has a reported flaw, and the true exposure is still being measured.
Which Vendors and Codebases Sit in the Blast Radius
The reference-code supply chain
EDK II is the upstream. Independent BIOS vendors take it, adapt it and sell it to hardware makers. Ars Technica names AMI, Insyde and Phoenix as suppliers that use the reference code extensively. Server and motherboard makers then wrap that firmware with their own drivers, management features and branding.
This layered chain explains the patch headache. A fix in the upstream project has to travel to each supplier, then to each hardware maker, then to each customer fleet. Every hop adds delay and a chance for a build to be skipped. Defenders usually learn their real status only when their hardware vendor publishes a bulletin.
Project Mu and hardened forks
Project Mu is Microsoft’s hardened fork of EDK2, according to Ars Technica, and it used the vulnerable component. The takeaway is plain. Hardening a fork reduces some risks, but it does not remove bugs inherited from shared code. Forks that track upstream closely inherit upstream flaws.
Teams that run their own firmware builds should audit which network features they compile in. Removing an unused pre-boot network stack shrinks the attack surface more reliably than waiting for a patch cycle. That choice sits with whoever controls the build, which is why hyperscalers and small hardware shops face different decisions here.
How the Exploit Sidesteps Secure Boot and TPM
Secure Boot checks that a bootloader carries a trusted signature before it runs. The TPM records measurements of the boot chain so that software can later verify what ran. Both protections assume the firmware doing the checking is itself trustworthy. Ars Technica reports that this exploit executes code before either protection can be applied.
Think of it as a guard who is compromised before the shift starts. The inspection routine still exists on paper, but the person running it already works for someone else. That is why firmware flaws get discussed as a separate class from OS bugs, and why a clean Secure Boot status does not prove a clean machine.
Disk encryption that depends on TPM state deserves a second look in this context. If you rely on measured boot to release keys, review how your stack behaves when firmware changes. Our guide to BitLocker, VeraCrypt, LUKS and FileVault covers how each tool ties into the boot chain.
Single-Shot Payloads and the Persistence Question
Ars Technica reports that the final payloads have no persistence and run only once. That sounds reassuring, and in a narrow sense it is. The payload does not sit in firmware waiting for the next reboot. But the same report says attackers could use the access to install other payloads that execute during later boot processes.
So the one-shot design is a limit on the initial payload, not a limit on the attacker. A single successful run could drop something that survives. For a defender, the practical reading is that a machine hit by this exploit should be treated as untrusted until it is checked, even if no lasting implant is obvious.
Detection is hard because the activity happens before most logging starts. Teams that watch boot-time behavior, firmware hashes and unexpected network traffic from machines in their pre-OS phase have the best chance of spotting trouble. Rules that flag odd early-boot network activity can feed a SIEM, and our walkthrough on building Wazuh SIEM detections for PHP2Shell shows the rule-writing workflow in a different threat context.
A Separate Issue: CERT/CC VU#718077 and Cisco CVE-2026-20293
Readers searching this topic will also hit another UEFI story. CERT/CC advisory VU#718077 describes a UEFI Shell issue in SPI flash that can undermine Secure Boot under specified conditions. Cisco UCS Servers and UCS-based appliances are affected by a variation of VU#718077, assigned CVE-2026-20293.
The available results present these as separate issues. Nothing in the reviewed material says VU#718077 or CVE-2026-20293 is the same flaw as CVE-2026-97631. Mixing them up would send teams down the wrong remediation path, since the affected components and fixes would differ.
| Attribute | CVE-2026-97631 | VU#718077 / CVE-2026-20293 |
|---|---|---|
| Reporting source | Ars Technica | CERT/CC advisory |
| Component | ICMP component in TianoCore EDK II | UEFI Shell issue in SPI flash |
| Reported effect | Code execution before the OS starts | Can undermine Secure Boot under specified conditions |
| Severity reported | 9.5 out of 10 | Not stated in the reviewed material |
| Named affected products | Suppliers AMI, Insyde, Phoenix, plus Project Mu | Cisco UCS Servers and UCS-based appliances (CVE-2026-20293) |
| Same flaw as the other? | Not established. The sources present them as separate issues. | |
Historical Context: Shared Code, Shared Exposure
Firmware security has followed a recurring pattern in recent years. Researchers find a flaw in code that many vendors share, the disclosure lands, and then months pass while the fix works its way down the supply chain. The shared upstream is efficient for manufacturers and brittle for defenders.
The industry has also seen boot-level attacks aimed squarely at Secure Boot, which is why the protection is no longer treated as a final answer. The lesson from those episodes is consistent. Trust anchors fail when the code beneath them fails, and fixes arrive faster for products with a single owner than for products assembled from many parts.
CVE-2026-97631 fits that mold on the facts reported so far. It lives in open-source reference code, it reaches many suppliers, and it undercuts protections that organizations bought specifically to guard the boot path. What it adds is a network-facing entry point in a component that many admins never think about.
Market Impact: Server Makers, Data Centers and Security Budgets
No coverage reviewed here quantifies a financial hit, so any dollar figure would be invented. What can be said is directional. Server vendors will face customer questions about firmware provenance. Data center operators will ask suppliers for attestation of which network features ship enabled. Insurers and auditors tend to follow with questions of their own.
Firmware assurance vendors and endpoint security firms that sell boot-integrity checks have an opening, since the story argues for visibility below the OS. Teams will test whether those products catch tampering that happens before their agents load. Buyers should ask for evidence, not slide decks.
The cost is mostly operational. Firmware updates require reboots, validation and rollback plans. For a large fleet, that is labor and downtime, and it competes with every other patch in the queue. Incidents like the TiDB Cloud breach that ran 28 days on a stolen service account show how long attackers can sit unseen once they hold a foothold, which is the scenario pre-OS access makes easier to start.
Competitive Comparison: How Firmware Supply Models Differ
Not every firmware model carries the same exposure. The comparison below is qualitative and rests on how each model works, not on measured vulnerability counts. The reporting confirms only that AMI, Insyde, Phoenix and Project Mu relate to the vulnerable reference code.
| Model | How it works | Upside | Risk for a bug like this |
|---|---|---|---|
| Upstream EDK II reference code | Open-source base that suppliers build on | Public review and a single place to fix | Flaws propagate to every downstream user |
| Independent BIOS vendors (AMI, Insyde, Phoenix) | Adapt the reference code and license it to hardware makers | Dedicated engineering and customer support | Fixes must pass through vendor, then OEM, then customer |
| Hardened forks (Project Mu) | Maintained fork with added hardening | Tighter controls and faster internal changes | Still inherits upstream flaws, as the reported component shows |
| Custom in-house builds | Operator compiles its own firmware | Can strip unused network features | Requires internal expertise and patch discipline |
The pattern is clear. Control over the build is the best defense, and control costs engineering time. Most organizations sit lower on that ladder and depend on their hardware vendor’s bulletins.
What Defenders Should Do Now
The facts are thin, so the right moves are cheap, reversible and aimed at reducing exposure while details firm up. None of the steps below depend on unconfirmed claims. They are standard firmware hygiene that pays off whether or not this specific CVE hits your fleet.
| Priority | Action | Why it helps |
|---|---|---|
| 1 | Ask each server vendor for a written statement on CVE-2026-97631 | Vendors know which builds ship the vulnerable component |
| 2 | Inventory firmware versions across the fleet | You cannot patch what you cannot see |
| 3 | Disable pre-boot network features you do not use, including network boot where possible | Cuts the reachable attack surface |
| 4 | Segment management and boot networks | Limits who can send traffic to a booting host |
| 5 | Plan a firmware update window and a rollback path | Lets you move the day a fix lands |
| 6 | Monitor for odd early-boot network activity | Gives a chance to catch tampering attempts |
For hosts you run yourself, a baseline audit helps you spot drift in settings and services. Our Lynis Linux security audit in 13 steps walks through a repeatable hardening check. For wider reading on the topic, the cybersecurity section collects our related coverage.
Five Predictions for How This Plays Out
These are analysis, not reporting. They rest on how past firmware disclosures have unfolded, and they could prove wrong as facts arrive.
- Vendor advisories will lead the news. Expect AMI, Insyde, Phoenix and major server makers to publish statements that clarify which builds are affected. Those documents will replace the broad headline numbers.
- The most-servers framing will shrink. Once vendors state which products ship the component enabled, the practical exposure should look narrower than the first headlines suggested, though still serious.
- Firmware patching will lag. Server fleets update on slow schedules, so unpatched hosts will remain long after fixes exist.
- Pre-boot network features will draw scrutiny. Security teams will push to disable or remove network code that the boot path does not need.
- Boot-integrity monitoring will get budget. Buyers will ask whether their tools can see tampering below the OS, and vendors will have to answer with evidence.
Frequently Asked Questions
What is CVE-2026-97631?
Ars Technica reports it as a memory-corruption flaw in an ICMP component of TianoCore EDK II, rated 9.5 out of 10. It can enable code execution before the operating system starts.
Does this UEFI vulnerability affect most servers on Earth?
That claim is unconfirmed. Ars Technica says the reference code is used by most of the world’s server vendors and data centers, but the reviewed coverage gives no count or percentage of affected servers.
Which vendors are involved?
Ars Technica names AMI, Insyde and Phoenix as suppliers that use the reference code extensively. It also says Project Mu, Microsoft’s hardened EDK2 fork, used the vulnerable component.
Can the flaw bypass Secure Boot and the TPM?
The reported exploit executes code before those protections can be applied, according to Ars Technica. That is why a normal Secure Boot status does not prove the boot path is clean.
Does the attack persist after a reboot?
The reported final payloads have no persistence and run once. Ars Technica adds that attackers could use the access to install other payloads that execute during later boot processes.
Is this the same as CERT/CC VU#718077 or Cisco CVE-2026-20293?
No evidence says so. VU#718077 covers a UEFI Shell issue in SPI flash, and Cisco UCS Servers are affected by a variation tracked as CVE-2026-20293. The sources present these as separate issues.
Is there a patch or evidence of exploitation?
The material reviewed does not confirm patches, fixed firmware versions or exploitation in the wild. Check your hardware vendor’s security bulletins for current status.
