Above this line: a lift ride under your hypervisor
Originally published on November 5, 2026 at bruno.verachten.fr
---
- ▶ 0. The lift ride (you are here)
- -1. One setting changed, two lines moved (26 November)
- -2. The roommate in the closet (12 November)
- Monday morning. No :latest for firmware (19 November)
- RISC-V. Down to the last binary (3 December)
<figure>
<img src="bruno.verachten.fr" alt="Looking straight down a square timber mine shaft, wooden frames receding floor after floor towards dark water at the bottom, a blue cable hanging down the middle" />
</figure>
Photo: Orphan Girl Mine, Butte, Montana, by James St. John, CC BY 2.0, resized.
In October 2025, Ruter, the public transport operator in Oslo, asked itself a very simple question: who actually controls our electric buses? So they took two of their own, a brand-new Yutong built in China and a three-year-old VDL from the Netherlands, and drove them into an isolated environment inside a mountain. No network. Just two buses, some probes, and a lot of rock.
What did they find? The new one was built for over-the-air updates: its manufacturer could reach each bus directly, battery and power-supply control system included, over the mobile network, through a Romanian SIM card. (A Chinese bus, in Oslo, talking through Romania. I’ve stopped trying to make the geography work.) The old one had no OTA at all.
Ruter’s conclusion, in its own publication, is that the manufacturer could, in theory, stop the bus or render it unusable. In theory. Nobody switched off a bus. But keep the shape of it in mind: closed firmware that somebody else can update.
Hold on to the bus. It comes back.
Ruter wondered who controls its buses. I asked the same thing about servers, mine and yours, to open my talk at Cloud Nord 2026 in Lille. This is the written version (the slides are online, in French, sources in the appendix).
Hands up, hands down
First question to the room: who has ever opened a BMC’s web interface? (The BMC is the little board that lets you power a server on remotely, and a lot more.) A handful of hands went up. Then: who has ever read the code running inside it?
Every hand dropped.
That’s the whole talk, in two questions. (If you only run cloud VMs and have never touched a BMC: lucky you, there’s a paragraph for you further down.)
I’m Bruno, community manager at Vates (we make XCP-ng and Xen Orchestra). At Cloud Nord 2025 I was turning Android phones into Jenkins agents; this year I came back to teach people to distrust their real, perfectly legit servers. « Je progresse dans la paranoïa, c’est l’âge. » I’m getting more paranoid. It’s my age.
I’m no firmware expert, by the way: nearly everything below, I discovered from summer 2026 onwards, so this series is me doing my homework in public.
The method: the "descenseur"
We take the lift from the VM all the way down to the silicon. On stage I called it « le descenseur » (French says ascenseur, and we were only ever going down). Think strace, except we don’t stop at the kernel. On each floor, we call an imaginary function:
audit(floor) == 0; // readable: you read it, you patch it -> green
audit(floor) == ?; // partly: an open door exists, few use it -> orange
audit(floor) == -1; // EACCES: you can't read it or remove it -> red
EACCES is what Linux hands you when it refuses you a file. At Cloud Nord the room voted with raised hands before each verdict. You can vote in your head. I won’t count (promise).
Somewhere on the way down there’s a line. Above it, you read the code. Below it, you take the vendor’s word for it. That’s the line in the title, and on every floor we’ll check which side of it we’re standing on (spoiler: it doesn’t improve).
One more map, because other people’s writing uses it. x86 counts rings from 3 (apps) down to 0 (kernel), and the hypervisor gets "ring -1", which is a figure of speech, not a piece of hardware. Libreboot calls the ME and the PSP (floor -3, patience) "ring -2" or "ring -3". Not a ring at all: another processor, reaching the centre. Rings aren’t floors, but they point the same way. Down. Audit your hypervisor all you like, you still haven’t audited the bottom.
Floor 0: everything’s fine
Ground floor: your VMs, and the hypervisor underneath. Xen, KVM: GPL, public code. You read it, you patch it, you send the patch upstream. audit("hypervisor") == 0. Green.
Everything’s fine… until you power the machine on.
Even at home. On stage I’d promised to put my own product in orange, so here goes: the hypervisor’s code is green, but booting it is another story. Secure Boot is the bouncer at the firmware’s door ("Sneakers? You’re not getting in."). Turn it on, and an XCP-ng host won’t boot, installer or installed. I hit it in my lab, on an OptiPlex. First I blamed the USB stick. Then the ISO. Then the IP KVM. Best part? The ISO really was corrupt as well. Two problems, one symptom. With a clean image and Secure Boot on:
All bootable devices failed Secure Boot verification.
Not a bug.
So what is it, then? Partly signatures: XCP-ng’s boot chain isn’t signed with a key your firmware trusts out of the box. The 8.1 release notes say Secure Boot relies on proprietary packages, the forum says it would need a valid Microsoft certificate, and the request has been open since 2019. Guests have had Secure Boot since 8.2.1 (same name, different thing, just to keep you on your toes). And enrolling your own keys? Then you sign the whole chain, every update included.
« Le Secure Boot ne vérifie pas que le code est ouvert. Il vérifie qui l’a signé. » Secure Boot doesn’t check that the code is open. It checks who signed it.
Who holds the keys. Sounds a bit like the bus, doesn’t it?
Floor -1: open upstream, closed at your place
Knock knock. On floor -1, the firmware that boots the machine answers. And your vendor’s UEFI? A closed binary. On 22 October 2026, TianoCore published GHSA-99cj-7hg9-mp4m, a critical pre-boot flaw in the PXE driver of EDK2, the reference UEFI implementation. The fix had been on master since 15 October. In your server, though, it lands when your vendor ships a new binary. Not before. (Dan Goodin at Ars Technica explains why that reaches so many servers: most UEFI suppliers build on EDK2.)
« Ouvert en amont, fermé chez vous. » Open upstream, closed at your place.
Why orange, then, and not red? Because doors exist. coreboot does the bare minimum of hardware bring-up, then hands over to a payload such as TianoCore, which is EDK2, compiled by you this time. Libreboot is to coreboot what Debian is to Linux: a distribution of it, the purist one, mostly on older machines (hello, ThinkPad X200 from 2008). On recent Intel, memory init goes through Intel’s FSP blob, and the Libreboot FAQ says replacing it would take the world’s best developer years. (Not me, then.) Dasharo, also coreboot-based, ships on laptops and on a handful of server boards with paid support.
Dasharo can even stop the Intel ME after boot, with the HAP bit, a flag that tells the ME to halt once the hardware is up. Stopped. Not removed. We’ll meet it again two floors down.
<figure>
<img src="bruno.verachten.fr" alt="A blue and grey firmware setup screen titled Intel Management Engine Options, with the Intel ME mode drop-down open on three choices: Enabled, Disabled (Soft) and Disabled (HAP)" />
<figcaption>Dasharo’s setup menu offers three Intel ME modes. Screenshot: 3mdeb, from the <a href="github.com/Dasharo/docs/blob/31300a0/docs/images/…">Dasharo documentation</a>, <a href="apache.org">Apache-2.0</a>.</figcaption>
</figure>
Floor -2: the roommate in the closet
Who has ever updated their BMC’s firmware? Who knows which OS runs inside it? (Before this talk, not me. Not a clue.)
Remember the Romanian SIM? Your server has one too: the BMC. Power, console, ISOs, its own OS and its own network, even while the server is off. A roommate living in your closet, with the house keys. The keys come with the server, though not always all of them: on one machine I was lent, mounting an ISO needed a paid licence. That same machine, with 1.5 TB of RAM, spent more than four minutes in POST (the power-on self-test, the machine checking itself) before even looking for its devices. Four minutes of code you can’t read, and your OS isn’t even born yet. Long enough to wonder what it’s doing in there.
Orange anyway, thanks to OpenBMC, an open source Linux distribution for BMCs. Facebook started it in 2014, and Facebook’s own 2015 engineering post says Facebook runs it in production. My servers? None of them. So I booted the public image for Bletchley, a Meta board, in QEMU on my laptop. That one gets its own post.
Floor -3: knock knock, who’s there?
Guessing game. A reasonable one-socket server: how many processors inside? The invoice says one. The invoice is an optimist. There’s the CPU you paid for, the BMC, your SSD’s controller, and the one that answers when you knock on floor -3.
Yes, a fourth one. And it was there before you.
On Intel, it’s the Management Engine: a separate little computer in the chipset since 2006. It has handled part of hardware init since Nehalem, its firmware is signed by Intel, and on recent chips it runs a 486-derived core running MINIX (my favourite piece of trivia in the whole talk). Without valid signed firmware, the machine shuts down after 30 minutes, according to people who took it apart.
Half an hour of freedom.
And AMD? No favourites here. The PSP is an Arm core on the same die as your x86 cores, and per the coreboot and Libreboot docs its firmware must be AMD-signed, or your x86 cores never start.
Not thirty minutes: zero.
Your processor has two brains, and you only hold the keys to one.
This isn’t Intel bashing or AMD bashing (I just did both, to be fair), it’s architecture. And these locks exist to protect you: anti-rollback, for one, stops anyone dragging you back to an older, vulnerable firmware. They just don’t hand you the key. (AMD friends reading this: « cœur sur vous », much love. I meant it on stage too.)
So I looked at a real one: an AMD EPYC Genoa belonging to a partner (not the loaner from floor -2), booted from a live key. The kernel reported its PSP fused, debug locked and anti-rollback on, all of it protective, and Secure Boot had no keys enrolled at all.
No TPM fitted on that box, so fwupd’s HSI scale (built with PCs in mind) stopped it at HSI:0, on step one. Ouch. Count BIOS, BMC, network cards, disk controller and SSDs, and that’s at least ten closed firmwares. « Je ne jette la pierre à personne. » I’m not throwing stones at anyone. Yours probably looks much the same.
To be fair, I ran the same checks on my own Intel NUC: ME version 18, manufacturing mode locked, and Boot Guard fused to the board vendor’s key, so only that vendor’s firmware boots (on my NUC, yes, that one stung). It has a TPM (the small chip that keeps track of what booted), and fwupd gives it HSI:3, a better score earned partly because of those vendor locks.
« Plus sûr, oui. Plus ouvert, non. » Safer, yes. More open, no.
audit("ME/PSP") == -1. Red. Can’t read it, can’t remove it.
<div class="tip">
Two minutes, and it tells you a lot: fwupdmgr security. The HSI scale was designed for laptops and desktops, so read a server’s score with that in mind.
</div>
"But Bruno, there’s me_cleaner!" (Nobody said it. I felt it.) me_cleaner strips much of the ME firmware, and the HAP bit stops the ME once the hardware is up, but by then it has already done its job. Never run it on a machine you need. For the PSP, says Libreboot, there’s no equivalent.
In the cloud, this floor is still under your cluster (told you there was a paragraph for you). On AMD, a confidential VM’s SEV-SNP attestation report comes from firmware running in, you guessed it, the PSP. You trust the host less and the chip maker more.
And here’s the part I genuinely like: with openSIL, AMD publishes its silicon initialisation code as open source, and coreboot boots recent EPYC chips with it on a few boards. A real step, and AMD is the one taking it. The PSP itself still runs AMD-signed firmware, so openSIL opens the initialisation, not the PSP. But a door that wasn’t there is now ajar: not orange yet, but the first crack in the red.
Floor -4: the bottom of the cave
Knock knock… nothing. On x86 the instruction set is proprietary and core designs are secret. Nobody expected to read a Xeon’s RTL (the hardware description the chip is built from) this morning. (Good. I didn’t bring one.) audit("ISA") == -1. Red.
Not a law of physics, though: OpenPOWER is one open ISA, and on Raptor’s machines the platform firmware sources are published and auditable. There’s another open ISA, and I’m keeping it warm for later.
Express ride back up
Here’s the map you voted on: green at the top, orange in the middle, red at the bottom. So is open source pointless? (Deliberately provocative.)
No.
« L’open source, c’est une direction. Pas une case à cocher. » Open source is a direction. Not a checkbox.
I skipped a few floors on the way down (my talk, my rules). Your SSD has its own processor and closed firmware, and in 2019 Radboud University researchers showed at IEEE S&P that several self-encrypting SSDs gave up their data without the user’s password.
In October 2026, an intermediate certificate of the certificate authority eMudhra turned out to have a private key equal to 4. Yes, four. Mozilla’s bug 2083449 tracks eight weak intermediates; eMudhra attributes it to a script error. It was spotted because the public half was public (I checked it myself, I couldn’t resist). A 4 inside SSD firmware? Nobody would ever see it.
The line moves both ways. After 2015 FCC rules on 5 GHz radios, TP-Link locked out third-party firmware entirely. The 2016 consent decree brought a \$200,000 penalty (for its own firmware exceeding power limits, not for open source) and a commitment to work with the open source community and chip makers on reopening the door. On an Archer A7 sold in the US, OpenWrt installs from TP-Link’s own update page. Are the two connected? I can’t prove it.
Monday morning: make the red visible
I won’t ask you to flash coreboot onto production. Your CISO would find me, and rightly so.
« On ne rend pas le rouge vert, on le rend visible. » We don’t turn red into green. We make it visible.
Five verbs. Inventory: list every firmware you have, and "no TPM" is a line in that list too. Measure: Secure Boot, our bouncer from floor 0, checks who signed each step; measured boot is the CCTV camera, recording each step in the TPM. Attest: have something else compare those recordings with what you expect, because a camera nobody watches is decoration. Pin: friends don’t let friends use latest, firmware included. Isolate: the BMC gets its own network, and nobody else’s. Red stays red, but you go from "I trust it" to "I know when it changes". That’s not nothing. Want to watch one setting move two lines in the TPM log? That’s the floor -1 post. The rest of Monday morning gets its own.
The line moves
What if, somewhere, floor -3 opened when you knocked?
Same lift, different building: RISC-V. On floor -3, where x86 keeps its ME, RISC-V puts OpenSBI, the open source reference firmware running at the machine’s most privileged level: audit("OpenSBI") == 0. On floor -4, the ISA is an open specification. The core? It depends. SiFive sells the P550 as licensed IP; CVA6 publishes its RTL, though trying it on an FPGA needs a closed vendor tool. An open ISA isn’t an open core (a confusion I used to make myself, so no judgement here).
On my first Banana Pi BPI-F3, the bootloader is GPL source, at the exact commit my distribution says it built. OpenSBI is open source too, though built from a contributor’s tree. Lovely. But a second, 32-bit core runs esos.elf, a prebuilt binary my distribution copies in, even though SpacemiT publishes its source. My most open board, and still a binary nobody here rebuilt. It gets its own post.
The SpacemiT K3 announces everything a hypervisor needs: H for the CPU, AIA for interrupts, an IOMMU for devices. 16 cores!
Well… 8.
Only eight of the sixteen have the H extension. Julien Aubé ran the commands on his board for me, and on that one board AIA is there while Linux sees no IOMMU.
Still, RISC-V servers are starting to look like servers.
<figure>
<img src="bruno.verachten.fr" alt="An open rack server on a trade-show stand, lid removed, rows of heatsinks and drive caddies visible, a product sheet resting on top." />
<figcaption>A rack server with its lid off, on a stand at the RVI Summit China 2026. Photo: <a href="linkedin.com">Ludovic Henry</a>, used with his permission.</figcaption>
</figure>
No board? Scaleway rents bare-metal RISC-V, the Elastic Metal EM-RV1, launched in February 2024. According to Scaleway, it boots U-Boot, OpenSBI, then Linux, on top of "minimal proprietary code". RISE’s GitHub runners run on these machines by default, and most of my riscv64 porting goes through them.
The bus comes back
Told you. After Oslo, Denmark’s Movia had EY audit electric buses from several manufacturers, and found no basis to consider Chinese buses less cybersecure than the others. And the manufacturer that could least demonstrate its cybersecurity management? The Dutch one, VDL: the maker of Oslo’s bus without OTA.
EY gives both halves: without OTA, nobody takes over the fleet remotely, and nobody patches, monitors or audits it either. Not having OTA doesn’t make you auditable.
« Injoignable, ce n’est pas vérifiable. » Unreachable isn’t verifiable.
The risk was never the bus’s passport. It’s closed firmware that someone else writes and signs, at the heart of a critical system. And you have several in every server.
Takeaways
- Know which floor you’re on. For each layer, ask whether you can read it, patch it, or only believe it.
- Spend two minutes on fwupdmgr security. It opens nothing, but it tells you where you stand.
- Treat firmware like container images. Inventory it, pin it, never :latest it.
- Put the BMC in its own cave. Separate management network, restricted access, default accounts changed.
- Watch the bottom of the stack. openSIL and RISC-V show the line can move down.
Thanks to the Cloud Nord crew for having me back, to Julien Aubé for running commands on his K3 for my slides, and to Ludovic Henry for the photo. The video (in French) and the slides are online. Next in the series: floor -2, where I boot a BMC on my laptop.
audit("this post") == 0; // sources in the slides' appendix
A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver
---
published: true
tags: security, firmware, uefi, infosec
description: "A 16-year-old buffer overflow in TianoCore EDK II's PXE driver (CVE-2026-97631, 9.5) runs code in ring 0 before Secure Boot and TPM load. The fix diff, the embargo AMI broke a month early, the fleet audit - and the QEMU harness I built to reproduce it, documented honestly including where it stopped."
series: black box
---
> There is a buffer overflow in the network-boot driver of TianoCore EDK II - the open-source UEFI reference implementation that virtually every server BIOS on the planet derives from - and it has been there for sixteen years. CVE-2026-97631, rated 9.5: during a PXE network boot, an oversized ICMP error message writes attacker-controlled bytes past a 504-byte struct, corrupting firmware memory - code execution in ring 0, before Secure Boot and TPM even load. Found by Alex Matrosov and Dan Holmes. And the disclosure itself broke: AMI pushed the fix to a public repo a month ahead of the coordinated date, forcing an early advisory. The fifth disclosure-pipeline failure of the month, on the blog that has been counting them.
This post: the mechanism from the actual fix diff, what the bug does and doesn't give an attacker, the embargo story, a fleet audit you can run in one line - and the headless QEMU harness I built to reproduce it (now on GitHub: slabbdev/uefi-pxe-cve-2026-97631), documented to the exact point where my hardware said no.
The bug, read from the fix
The vulnerable code lives in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c - the handler that processes ICMP error messages arriving while the firmware network-boots. Here is the actual buggy loop, from the repo, before the patch (PR #13200, opened Sept 28):
CopiedLen = 0;
IcmpError = (UINT8 *)&Mode->IcmpError; // EFI_PXE_BASE_CODE_ICMP_ERROR = 504 bytes
for (Index = 0; Index < RxData->FragmentCount; Index++) {
CopiedLen += RxData->FragmentTable[Index].FragmentLength; // (1)
if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) {
CopyMem (IcmpError, ...FragmentBuffer, ...FragmentLength); // (2)
} else {
CopyMem (IcmpError, ...); // the else branch copied too - truncated in the diff, same object
}
}
Two textbook flaws stacked: the bound is checked against the cumulative length after adding the fragment (1), and a copy happens in both branches (2). Craft an ICMP error whose quoted payload exceeds 504 bytes - trivially, since the ICMP error body is just "original datagram" bytes you control - and the writes run past the end of the IcmpError struct inside the firmware's DXE phase. The fix introduces a FragmentLen variable and copies strictly bounded amounts per fragment.
What that buys an attacker, precisely: memory corruption in ring 0, in firmware, during the boot window - before the OS, before Secure Boot's runtime protections matter, before TPM-measured boot captures anything sane. The researchers note it can bypass remote attestation and break disk encryption assumptions. What it does NOT buy: this is not an internet-facing RCE. You need a position on the local network, a target that actually does PXE network boot (datacenter servers, fat clients - not your laptop booting from disk), and per-model tuning of the exploit. It is an insider/nation-state/ransomware escalation tool, not a worm.
The disclosure that broke
The coordinated embargo targeted January. Then AMI - an IBV whose BIOS AMI, Insyde, Phoenix and OEMs ship - published the fix pull request on September 28, a month early, blowing the timeline and forcing the early advisory. The PR is still there, timestamped, from an AMI engineer. Ars asked AMD, Phoenix, AMI, Microsoft and Amazon for comment; none answered. Intel and Arm claim their products aren't directly affected, though both borrow from EDK II lineage.
The month's disclosure-failure scoreboard, for those keeping count: LiteLLM reposted with scrambled dates, ZDI's private queue leaked to the public LKML, eMudhra blamed "amplification", a measured PHP advisory got dressed as BREAKING - and now an IBV broke its own embargo. Five failures, five different mechanisms, one lesson: the pipeline around the vulnerability is the vulnerability.
Audit your fleet - one line
PXE is on by default on most server firmwares. The audit:
# any network-boot entries in the firmware boot order?
efibootmgr -v | grep -iE 'pxe|network|ip4|ip6'
# BMC angle: many boards can enable network boot remotely - check yours
ipmitool lan print 1 # if the BMC is reachable, PXE policy is BMC policy
If nothing boots from the network and nothing can turn it on remotely, this CVE is not your fire today - but the patch wave is coming through your BIOS vendors over the next months, and unlike Secure Boot key rollovers, this one is a normal firmware update. Add "EDK II PXE fix" to the checklist of the next BIOS refresh cycle; disable network boot entirely on machines that never PXE.
The harness - what I built, what worked, what didn't
I tried to reproduce the crash locally, headless, on the exact vulnerable code. The harness (three small files, in the repo) is genuinely reusable for any OVMF boot-testing:
- bridge.py - a Python DHCP server + attack tool on the QEMU wire: binds the QEMU socket UDP netdev pair, answers DHCP DISCOVER/REQUEST, waits for the TFTP read request, then fires 6× ICMP type-3 code-1 errors quoting a 1,200-byte fake datagram into a struct with room for 504. Pure stdlib, no scapy.
- router.py - a screen-state router: classifies OVMF's screen from screendump pixel statistics (black = UEFI Shell, blue = front page/Boot Manager), then drives the headless firmware through the monitor (sendkey) into the Boot Manager and onto UEFI PXE IPv4 - no display, no VNC.
- QEMU config: OVMF pflash, virtio-net on a UDP socket netdev (no multicast flakiness), filter-dump pcap tap on the wire, -d cpu_reset to catch firmware triple-faults.
What worked: everything up to the PXE boot attempt, reproducibly. The firmware boots, the router navigates the Boot Manager blindly and lands on the PXE screen (Client MAC banner and all), the wire tap and reset counters are live, the DHCP/attack engine is armed.
What didn't: the homebrew QEMU-bundled OVMF builds (IA32 and X64, q35 and i440fx) display the PXE banner and then transmit zero packets - the DHCP Discover never leaves the firmware under TCG emulation, so the ICMP trigger never arrives at the vulnerable handler. Reproducing further needs a serial-debug OVMF build (or a real machine with PXE enabled, which I won't point an overflow at outside a lab). The harness is documented to this exact boundary on purpose: it's the difference between "I ran it" and "I read it", and today this post is honest about being the second with the doors open for the first.
TL;DR
Sixteen-year-old overflow in the UEFI network-boot driver, ring 0 before your defenses load, local-network attack on PXE-booting fleets - patched in EDK II and rolling out through every BIOS vendor now. Check your boot order (efibootmgr), disable network boot where you don't need it, and add the fix to your firmware refresh checklist. The disclosure broke a month early, which is somehow the least surprising sentence of October.
Sources: Ars Technica - Code-execution flaw in UEFI firmware · EDK II fix PR #13200 · EDK II fix PR #13302 · Harness repo: slabbdev/uefi-pxe-cve-2026-97631
5 reactions
Mentions
EDK2 PXE RCE: one ICMP error before the operating system exists EDK2 PXE RCE: one ICMP error before the operating system exists CVE-2026-97631 sits below the controls most security teams monitor. The affected code is the EDK II network stack used during PXE boot. A machine must be network-booting over IPv4 or IPv6, and an attacker must be able to deliver crafted ICMP error messages to it. Under those conditions, the advisory describes memory corruption in the DXE phase that can lead to arbitrary code execution before the operating system loads. That timing is the main lesson. Endpoint agents, EDR, host firewalls, and operating-system logging are not running yet. Secure Boot may verify the firmware and boot components, but it does not make a running firmware network parser correct. Measured boot may provide evidence about the boot chain, but it does not necessarily prevent an attacker from abusing a vulnerable PXE path during the boot itself. The advisory rates the issue critical. AMD's bulletin says an unauthenticated attacker who can deliver ICMP error messages can corrupt DXE memory and execute arbitrary code before Secure Boot or measured boot has verified or measured any OS component. EDK II is used in physical firmware and in virtual machine firmware, so the inventory should not stop at laptops. The network boot path PXE uses DHCP and TFTP to locate and download boot images. The firmware network stack also processes ICMP responses generated along the route. An attacker on the same network segment, a compromised router, or another system able to inject packets into that path may be in scope. Internet reachability is not required for every deployment, but a poorly segmented provisioning network can be exposed to tenants, guests, contractors, or compromised workloads. The flaw is not evidence that every device with UEFI is exploitable. The boot mode, network stack configuration, firmware build, and attacker position all matter. The useful operational question is which systems still boot from the network and which networks can deliver ICMP to them during that window. Inventory firmware and boot policy Start with the hypervisors. vSphere, KVM, Proxmox, OpenStack, and cloud platforms may ship EDK2-derived firmware images. Record the firmware package version as well as the guest operating system version. A VM template with an old firmware package can keep reproducing the same exposure long after the base image was updated. Then inventory physical servers and workstations that use PXE or HTTP boot. Check whether network boot is enabled permanently, enabled only for a deployment task, or selected through a one-time boot menu. Servers in a provisioning VLAN deserve special attention because they often sit in a state where network boot remains enabled. Map the networks that can send DHCP, TFTP, and ICMP to those systems. Guest Wi-Fi, a shared lab VLAN, or a flat management network can break the assumption that provisioning traffic is isolated. Look for both direct paths and paths through a router that permits ICMP errors. Finally, record the firmware update owner. BIOS and BMC firmware often falls between operating-system patching and hardware support. A server can show a current OS and still run an old firmware image with no recorded change history. Reduce the window The most direct control is to apply a fixed EDK2-derived firmware release when the hardware vendor ships one. Track the upstream advisory and the vendor's response because an EDK2 source fix does not automatically update an OEM firmware image. Test the update on the same model and boot configuration used in production. Where the firmware cannot be updated immediately, reduce network-boot exposure. Disable PXE on systems that do not need it. Turn it off after provisioning or when the deployment task finishes. Isolate provisioning networks from guest, tenant, and general-purpose segments. Restrict which systems can act as DHCP and TFTP servers, and review router ACLs that allow ICMP from untrusted networks into the boot path. Some administrators may consider filtering fragmented ICMP packets. The AMD bulletin recommends dropping IPv4 ICMP packets with the More Fragments flag or a non-zero fragment offset. That may be a useful containment measure during a PXE window, but it is not a substitute for firmware remediation and it must be tested against the operating network's ICMP requirements. Verify the fix beyond a version string After firmware updates, verify the version reported by the hardware management interface and the hypervisor firmware package. Then run a controlled boot test in an isolated lab. Confirm that the expected boot mode works, that secure boot policy remains intact, and that the firmware no longer accepts the malformed ICMP sequence associated with the vulnerability. Review boot measurements and firmware event logs for unexpected changes. Measured boot can help identify which components were loaded, but teams need to know the expected values before an incident. A clean measurement record is only useful if it is compared with a trusted baseline. The deeper control is to shorten the period when network boot is possible. A firmware flaw in a rarely used boot path is still dangerous if hundreds of servers sit with PXE enabled for months. Inventory, segmentation, and a one-time boot policy make the attack window smaller even before the next firmware release arrives. References - TianoCore EDK2 security advisory GHSA-99cj-7hg9-mp4m - AMD security bulletin AMD-SB-7081 - Red Hat CVE-2026-97631
Above this line: a lift ride under your hypervisor Originally published on November 5, 2026 at bruno.verachten.fr --- - ▶ 0. The lift ride (you are here) - -1. One setting changed, two lines moved (26 November) - -2. The roommate in the closet (12 November) - Monday morning. No :latest for firmware (19 November) - RISC-V. Down to the last binary (3 December) <figure> <img src="bruno.verachten.fr" alt="Looking straight down a square timber mine shaft, wooden frames receding floor after floor towards dark water at the bottom, a blue cable hanging down the middle" /> </figure> Photo: Orphan Girl Mine, Butte, Montana, by James St. John, CC BY 2.0, resized. In October 2025, Ruter, the public transport operator in Oslo, asked itself a very simple question: who actually controls our electric buses? So they took two of their own, a brand-new Yutong built in China and a three-year-old VDL from the Netherlands, and drove them into an isolated environment inside a mountain. No network. Just two buses, some probes, and a lot of rock. What did they find? The new one was built for over-the-air updates: its manufacturer could reach each bus directly, battery and power-supply control system included, over the mobile network, through a Romanian SIM card. (A Chinese bus, in Oslo, talking through Romania. I’ve stopped trying to make the geography work.) The old one had no OTA at all. Ruter’s conclusion, in its own publication, is that the manufacturer could, in theory, stop the bus or render it unusable. In theory. Nobody switched off a bus. But keep the shape of it in mind: closed firmware that somebody else can update. Hold on to the bus. It comes back. Ruter wondered who controls its buses. I asked the same thing about servers, mine and yours, to open my talk at Cloud Nord 2026 in Lille. This is the written version (the slides are online, in French, sources in the appendix). Hands up, hands down First question to the room: who has ever opened a BMC’s web interface? (The BMC is the little board that lets you power a server on remotely, and a lot more.) A handful of hands went up. Then: who has ever read the code running inside it? Every hand dropped. That’s the whole talk, in two questions. (If you only run cloud VMs and have never touched a BMC: lucky you, there’s a paragraph for you further down.) I’m Bruno, community manager at Vates (we make XCP-ng and Xen Orchestra). At Cloud Nord 2025 I was turning Android phones into Jenkins agents; this year I came back to teach people to distrust their real, perfectly legit servers. « Je progresse dans la paranoïa, c’est l’âge. » I’m getting more paranoid. It’s my age. I’m no firmware expert, by the way: nearly everything below, I discovered from summer 2026 onwards, so this series is me doing my homework in public. The method: the "descenseur" We take the lift from the VM all the way down to the silicon. On stage I called it « le descenseur » (French says ascenseur, and we were only ever going down). Think strace, except we don’t stop at the kernel. On each floor, we call an imaginary function: audit(floor) == 0; // readable: you read it, you patch it -> green audit(floor) == ?; // partly: an open door exists, few use it -> orange audit(floor) == -1; // EACCES: you can't read it or remove it -> red EACCES is what Linux hands you when it refuses you a file. At Cloud Nord the room voted with raised hands before each verdict. You can vote in your head. I won’t count (promise). Somewhere on the way down there’s a line. Above it, you read the code. Below it, you take the vendor’s word for it. That’s the line in the title, and on every floor we’ll check which side of it we’re standing on (spoiler: it doesn’t improve). One more map, because other people’s writing uses it. x86 counts rings from 3 (apps) down to 0 (kernel), and the hypervisor gets "ring -1", which is a figure of speech, not a piece of hardware. Libreboot calls the ME and the PSP (floor -3, patience) "ring -2" or "ring -3". Not a ring at all: another processor, reaching the centre. Rings aren’t floors, but they point the same way. Down. Audit your hypervisor all you like, you still haven’t audited the bottom. Floor 0: everything’s fine Ground floor: your VMs, and the hypervisor underneath. Xen, KVM: GPL, public code. You read it, you patch it, you send the patch upstream. audit("hypervisor") == 0. Green. Everything’s fine… until you power the machine on. Even at home. On stage I’d promised to put my own product in orange, so here goes: the hypervisor’s code is green, but booting it is another story. Secure Boot is the bouncer at the firmware’s door ("Sneakers? You’re not getting in."). Turn it on, and an XCP-ng host won’t boot, installer or installed. I hit it in my lab, on an OptiPlex. First I blamed the USB stick. Then the ISO. Then the IP KVM. Best part? The ISO really was corrupt as well. Two problems, one symptom. With a clean image and Secure Boot on: All bootable devices failed Secure Boot verification. Not a bug. So what is it, then? Partly signatures: XCP-ng’s boot chain isn’t signed with a key your firmware trusts out of the box. The 8.1 release notes say Secure Boot relies on proprietary packages, the forum says it would need a valid Microsoft certificate, and the request has been open since 2019. Guests have had Secure Boot since 8.2.1 (same name, different thing, just to keep you on your toes). And enrolling your own keys? Then you sign the whole chain, every update included. « Le Secure Boot ne vérifie pas que le code est ouvert. Il vérifie qui l’a signé. » Secure Boot doesn’t check that the code is open. It checks who signed it. Who holds the keys. Sounds a bit like the bus, doesn’t it? Floor -1: open upstream, closed at your place Knock knock. On floor -1, the firmware that boots the machine answers. And your vendor’s UEFI? A closed binary. On 22 October 2026, TianoCore published GHSA-99cj-7hg9-mp4m, a critical pre-boot flaw in the PXE driver of EDK2, the reference UEFI implementation. The fix had been on master since 15 October. In your server, though, it lands when your vendor ships a new binary. Not before. (Dan Goodin at Ars Technica explains why that reaches so many servers: most UEFI suppliers build on EDK2.) « Ouvert en amont, fermé chez vous. » Open upstream, closed at your place. Why orange, then, and not red? Because doors exist. coreboot does the bare minimum of hardware bring-up, then hands over to a payload such as TianoCore, which is EDK2, compiled by you this time. Libreboot is to coreboot what Debian is to Linux: a distribution of it, the purist one, mostly on older machines (hello, ThinkPad X200 from 2008). On recent Intel, memory init goes through Intel’s FSP blob, and the Libreboot FAQ says replacing it would take the world’s best developer years. (Not me, then.) Dasharo, also coreboot-based, ships on laptops and on a handful of server boards with paid support. Dasharo can even stop the Intel ME after boot, with the HAP bit, a flag that tells the ME to halt once the hardware is up. Stopped. Not removed. We’ll meet it again two floors down. <figure> <img src="bruno.verachten.fr" alt="A blue and grey firmware setup screen titled Intel Management Engine Options, with the Intel ME mode drop-down open on three choices: Enabled, Disabled (Soft) and Disabled (HAP)" /> <figcaption>Dasharo’s setup menu offers three Intel ME modes. Screenshot: 3mdeb, from the <a href="github.com/Dasharo/docs/blob/31300a0/docs/images/…">Dasharo documentation</a>, <a href="apache.org">Apache-2.0</a>.</figcaption> </figure> Floor -2: the roommate in the closet Who has ever updated their BMC’s firmware? Who knows which OS runs inside it? (Before this talk, not me. Not a clue.) Remember the Romanian SIM? Your server has one too: the BMC. Power, console, ISOs, its own OS and its own network, even while the server is off. A roommate living in your closet, with the house keys. The keys come with the server, though not always all of them: on one machine I was lent, mounting an ISO needed a paid licence. That same machine, with 1.5 TB of RAM, spent more than four minutes in POST (the power-on self-test, the machine checking itself) before even looking for its devices. Four minutes of code you can’t read, and your OS isn’t even born yet. Long enough to wonder what it’s doing in there. Orange anyway, thanks to OpenBMC, an open source Linux distribution for BMCs. Facebook started it in 2014, and Facebook’s own 2015 engineering post says Facebook runs it in production. My servers? None of them. So I booted the public image for Bletchley, a Meta board, in QEMU on my laptop. That one gets its own post. Floor -3: knock knock, who’s there? Guessing game. A reasonable one-socket server: how many processors inside? The invoice says one. The invoice is an optimist. There’s the CPU you paid for, the BMC, your SSD’s controller, and the one that answers when you knock on floor -3. Yes, a fourth one. And it was there before you. On Intel, it’s the Management Engine: a separate little computer in the chipset since 2006. It has handled part of hardware init since Nehalem, its firmware is signed by Intel, and on recent chips it runs a 486-derived core running MINIX (my favourite piece of trivia in the whole talk). Without valid signed firmware, the machine shuts down after 30 minutes, according to people who took it apart. Half an hour of freedom. And AMD? No favourites here. The PSP is an Arm core on the same die as your x86 cores, and per the coreboot and Libreboot docs its firmware must be AMD-signed, or your x86 cores never start. Not thirty minutes: zero. Your processor has two brains, and you only hold the keys to one. This isn’t Intel bashing or AMD bashing (I just did both, to be fair), it’s architecture. And these locks exist to protect you: anti-rollback, for one, stops anyone dragging you back to an older, vulnerable firmware. They just don’t hand you the key. (AMD friends reading this: « cœur sur vous », much love. I meant it on stage too.) So I looked at a real one: an AMD EPYC Genoa belonging to a partner (not the loaner from floor -2), booted from a live key. The kernel reported its PSP fused, debug locked and anti-rollback on, all of it protective, and Secure Boot had no keys enrolled at all. No TPM fitted on that box, so fwupd’s HSI scale (built with PCs in mind) stopped it at HSI:0, on step one. Ouch. Count BIOS, BMC, network cards, disk controller and SSDs, and that’s at least ten closed firmwares. « Je ne jette la pierre à personne. » I’m not throwing stones at anyone. Yours probably looks much the same. To be fair, I ran the same checks on my own Intel NUC: ME version 18, manufacturing mode locked, and Boot Guard fused to the board vendor’s key, so only that vendor’s firmware boots (on my NUC, yes, that one stung). It has a TPM (the small chip that keeps track of what booted), and fwupd gives it HSI:3, a better score earned partly because of those vendor locks. « Plus sûr, oui. Plus ouvert, non. » Safer, yes. More open, no. audit("ME/PSP") == -1. Red. Can’t read it, can’t remove it. <div class="tip"> Two minutes, and it tells you a lot: fwupdmgr security. The HSI scale was designed for laptops and desktops, so read a server’s score with that in mind. </div> "But Bruno, there’s me_cleaner!" (Nobody said it. I felt it.) me_cleaner strips much of the ME firmware, and the HAP bit stops the ME once the hardware is up, but by then it has already done its job. Never run it on a machine you need. For the PSP, says Libreboot, there’s no equivalent. In the cloud, this floor is still under your cluster (told you there was a paragraph for you). On AMD, a confidential VM’s SEV-SNP attestation report comes from firmware running in, you guessed it, the PSP. You trust the host less and the chip maker more. And here’s the part I genuinely like: with openSIL, AMD publishes its silicon initialisation code as open source, and coreboot boots recent EPYC chips with it on a few boards. A real step, and AMD is the one taking it. The PSP itself still runs AMD-signed firmware, so openSIL opens the initialisation, not the PSP. But a door that wasn’t there is now ajar: not orange yet, but the first crack in the red. Floor -4: the bottom of the cave Knock knock… nothing. On x86 the instruction set is proprietary and core designs are secret. Nobody expected to read a Xeon’s RTL (the hardware description the chip is built from) this morning. (Good. I didn’t bring one.) audit("ISA") == -1. Red. Not a law of physics, though: OpenPOWER is one open ISA, and on Raptor’s machines the platform firmware sources are published and auditable. There’s another open ISA, and I’m keeping it warm for later. Express ride back up Here’s the map you voted on: green at the top, orange in the middle, red at the bottom. So is open source pointless? (Deliberately provocative.) No. « L’open source, c’est une direction. Pas une case à cocher. » Open source is a direction. Not a checkbox. I skipped a few floors on the way down (my talk, my rules). Your SSD has its own processor and closed firmware, and in 2019 Radboud University researchers showed at IEEE S&P that several self-encrypting SSDs gave up their data without the user’s password. In October 2026, an intermediate certificate of the certificate authority eMudhra turned out to have a private key equal to 4. Yes, four. Mozilla’s bug 2083449 tracks eight weak intermediates; eMudhra attributes it to a script error. It was spotted because the public half was public (I checked it myself, I couldn’t resist). A 4 inside SSD firmware? Nobody would ever see it. The line moves both ways. After 2015 FCC rules on 5 GHz radios, TP-Link locked out third-party firmware entirely. The 2016 consent decree brought a \$200,000 penalty (for its own firmware exceeding power limits, not for open source) and a commitment to work with the open source community and chip makers on reopening the door. On an Archer A7 sold in the US, OpenWrt installs from TP-Link’s own update page. Are the two connected? I can’t prove it. Monday morning: make the red visible I won’t ask you to flash coreboot onto production. Your CISO would find me, and rightly so. « On ne rend pas le rouge vert, on le rend visible. » We don’t turn red into green. We make it visible. Five verbs. Inventory: list every firmware you have, and "no TPM" is a line in that list too. Measure: Secure Boot, our bouncer from floor 0, checks who signed each step; measured boot is the CCTV camera, recording each step in the TPM. Attest: have something else compare those recordings with what you expect, because a camera nobody watches is decoration. Pin: friends don’t let friends use latest, firmware included. Isolate: the BMC gets its own network, and nobody else’s. Red stays red, but you go from "I trust it" to "I know when it changes". That’s not nothing. Want to watch one setting move two lines in the TPM log? That’s the floor -1 post. The rest of Monday morning gets its own. The line moves What if, somewhere, floor -3 opened when you knocked? Same lift, different building: RISC-V. On floor -3, where x86 keeps its ME, RISC-V puts OpenSBI, the open source reference firmware running at the machine’s most privileged level: audit("OpenSBI") == 0. On floor -4, the ISA is an open specification. The core? It depends. SiFive sells the P550 as licensed IP; CVA6 publishes its RTL, though trying it on an FPGA needs a closed vendor tool. An open ISA isn’t an open core (a confusion I used to make myself, so no judgement here). On my first Banana Pi BPI-F3, the bootloader is GPL source, at the exact commit my distribution says it built. OpenSBI is open source too, though built from a contributor’s tree. Lovely. But a second, 32-bit core runs esos.elf, a prebuilt binary my distribution copies in, even though SpacemiT publishes its source. My most open board, and still a binary nobody here rebuilt. It gets its own post. The SpacemiT K3 announces everything a hypervisor needs: H for the CPU, AIA for interrupts, an IOMMU for devices. 16 cores! Well… 8. Only eight of the sixteen have the H extension. Julien Aubé ran the commands on his board for me, and on that one board AIA is there while Linux sees no IOMMU. Still, RISC-V servers are starting to look like servers. <figure> <img src="bruno.verachten.fr" alt="An open rack server on a trade-show stand, lid removed, rows of heatsinks and drive caddies visible, a product sheet resting on top." /> <figcaption>A rack server with its lid off, on a stand at the RVI Summit China 2026. Photo: <a href="linkedin.com">Ludovic Henry</a>, used with his permission.</figcaption> </figure> No board? Scaleway rents bare-metal RISC-V, the Elastic Metal EM-RV1, launched in February 2024. According to Scaleway, it boots U-Boot, OpenSBI, then Linux, on top of "minimal proprietary code". RISE’s GitHub runners run on these machines by default, and most of my riscv64 porting goes through them. The bus comes back Told you. After Oslo, Denmark’s Movia had EY audit electric buses from several manufacturers, and found no basis to consider Chinese buses less cybersecure than the others. And the manufacturer that could least demonstrate its cybersecurity management? The Dutch one, VDL: the maker of Oslo’s bus without OTA. EY gives both halves: without OTA, nobody takes over the fleet remotely, and nobody patches, monitors or audits it either. Not having OTA doesn’t make you auditable. « Injoignable, ce n’est pas vérifiable. » Unreachable isn’t verifiable. The risk was never the bus’s passport. It’s closed firmware that someone else writes and signs, at the heart of a critical system. And you have several in every server. Takeaways - Know which floor you’re on. For each layer, ask whether you can read it, patch it, or only believe it. - Spend two minutes on fwupdmgr security. It opens nothing, but it tells you where you stand. - Treat firmware like container images. Inventory it, pin it, never :latest it. - Put the BMC in its own cave. Separate management network, restricted access, default accounts changed. - Watch the bottom of the stack. openSIL and RISC-V show the line can move down. Thanks to the Cloud Nord crew for having me back, to Julien Aubé for running commands on his K3 for my slides, and to Ludovic Henry for the photo. The video (in French) and the slides are online. Next in the series: floor -2, where I boot a BMC on my laptop. audit("this post") == 0; // sources in the slides' appendix
733,153 TFTP services show the network-boot surface EDK2 flaws depend on 733,153 TFTP services show the network-boot surface EDK2 flaws depend on EDK II CVE-2026-97631 is a pre-boot code-execution flaw. It does not have a useful product fingerprint of its own, because EDK2-derived firmware is not an internet-facing application with a login page. A search for the firmware name would be measuring text, not deployed firmware. The adjacent observable service is TFTP. A ZoomEye query for service="tftp" returned 733,153 matches on November 4, 2026. That number sizes a network service tied to network boot, firmware distribution, device provisioning, and configuration transfer. It does not count EDK2 hosts and it does not prove that any of those hosts boot from the network. Observation | Query | Matches | Scope | |---|---:|---| | service="tftp" | 733,153 | page 1, page size 1, sub_type=all | The query completed at 2026-11-04T23:43:28Z. It was successful, so the result is a real count rather than a request error. The count is a point-in-time observation of indexed TFTP services, not an installation count for a particular TFTP product. Why TFTP is relevant PXE boot commonly relies on DHCP to direct a client to a boot server and TFTP to fetch boot files. The same service may support switch and router provisioning, IP phone configuration, camera firmware, or recovery workflows. A public TFTP service can reveal files without strong authentication, depending on how it is configured. For CVE-2026-97631, the key question is not whether an organization runs TFTP somewhere. It is whether a vulnerable firmware network stack can receive crafted ICMP errors while booting. TFTP inventory supplies a clue about the provisioning path, not a diagnosis. A practical network-boot review Use the service count to locate candidate boot infrastructure, then compare it with internal records. Identify the systems that operate DHCP options 66 and 67, the TFTP root, boot menus, and signed boot images. Confirm which clients are allowed to use them and during which maintenance windows. Inspect the network path from the client to the boot server. An attacker needs a position where crafted ICMP errors can reach the firmware stack. A flat provisioning VLAN, a guest network with routing into management, or a virtual switch shared by tenants can supply that position. Review the files exposed by TFTP. Boot images should have a documented owner, hash, and version. Remove stale firmware, recovery images, and configuration exports that are no longer required. TFTP should not become an unauthenticated file share simply because it is convenient for provisioning. Do not turn the service count into a vulnerability claim The 733,153 figure does not say how many systems use EDK2, how many are vulnerable, or how many are actively network-booting. Public TFTP services may be honeypots, lab systems, embedded devices, or intentionally exposed infrastructure. Many boot servers are also private and never appear in an internet index. The value of the count is directional. It shows that a legacy transfer protocol remains widely observable. It gives defenders a reason to review whether the same protocol is exposed in a provisioning network where firmware-level trust assumptions are weakest. Remediation priorities Apply the fixed EDK2-derived firmware from the hardware or hypervisor vendor. Disable network boot when it is not required, especially after a deployment window. Restrict DHCP and TFTP to known provisioning clients and keep those networks away from guests, tenants, and general-purpose workloads. If firmware patches are pending, filter malformed ICMP packets at the provisioning boundary and monitor for unexpected changes to boot images. Use file hashes and boot measurements to detect tampering, but remember that those checks are most useful when compared with a known-good baseline. The right conclusion is narrow. TFTP is a useful way to find network-boot infrastructure. It is not a way to identify vulnerable firmware from the outside. References - TianoCore EDK2 security advisory GHSA-99cj-7hg9-mp4m - AMD security bulletin AMD-SB-7081 - ZoomEye search platform
TianoCore disclosed CVE-2026-97631 (9.5) in EDK II's PXE boot driver. Crafted ICMP errors during network boot may hang affected systems or permit targeted pre-OS code execution. For MSPs/admins: inventory PXE-boot systems, disable network boot where unused, isolate provisioning traffic, and check for vendor firmware updates. Exposure is during PXE boot, not every startup. TianoCore lists no patched release. github.com/tianocore/edk2/security/advisories/GHS…
記事に気付いてなかったから、今後は定期的に巡回しておこうかな… github.com/tianocore/edk2/security/advisories
Pre-boot RCE in EDK II PXE driver CVE-2026-97631
🚨🇺🇸 Critical 16-year-old EDK II flaw enables code execution before Secure Boot A critical buffer overflow in TianoCore EDK II, the open-source foundation used to build much of the world’s UEFI firmware, can allow an unauthenticated attacker to run code before the operating system loads. Tracked as CVE-2026-97631, the vulnerability carries a CVSS score of 9.5 and has existed in the code since November 2010. ⠀ The flaw resides in the PXE network-boot driver, which copies incoming ICMP error messages into a fixed 504-byte buffer without properly limiting their size. ⠀ An attacker who can reach a machine while it is booting over the network can send a crafted ICMP message that: • Crashes the firmware and prevents the operating system from loading • Executes attacker-controlled code in the pre-boot environment • Runs before Secure Boot and measured-boot protections evaluate the operating system ⠀ Reliable code execution requires knowledge of the target’s firmware build. Systems that boot exclusively from local storage are not exposed through this attack path. ⠀ An upstream fix was merged into EDK II on October 15, but no stable EDK II release currently includes it. Server and motherboard vendors must integrate the patch and distribute BIOS or UEFI updates to customers. Source: github.com/tianocore/edk2/security/advisories/GHS…
Ping of death is back 💀 github.com/tianocore/edk2/security/advisories/GHS… TLDR; Ping during PXE boot can crash or get RCE because of vulnerability in UEFI. t.co
A 16-year-old buffer overflow boots before your defenses: CVE-2026-97631 in EDK II's PXE driver --- published: true tags: security, firmware, uefi, infosec description: "A 16-year-old buffer overflow in TianoCore EDK II's PXE driver (CVE-2026-97631, 9.5) runs code in ring 0 before Secure Boot and TPM load. The fix diff, the embargo AMI broke a month early, the fleet audit - and the QEMU harness I built to reproduce it, documented honestly including where it stopped." series: black box --- > There is a buffer overflow in the network-boot driver of TianoCore EDK II - the open-source UEFI reference implementation that virtually every server BIOS on the planet derives from - and it has been there for sixteen years. CVE-2026-97631, rated 9.5: during a PXE network boot, an oversized ICMP error message writes attacker-controlled bytes past a 504-byte struct, corrupting firmware memory - code execution in ring 0, before Secure Boot and TPM even load. Found by Alex Matrosov and Dan Holmes. And the disclosure itself broke: AMI pushed the fix to a public repo a month ahead of the coordinated date, forcing an early advisory. The fifth disclosure-pipeline failure of the month, on the blog that has been counting them. This post: the mechanism from the actual fix diff, what the bug does and doesn't give an attacker, the embargo story, a fleet audit you can run in one line - and the headless QEMU harness I built to reproduce it (now on GitHub: slabbdev/uefi-pxe-cve-2026-97631), documented to the exact point where my hardware said no. The bug, read from the fix The vulnerable code lives in NetworkPkg/UefiPxeBcDxe/PxeBcSupport.c - the handler that processes ICMP error messages arriving while the firmware network-boots. Here is the actual buggy loop, from the repo, before the patch (PR #13200, opened Sept 28): CopiedLen = 0; IcmpError = (UINT8 *)&Mode->IcmpError; // EFI_PXE_BASE_CODE_ICMP_ERROR = 504 bytes for (Index = 0; Index < RxData->FragmentCount; Index++) { CopiedLen += RxData->FragmentTable[Index].FragmentLength; // (1) if (CopiedLen <= sizeof (EFI_PXE_BASE_CODE_ICMP_ERROR)) { CopyMem (IcmpError, ...FragmentBuffer, ...FragmentLength); // (2) } else { CopyMem (IcmpError, ...); // the else branch copied too - truncated in the diff, same object } } Two textbook flaws stacked: the bound is checked against the cumulative length after adding the fragment (1), and a copy happens in both branches (2). Craft an ICMP error whose quoted payload exceeds 504 bytes - trivially, since the ICMP error body is just "original datagram" bytes you control - and the writes run past the end of the IcmpError struct inside the firmware's DXE phase. The fix introduces a FragmentLen variable and copies strictly bounded amounts per fragment. What that buys an attacker, precisely: memory corruption in ring 0, in firmware, during the boot window - before the OS, before Secure Boot's runtime protections matter, before TPM-measured boot captures anything sane. The researchers note it can bypass remote attestation and break disk encryption assumptions. What it does NOT buy: this is not an internet-facing RCE. You need a position on the local network, a target that actually does PXE network boot (datacenter servers, fat clients - not your laptop booting from disk), and per-model tuning of the exploit. It is an insider/nation-state/ransomware escalation tool, not a worm. The disclosure that broke The coordinated embargo targeted January. Then AMI - an IBV whose BIOS AMI, Insyde, Phoenix and OEMs ship - published the fix pull request on September 28, a month early, blowing the timeline and forcing the early advisory. The PR is still there, timestamped, from an AMI engineer. Ars asked AMD, Phoenix, AMI, Microsoft and Amazon for comment; none answered. Intel and Arm claim their products aren't directly affected, though both borrow from EDK II lineage. The month's disclosure-failure scoreboard, for those keeping count: LiteLLM reposted with scrambled dates, ZDI's private queue leaked to the public LKML, eMudhra blamed "amplification", a measured PHP advisory got dressed as BREAKING - and now an IBV broke its own embargo. Five failures, five different mechanisms, one lesson: the pipeline around the vulnerability is the vulnerability. Audit your fleet - one line PXE is on by default on most server firmwares. The audit: # any network-boot entries in the firmware boot order? efibootmgr -v | grep -iE 'pxe|network|ip4|ip6' # BMC angle: many boards can enable network boot remotely - check yours ipmitool lan print 1 # if the BMC is reachable, PXE policy is BMC policy If nothing boots from the network and nothing can turn it on remotely, this CVE is not your fire today - but the patch wave is coming through your BIOS vendors over the next months, and unlike Secure Boot key rollovers, this one is a normal firmware update. Add "EDK II PXE fix" to the checklist of the next BIOS refresh cycle; disable network boot entirely on machines that never PXE. The harness - what I built, what worked, what didn't I tried to reproduce the crash locally, headless, on the exact vulnerable code. The harness (three small files, in the repo) is genuinely reusable for any OVMF boot-testing: - bridge.py - a Python DHCP server + attack tool on the QEMU wire: binds the QEMU socket UDP netdev pair, answers DHCP DISCOVER/REQUEST, waits for the TFTP read request, then fires 6× ICMP type-3 code-1 errors quoting a 1,200-byte fake datagram into a struct with room for 504. Pure stdlib, no scapy. - router.py - a screen-state router: classifies OVMF's screen from screendump pixel statistics (black = UEFI Shell, blue = front page/Boot Manager), then drives the headless firmware through the monitor (sendkey) into the Boot Manager and onto UEFI PXE IPv4 - no display, no VNC. - QEMU config: OVMF pflash, virtio-net on a UDP socket netdev (no multicast flakiness), filter-dump pcap tap on the wire, -d cpu_reset to catch firmware triple-faults. What worked: everything up to the PXE boot attempt, reproducibly. The firmware boots, the router navigates the Boot Manager blindly and lands on the PXE screen (Client MAC banner and all), the wire tap and reset counters are live, the DHCP/attack engine is armed. What didn't: the homebrew QEMU-bundled OVMF builds (IA32 and X64, q35 and i440fx) display the PXE banner and then transmit zero packets - the DHCP Discover never leaves the firmware under TCG emulation, so the ICMP trigger never arrives at the vulnerable handler. Reproducing further needs a serial-debug OVMF build (or a real machine with PXE enabled, which I won't point an overflow at outside a lab). The harness is documented to this exact boundary on purpose: it's the difference between "I ran it" and "I read it", and today this post is honest about being the second with the doors open for the first. TL;DR Sixteen-year-old overflow in the UEFI network-boot driver, ring 0 before your defenses load, local-network attack on PXE-booting fleets - patched in EDK II and rolling out through every BIOS vendor now. Check your boot order (efibootmgr), disable network boot where you don't need it, and add the fix to your firmware refresh checklist. The disclosure broke a month early, which is somehow the least surprising sentence of October. Sources: Ars Technica - Code-execution flaw in UEFI firmware · EDK II fix PR #13200 · EDK II fix PR #13302 · Harness repo: slabbdev/uefi-pxe-cve-2026-97631
CVE-2026-97631 (UEFI PXE pre-boot RCE) It looks like Hetzner dedicated servers are affected by CVE-2026-97631 Is there a good way to protect them until Hetzner rolls out a BIOS update?