A 9.5 Firmware Flaw Runs Before Windows Starts. For an MSP, the Risk Sits on the Imaging Network.

01 What one packet does

The driver keeps the last ICMP error message it receives in a field of 504 bytes. The copy code checks the size wrongly, in both the IPv4 and IPv6 handlers. A bigger message keeps copying past the end. The advisory adds that “nothing earlier on the receive path restricts the message length” [ TianoCore advisory ] .

Two outcomes follow. The easy one is a crash: the boot hangs, so the machine never installs or recovers. The harder one is code execution. An attacker who knows the exact firmware build plants a fake event in the same packet, and the firmware runs it at its highest privilege level. The payload does not survive a reboot on its own. It does give the attacker a chance to install something that runs early in every boot after that [ Ars Technica ] .

02 Who can reach it, and when

Ars Technica’s headline says the flaw affects most servers on the planet. The code is that widespread. Microsoft’s hardened fork, Project Mu, carried the same component [ Ars Technica ] . Reach is a different question. The attacker has to send a unicast ICMP error to the machine’s address during the PXE boot. The advisory scores the attack as network-based with a precondition present: the boot has to be happening [ TianoCore advisory ] .

A web server that boots from its own disk and reboots twice a year is a poor target. The machines that matter are the ones that network boot often, or by default:

1. Laptops and desktops being imaged through Windows Deployment Services, Configuration Manager, FOG or similar tools.
2. Servers being rebuilt in a hosting or colocation estate, where bare-metal provisioning runs over PXE.
3. Machines with network boot above the disk in the boot order, so every reboot tries the network first.
4. Diskless and thin clients that always boot from the network.

The attacker also has to get a packet to that machine at that moment. On a flat office network, anyone already inside can. That includes a compromised laptop, a rogue device on a meeting-room port, or malware on the deployment server itself. On a properly separated provisioning network, the list is short.

03 Why MSPs should care first

An MSP’s job puts it inside the window. You image new starters’ laptops, rebuild machines after an incident and roll out fresh builds across a client site. Each of those jobs PXE boots a machine on a network you or your client control. For years the risk of that network was low. It handed out an operating system image and nothing else.

CVE-2026-97631 changes what a foothold on that network is worth. An attacker who already sits on a client’s network gets a way to place code beneath the operating system of every machine you rebuild there. Endpoint protection, disk encryption and Secure Boot all start after that code. The machine you rebuilt to remove an attacker could carry them straight back.

This is the second time the same driver family has done this. In January 2024, researchers disclosed PixieFail, nine flaws in EDK II’s IPv6 network boot stack [ Cyber Security News ] . The fixes for those took months to reach shipped firmware too. If your estate still runs firmware from before 2024, check it for both.

04 Where the fix is

The fix exists upstream. Pull request 13302 adds bounds checks, corrects the pointer arithmetic, truncates oversized messages and clears the buffer before each copy [ PR 13302 ] . It was merged on 15 October 2026, and the advisory followed on 22 October [ Cyber Security News ] .

The advisory still says “Not patched currently”, and for your hardware that is accurate. EDK II is reference code. AMI, Insyde and Phoenix take it into their firmware, then Dell, HPE, Lenovo and every motherboard maker take theirs into each model’s BIOS update. Each step takes weeks, and older models wait longest or never get one.

The disclosure also came early. The researchers, Alex Matrosov of Anthropic and Dan Holmes of Google, had agreed a coordinated release in January. The fix went public before then, so vendors are working to a timetable they did not plan for [ Ars Technica ] . Public fix code shows skilled attackers exactly where the bug is. Plan on a working exploit arriving before most of your fleet is patched.

05 Five changes for this week

None of these wait for a vendor. Each one shrinks the window or the list of people who can reach it.

The last item is the slow one, so start the emails today. Your clients will forward the Ars Technica headline and ask whether they are exposed. Answer with a table: each site, whether it PXE boots, how that network is separated, and the firmware status per model. That table answers the client today. Under the Cyber Security and Resilience Bill, it is also the kind of evidence you will be asked to show. If your clients want that evidence from an independent tester, we deliver it under your brand as white-label penetration testing, on the terms in our MSP partner programme.

Firmware flaws keep surfacing because AI-assisted research now reads code nobody has audited for years. This one was found by a researcher at an AI lab. The machines you image next month will still run firmware written long before anyone looked. Start by finding out, with an internal penetration test, what an attacker on your client networks can reach first. Your red team. Within reach.