--- title: Critical EDK II flaw lets attackers run code before... description: A critical flaw in EDK II, the TianoCore codebase behind most server UEFI firmware, lets attackers run code during boot before Secure Boot activates. It's... canonical: https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Critical EDK II flaw lets attackers run code before Secure Boot, and the fix leaked early | daily.dev og:description: A critical flaw in EDK II, the TianoCore codebase behind most server UEFI firmware, lets attackers run code during boot before Secure Boot activates. It's... og:url: https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx og:image: https://api.daily.dev/og/posts/8Gu8huepX.png og:image:alt: Critical EDK II flaw lets attackers run code before Secure Boot, and the fix leaked early 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. # Critical EDK II flaw lets attackers run code before Secure Boot, and the fix leaked early **[Collections](https://daily.dev/sources/collections)** · 2 min read · 0 upvotes · 0 comments ## Summary A critical flaw in EDK II, the TianoCore codebase behind most server UEFI firmware, lets attackers run code during boot before Secure Boot activates. It's tracked as CVE-2026-97631 and rated 9.5 out of 10. The bug is a memory-corruption issue in the PXE network-boot driver, which copies ICMP error messages into a fixed 504-byte buffer without proper size checks. Exploiting it requires knowing the exact firmware build, and delivered code doesn't persist unless used to install something that runs on every boot. Researchers Alex Matrosov and Dan Holmes-Mitra planned a January 2027 disclosure, but a public code change signed off by an AMI engineer described the bug by CVE number and included the fix in September. TianoCore merged a fix on 15 October, and Microsoft's Project Mu shipped a fixed build on 26 October, though no stable EDK II release includes it yet. ## Content A memory-corruption bug in TianoCore EDK II, the open-source codebase behind most server UEFI firmware, can let an attacker run code before Secure Boot checks anything. It is tracked as CVE-2026-97631 and rated 9.5 out of 10. Details leaked well before the planned disclosure, and patched firmware will take a long time to reach servers. ## The bug The flaw is in the PXE network-boot driver, in the code that handles ICMP error messages. It copies those messages into a fixed 504-byte buffer without proper size checks, so an attacker on the network can overwrite memory. An attacker who knows the exact firmware build can turn that into code execution during boot, before defenses like Secure Boot are active. Code that runs this way doesn't persist on its own. But it can be used to install other code that runs on every boot, which is what makes it serious. ## How it leaked Researchers Alex Matrosov and Dan Holmes-Mitra had planned to disclose the flaw in January 2027. In September, though, a public code change signed off by an AMI engineer described the bug by its CVE number and included the fix. The coordinated disclosure fell apart before a patch was ready, and TianoCore later published an advisory. ## Fix status TianoCore merged a fix on 15 October. Microsoft's Project Mu shipped a fixed build on 26 October. No stable EDK II release includes the fix yet, so server operators are still waiting on BIOS or UEFI updates from their vendors. That wait will be long. EDK II sits underneath millions of devices from many vendors, and each one has to take the fix into its own firmware and ship it. I wouldn't expect this to be quick, and the early leak means the gap between public details and deployed patches is wider than anyone wanted. The bug also showed up in this week's security roundups alongside other broken embargoes, which is a pattern worth watching. ## Questions this post answers ### What is CVE-2026-97631 and why is it rated so severe? CVE-2026-97631 is a critical memory-corruption vulnerability in EDK II's PXE network-boot driver, rated 9.5 out of 10 by TianoCore. It occurs because the driver copies ICMP error messages into a fixed 504-byte buffer without proper size checks, letting an attacker execute code during boot before Secure Boot activates. Exploitation requires knowing the exact firmware build. _Teams tracking firmware CVEs like this one can follow patch timelines and vendor advisories on daily.dev._ ### Has TianoCore fixed the EDK II PXE driver vulnerability yet? Yes, TianoCore merged a fix on 15 October, and Microsoft's Project Mu shipped a fixed build on 26 October. However, no stable EDK II release includes the fix yet, meaning server operators must wait for individual hardware vendors to incorporate the patch into their own BIOS or UEFI firmware updates. _Developers waiting on downstream firmware patches can track the rollout status on daily.dev._ ### How did the EDK II CVE-2026-97631 fix leak before its planned disclosure date? Researchers Alex Matrosov and Dan Holmes-Mitra had planned to disclose the flaw in January 2027, but the timeline collapsed in September when a public code change, signed off by an AMI engineer, described the bug by its CVE number and included the fix, exposing it months early. _Security-conscious teams follow disclosure timelines and leaks like this one 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 - [UEFI bootkit infected fully patched Windows machines. Is Microsoft to blame?](https://daily.dev/posts/uefi-bootkit-infected-fully-patched-windows-machines-is-microsoft-to-blame--ppuisetuk) · Ars Technica · 0 upvotes · 0 comments - [New Linux kernel flaw allows VM escape on Intel, AMD devices](https://daily.dev/posts/new-linux-kernel-flaw-allows-vm-escape-on-intel-amd-devices-pgteqqq1i) · BleepingComputer · 2 upvotes · 0 comments - [Security briefing: October 2026](https://daily.dev/posts/security-briefing-october-2026-uxnqjrxgv) · Sysdig Blog · 0 upvotes · 0 comments --- Tags: [#security](https://daily.dev/tags/security) [View this post on daily.dev](https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx) ```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":"Critical EDK II flaw lets attackers run code before Secure Boot, and the fix leaked early","url":"https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx"},"datePublished":"2026-10-28T18:05:42.187Z","dateModified":"2026-10-30T14:05:47.234Z","description":"A critical flaw in EDK II, the TianoCore codebase behind most server UEFI firmware, lets attackers run code during boot before Secure Boot activates. It's...","image":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b4ad05d4afaa49ffd60eea76bbdf7cc5?_a=AQAEuop","thumbnailUrl":"https://media.daily.dev/image/upload/f_auto,q_auto/v1/posts/b4ad05d4afaa49ffd60eea76bbdf7cc5?_a=AQAEuop","isAccessibleForFree":true,"articleSection":"Collections","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":"Collections","logo":"https://media.daily.dev/image/upload/s--fk_6ycEi--/f_auto,q_auto/v1780996001/logos/collections?_a=BAMAMiWQ0","url":"https://daily.dev/sources/collections"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx","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":"Collections","item":"https://daily.dev/sources/collections"},{"@type":"ListItem","position":3,"name":"Critical EDK II flaw lets attackers run code before Secure Boot, and the fix leaked early"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/critical-edk-ii-flaw-lets-attackers-run-code-before-secure-boot-and-the-fix-leaked-early-8gu8huepx#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2026-97631 and why is it rated so severe?","acceptedAnswer":{"@type":"Answer","text":"CVE-2026-97631 is a critical memory-corruption vulnerability in EDK II's PXE network-boot driver, rated 9.5 out of 10 by TianoCore. It occurs because the driver copies ICMP error messages into a fixed 504-byte buffer without proper size checks, letting an attacker execute code during boot before Secure Boot activates. Exploitation requires knowing the exact firmware build. Teams tracking firmware CVEs like this one can follow patch timelines and vendor advisories on daily.dev."}},{"@type":"Question","name":"Has TianoCore fixed the EDK II PXE driver vulnerability yet?","acceptedAnswer":{"@type":"Answer","text":"Yes, TianoCore merged a fix on 15 October, and Microsoft's Project Mu shipped a fixed build on 26 October. However, no stable EDK II release includes the fix yet, meaning server operators must wait for individual hardware vendors to incorporate the patch into their own BIOS or UEFI firmware updates. Developers waiting on downstream firmware patches can track the rollout status on daily.dev."}},{"@type":"Question","name":"How did the EDK II CVE-2026-97631 fix leak before its planned disclosure date?","acceptedAnswer":{"@type":"Answer","text":"Researchers Alex Matrosov and Dan Holmes-Mitra had planned to disclose the flaw in January 2027, but the timeline collapsed in September when a public code change, signed off by an AMI engineer, described the bug by its CVE number and included the fix, exposing it months early. Security-conscious teams follow disclosure timelines and leaks like this one on daily.dev."}}]} ```