--- title: Code-execution flaw in UEFI firmware affects most... description: A critical flaw in TianoCore EDK II, the reference codebase behind most server UEFI firmware, lets attackers execute code during boot before defenses like... canonical: https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Code-execution flaw in UEFI firmware affects most servers on planet Earth | daily.dev og:description: A critical flaw in TianoCore EDK II, the reference codebase behind most server UEFI firmware, lets attackers execute code during boot before defenses like... og:url: https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii og:image: https://api.daily.dev/og/posts/X5xRpf8Ii.png og:image:alt: Code-execution flaw in UEFI firmware affects most servers on planet Earth og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Code-execution flaw in UEFI firmware affects most servers on planet Earth **[Ars Technica](https://daily.dev/sources/arstechnica)** · 2 min read · 0 upvotes · 0 comments ## Summary A critical flaw in TianoCore EDK II, the reference codebase behind most server UEFI firmware, lets attackers execute code during boot before defenses like Secure Boot activate. Tracked as CVE-2026-97631 and rated 9.5 out of 10, it's a memory-corruption bug in an ICMP component. Payloads delivered this way don't persist on their own but can be used to install other code that runs on every boot. The fix leaked early: AMI published a pull request detailing the bug and patch before the planned coordinated disclosure, and TianoCore then published an advisory last week. Patching millions of devices across many vendors will be slow. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is CVE-2026-97631 and why is it dangerous? CVE-2026-97631 is a memory-corruption flaw in an ICMP component of TianoCore EDK II, the reference codebase most UEFI firmware vendors use, rated 9.5 out of 10 in severity. It lets attackers execute code during boot, before protections like Secure Boot and the TPM can establish a chain of trust. Payloads don't persist on their own but can install other code that runs on every subsequent boot. _Teams tracking firmware-level threats can follow disclosures like this one on daily.dev as patches roll out._ ### Which UEFI vendors are affected by the EDK II vulnerability? Virtually all independent BIOS vendors (IBVs) are affected because they extensively use the TianoCore EDK II reference code, including AMI, Insyde, and Phoenix. Microsoft's hardened EDK2 fork, Project Mu, also included the code containing the vulnerable component. This makes the flaw relevant to most of the world's server vendors and data centers. _Infrastructure teams vetting firmware supply chains can track EDK2 disclosures as they land on daily.dev._ ### How did the EDK II vulnerability get leaked before coordinated disclosure? AMI published a GitHub pull request detailing the vulnerability and including a code fix before the coordinated disclosure planned for January. Once discoverers Alex Matrosov (Anthropic) and Dan Holmes (Google) noticed, TianoCore Project members published a public advisory the following week, effectively forcing an early release of exploit-relevant details. _Security teams watching how disclosure timelines slip can follow incident writeups like this on daily.dev._ ## Community take How the wider developer community reacted, aggregated from 1 discussion and 82 comments across hackernews (as of 2026-10-30). **TL;DR:** Discussion centers on how narrow the real-world exploitability is (needs network-level access during PXE boot) versus the severity of defeating measured/secure boot and attestation, with many arguing the risk is overstated for typical servers but real for bare-metal hosting and attestation-dependent workflows. **Sentiment:** 10% positive · 50% mixed · 40% skeptical **The case for** - Some note it only matters for niche PXE-boot setups, so most deployed servers aren't actually exposed. - A few point out defenders could at least detect anomalous ICMP traffic as an early warning sign. **The pushback** - Many argue an attacker with enough network access to send the crafted ICMP packet could likely subvert PXE boot some other way anyway, making the exploit less novel than claimed. - Several stress this breaks measured/secure boot and remote attestation, which is a serious consequence beyond just swapping the booted OS. - Some see it as a de facto BitLocker/TPM-based disk encryption bypass when no passphrase is used. - Multiple commenters criticize the CVSS 9.5 score as inflated or meaningless given CVSS scoring debates generally. - Several blame the bloated, million-line UEFI/EDK2 codebase as structurally prone to this kind of bug. - Some call the framing (e.g. 'affects most servers on Earth') clickbait or fearmongering given the narrow attack surface in practice. - Concerns raised about coordinated disclosure failing, since AMI's pull request leaked details before the planned advisory. **By community** - hackernews (mixed): Debate splits between those downplaying the practical attack surface and those alarmed by the attestation/secure-boot implications, with side threads on CVSS inflation and UEFI codebase bloat. **Hottest debate:** Whether this is a serious, broadly exploitable threat or a narrow, overstated one given the PXE-boot and network-access prerequisites. **Open questions** - How many real-world firmware builds actually compile in the vulnerable ICMP component? - How quickly and completely can patches realistically be rolled out across many vendors and millions of devices? - Does this meaningfully affect personal computers/phones, or is it essentially server/bare-metal-hosting specific? **Highlights** > Yeah I'm actually not terribly worried about the server scenario, but having a way to get code exec in the firmware lets you defeat measured boot, which means this is a Bitlocker bypass in the default config. > — [mjg59 on hackernews · 1 comments](https://news.ycombinator.com/item?id=50269775) > Yeah but that just lets them replace the OS that gets booted. This gives the attacker access at the UEFI level and above -- they can use it to produce false attestations. > — [octoberfranklin on hackernews · 1 comments](https://news.ycombinator.com/item?id=50268350) > Send an ICMP packet while it is booting from PXE. So you need to 1) Have a server which boots from PXE, 2) Have it do PXE on the same interface used for connections to the internet, 3) Lack a firewall filtering out unexpected or malformed ICMP packages(?), and 4) Do it at the exact moment the physical server is rebooting. Seems like it is basically zero attack surface when it comes to remotely compromising a server. A client device, on the other hand, would be way easier to exploit, and being able to fool Secure Boot would be very interesting to people trying to bypass DRM or cheat in video games, and of course Evil Maids and security agencies. > — [crote on hackernews](https://news.ycombinator.com/item?id=50271445) > Another breathless fearmongering. "threatens"? No, I don't think network booting is even all that common outside of extremely niche scenarios. Instead, it applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources. Who is PXE-booting over the open Internet!? > — [userbinator on hackernews · 4 comments](https://news.ycombinator.com/item?id=50269403) > We recently wrote about moving away from OVMF (~1M lines of C) to very minimal and hyperspecific firmware (300 lines of assembly)[1] for our specific confidential VM machine targets, and the idea that "popular" does not automatically mean "secure". You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable. You can instead just write hyperspecific, small codebases and throw all the security practices at it - like LLMs (economical if it's small), fuzzing, formal methods etc. [1] https://tinfoil.sh/blog/2026-10-25-less-is-more > — [FrasiertheLion on hackernews · 6 comments](https://news.ycombinator.com/item?id=50268974) **Source threads** - [hackernews](https://news.ycombinator.com/item?id=50265393) · 146 points · 82 comments ## Similar posts on daily.dev - [New U-Boot flaws could enable stealthy firmware attacks](https://daily.dev/posts/new-u-boot-flaws-could-enable-stealthy-firmware-attacks-306qqf8os) · BleepingComputer · 1 upvotes · 0 comments - [Linux Sees Patches For "Critical" Vulnerability Affecting Many Arm CPUs](https://daily.dev/posts/linux-sees-patches-for-critical-vulnerability-affecting-many-arm-cpus-i0fzrb307) · Phoronix · 4 upvotes · 0 comments - [Schneier on Security](https://daily.dev/posts/schneier-on-security-gtentyiez) · Schneier on Security · 2 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"Code-execution flaw in UEFI firmware affects most servers on planet Earth","url":"https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii"},"datePublished":"2026-10-27T23:08:39.904Z","dateModified":"2026-10-30T14:05:31.767Z","description":"A critical flaw in TianoCore EDK II, the reference codebase behind most server UEFI firmware, lets attackers execute code during boot before defenses like...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/81b6be88cbb5b7c207276584dc08ab2f?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/81b6be88cbb5b7c207276584dc08ab2f?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Ars Technica","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Ars Technica","logo":"https://media.daily.dev/image/upload/t_logo,f_auto/v1/logos/80883e0e48a34b5ebcf93777016cb3fe","url":"https://daily.dev/sources/arstechnica"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"security","timeRequired":"PT2M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Ars Technica","item":"https://daily.dev/sources/arstechnica"},{"@type":"ListItem","position":3,"name":"Code-execution flaw in UEFI firmware affects most servers on planet Earth"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/code-execution-flaw-in-uefi-firmware-affects-most-servers-on-planet-earth-x5xrpf8ii#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2026-97631 and why is it dangerous?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-97631 is a memory-corruption flaw in an ICMP component of TianoCore EDK II, the reference codebase most UEFI firmware vendors use, rated 9.5 out of 10 in severity. It lets attackers execute code during boot, before protections like Secure Boot and the TPM can establish a chain of trust. Payloads don't persist on their own but can install other code that runs on every subsequent boot. Teams tracking firmware-level threats can follow disclosures like this one on daily.dev as patches roll out."}},{"@type":"Question","name":"Which UEFI vendors are affected by the EDK II vulnerability?","acceptedAnswer":{"@type":"Answer","text":"Virtually all independent BIOS vendors (IBVs) are affected because they extensively use the TianoCore EDK II reference code, including AMI, Insyde, and Phoenix. Microsoft's hardened EDK2 fork, Project Mu, also included the code containing the vulnerable component. This makes the flaw relevant to most of the world's server vendors and data centers. Infrastructure teams vetting firmware supply chains can track EDK2 disclosures as they land on daily.dev."}},{"@type":"Question","name":"How did the EDK II vulnerability get leaked before coordinated disclosure?","acceptedAnswer":{"@type":"Answer","text":"AMI published a GitHub pull request detailing the vulnerability and including a code fix before the coordinated disclosure planned for January. Once discoverers Alex Matrosov (Anthropic) and Dan Holmes (Google) noticed, TianoCore Project members published a public advisory the following week, effectively forcing an early release of exploit-relevant details. Security teams watching how disclosure timelines slip can follow incident writeups like this on daily.dev."}}]} ```