Code-execution flaw in UEFI firmware threatens most servers on planet Earth

I've been thinking similarly, that we're quickly going to want to start minimising dependencies and code size in the programs we make to try to reduce attack surface area.

70's software is closed-source bespoke reimplementation; 80's Dream of reusable software components; 90's Building the Dream; 00's Living the Dream; 10's Everything is amazing but; 20's transition to...; 30's what??? Open-{source, reference implementation, tests, specs, design docs, gist, ...?} bespoke reimplementation?

中国特色. And an even larger gap vis optimized-for-pharma US IP config (Industrial Policy).

I really like this idea of 300 lines (asm) vs ~1M lines (C) which was possible by really understanding what you are doing and limiting to the core feature you need. In this case you had 'the luxury' of this being low level code. What I fear for is all (application) the code that runs on top of frameworks/run-times/interpreters (in reference to the recent PHP drama). We can harden our application code as much as we like, but if the underlying code is not safe we have an issue - this combined with you remark on attackers being in the advantage versus defenders. At this time the only way that I see to protect this is by using some kind of (virtual) private network. What are your ideas on this?

"Popular" usually means that supporting many use cases. Many use cases means a lot of code. Probably means increased complexity. Tailored hyperspecific firmware is much more usable now and maybe you can even formally verify it.

I feel like I was reading this from Marcus Ranum in 2005 in the famous article "Six dumbest ideas in computer security"[1] where he wrote about just running a custom webserver that accepts only correctly specified requests, instead of Apache and a filter set of bad-request-blockers and a default-permit firewall and etc.

That article makes good re-reading in the "Penetrate and Patch" section now, in the days of AI exploits popping up faster and faster.

[1] https://www.ranum.com/security/computer_security/editorials/...

Yea I really like this idea.

We need a clean start. A lot of layers can and should be rebuilt, and even if you do it without reducing functionality, I feel like in a lot of cases like we’ll be able to cut down the code significantly.

When I explain software bloat to non technical people, I say imagine you built a 10 story building, but every few years it was a story at a time with the renovations along the way.

Like there’s gonna be a lot of inefficiencies. Yea I know we refactor. But doing a clean slate rebuild. Knowing exactly what you need based on real world experience, it should work to really streamline stuff.

>You can point an LLM at any large codebase and it will find vulnerabilities, so "patch the planet" isn't very scalable.

So the solutions need to be structural.

e.g. relative to a monolith kernel, seL4 is small, has no known bugs (AI can try, but so far crickets) and is the only piece that needs to run privileged.

Everything running under seL4 benefits from the guarantees seL4 provides.

> https://tinfoil.sh/blog/2026-10-25-less-is-more

The blog-post is written by AI. I am more than interested to hear a human talk about it but AI generated blog post removes that interest.

You cannot trust compiler generated machine code and/or significantly sized runtimes. Some simple binary specifications with some assembly implementations (could be on several ISAs, x86_64, RISC-V, etc).

I guess this is what they are doing.

> to very minimal and hyperspecific firmware (300 lines of assembly)

So, just normal BIOS boot?

> It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does.

Yes it does? If anything, it provides way more; a .efi program can use firmware services to load files and print text. There's like 80% of a DOS in there.

> Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?

Because we still want enough functionality to load the OS in the first place, which means e.g. nvme drivers, Ethernet drivers (for netboot), keyboard input and some display output (to let a user pick what to load), and of course filesystem drivers because loading an OS/bootloader from a single shared MBR was awful.

BIOS had to be replaced. It didn't have to be UEFI, but it did need to be something, even just a new 64-bit stage would have gone a long way. But nobody made such a thing, and the alternatives that actually exist like Coreboot do a lot less even than BIOS did. Past a certain point, pretending to be smol-bean 1980s/'90s hardware stops being a fun game and starts being a real limitation holding things back. Said "hardware abstraction layer" was getting to be more like a bunch of increasingly hard-to-maintain lies told to BIOS rather than a real service provided by BIOS.

> doesn't really provide a hardware abstraction layer like BIOS does

I'm not really sure what this means. UEFI provides a consistent interface to access storage devices, network devices, input devices, and access to a framebuffer. How else would bootloaders work?

Well, looking at the mess that is most arm/arm64 SBCs, I understand why it’s nice to have a standard interface that can run (eg) grub. Can UEFI be much smaller? Also yes.

The value of UEFI is surely dubious. I recently had to update my BIOS using Windows PE since there was no way of doing this on Linux. Of course my default boot was reset. The funny thing was though that I could repair my Linux boot using Win PE.

Before the only way was either fdisk /mbr to reset for Windows or boot a Linux system on stick/CD and rebuild grub/lilo. The latter has gotten unreasonably complex though so I rather wouldn't do this manually.

My verdict is that UEFI does something right, but created for the enterprise sector carries way too much complexity. Obviously so complex that everybody ends up using the original same code base.

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.

You can technically send then all the time and it is enough that they boot once. No need to know the time beforehand.

PXE boot enabled and attempted by default on an internet-facing network interface is certainly a... choice.

This is something that shouldn't be possible in the real world because any sysadmin should know not to do this, but guaranteed there are at least some small time operations with a couple of colo'd servers that only have single interfaces serving public traffic, and the intern who set them up didn't know what a boot order was or what "PXE" even did.

Before publishing the exploit, I imagine it would've been quite practical to flood an entire data center with malicious ICMP packages and just waiting for the next kernel patches that necessitate rebooting to come out. If you don't know that the ICMP packets flooding in aren't just weird background noise, you might ignore them when they're not causing problems.

For a deployed server, yes, you’d probably need to first get inside their network, then using some other exploit or social engineering, cause the server to reboot and then provoke this vulnerability and gain a persistent shell on the server.

This may sound like a movie-plot threat in 2020, but perhaps in 2026 it’s less unlikely?

There’s also the theft scenario, as indicated in the article, or the supply chain attack scenario. I don’t know how feasible it would be for a buyer to validate the integrity of the hardware they just racked up if they can’t trust secure boot?

It its anything like recent exploits, the whole internet is going to get hacked in 15 minutes... its a real exploit didn't you know?

The chaining to get something like this to work is pretty up there.

I don't know where Ars Technica got that from, though. The initial advisory [1] says:

> The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance.

[1] https://github.com/tianocore/edk2/security/advisories/GHSA-9...

This one seems weird. PXE-boot is such a fragile process in and off itself this doesn't strike me as end-of-the-world. If an attacker has enough presence on your network to send a targeted ICMP packet, they almost certainly could also fool around with your PXE-booting servers some other way.

This is literally some security people crying wolf until everyone just stops listening to them.

[dead]

Gadzooks! I must launch my homelab into LEO, stat!! Quick <local LLM>, start me a space program!

Servers are locked down these days too, are they not? They may have an encrypted boot image, with keys in TPM, and boot from a PXE provisioning system. Would this offer a path to modify that boot image?

They almost had a cybercriminal up there. Too bad it was all made up and the position of the first ever space criminal is back up for grabs.

Arguably it's trivial to fix for most netbooting environments, the one iffy case would be corporate laptops configured to boot from net for management purposes because there "attacker controls the network and timing" suddenly can become easy

It's ICMP, so any network that doesn't filter ICMP and would allow malformed packets through could be a target. You'd have no idea when something was PXE booting, so you'd have to keep sending the packets and wait.

A bigger question I think is why you'd assign a public IP to a machine for PXE boot rather than booting it from a private IP space then assigning any publics once the OS is booted.

CVSS is an imperfect system. Most of the time it gets the idea of how severe an issue is across, but once you go above an 8, maybe an 8.5, there are some perverse incentives at play. Even with newer versions of the framework coming out over the years, there have always been gaps.

Even before AI, there was prestige in being able to say that you (or your team) found a 9.2 in some major piece of software. You could put that on your resume in some specializations.

Now with AI vulnerability scanning being so hyper-commercialized (but not yet fully commoditized), this is cranked way up since there are more monied interests involved, and many of them are probably trying to make a quick buck before LLM-based vulnerability scans are a commodity (for better or worse).

The PHP CVS were originally reported as perfect 10s and in theory allow remote access (practically all of the internet). This requires physical hardware access (practically 0 of the internet).

Those original PHP 10s were negotiated down into a 9.2 by disclosure.. so maybe this'll be an 8.7 soon.

CVSS scores are essentially meaningless. Don't read anything into it.

Check it yourself: paste CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H into a CVSS analyser and read the descriptions of the related categories.

They can't really call it a 12...

They had a massive amount of bot attacks recently. That captcha wasn’t always there, but the website became so slow as to be unusable. That captcha only surfaces from certain countries. It comes up far, far less frequently than it did a few weeks ago

Clearly you don't work on anything on the Web in 2026, if you're complaining about a captcha.

If you have network boot enabled and you’re on a recent enough uefi you’re vulnerable yes. However personal devices have uefi network boot disabled by default

Suppose the server only boots signed images created by itself, which the PXE server happens to serve. You cannot just switch or mess with the menu. But if you can exploit the boot chain before any Secure Boot components run, then you might find your way in.

Aren't orbiting stations and satellites part of planet earth's space?

I was wondering about servers on satellites.

More buffoonery, this time from AMI.

As TFA says, this can be exploited only by someone who already has access to the internal network of the company.

Moreover, in well configured networks there is typically a separate network for the management Ethernet interfaces of the servers, to which non-authorized computers do not have access, and Ethernet booting of the servers is done through that network.

So the bug can be exploited only by a company insider, who must be an admin for the case with a separated management network, or by an external attacker who already has control over an internal computer, which must be the computer of an admin in the case with separate management network.

I'd argue datacenters in Space implies datacenters outside of Space.

The space-based data centers will serve the exploit via the InterPlanetary File System.

Several large bare-metal hosting companies. Not over the open Internet, but that doesn't matter if the management networks are shared and the price of admission a single server rental.

It's a pretty common setup on servers, even if it's not the majority. Probably more commonly it's part of the boot sequence on servers even if it's not used. I would say this is a relevant issue for most organizations' network security because of the risk it represents of being able to escalate from compromising a less privileged machine (e.g. a user's device) to a more privileged machine. It's not a 'oh god every server is going to be pwned' issue, but it doesn't need to be to be worth alerting people to.

> No, I don't think network booting is even all that common outside of extremely niche scenarios.

It's incredibly common though? I've run across it and I work on games and client software, not server stuff.

It's always fearmongering when it comes to "vulnerabilities" that affect the model of locking down computing devices.

This shit used to confuse me so hard when I was learning security. It seemed that articles were talking about something really important, but I just couldn't connect it to anything I knew. Then I realized they weren't talking about security for users, but rather security from users - and for entities ultimately looking to restrict users (the same inversion-of-authority as TSA propaganda). Hence the syndrome of acronym hell, as that amount of overabstraction is required to motivate a system for its own purposes.

Now given that this is a network exploit, you've got to adapt my model a bit from above - my framing is most clear when talking about local "exploits" in locked down bootloaders etc. But from an individual security perspective here? If you've disabled the network stack in your BIOS (because why the hell is it there in the first place), OR put any management interfaces on their own network unreachable from anything that isn't trusted to be managing, this is an utter nothingburger.

> Another breathless fearmongering.

It's Ars; you come to expect it.