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.
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.
I've taken to saying Donald Knuth was wrong, premature optimization isn't the root of all evil.
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
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.
So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
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?
The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
I've always been downright suspicious of the creation of UEFI. It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does. Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?
And unlike BIOS which is relatively small UEFI is "full-fat" almost the size of an operating system itself. It can even run its own applications.
The 1 million lines of C code comprising UEFI are riddled with bugs and this is just one of them. No doubt LLMs will be able to uncover a lot more of them.
> 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.
they also provide device trees to the kernel on modern arm uefi environments. And in servers they provide an interface for the baseboard management controller to interact with the firmware directly.
> 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.
> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.
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.
Yes - all the times I've seen PXE boot used, the usage has been "Hold F12 during boot to reformat the disk and re-install the OS from scratch"
Which is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
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.
Would this mean any TPM based decryption keys could potentially be compromised in this kind of attack? E.g. when they're used for LUKS disk encryption.
It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.
Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.
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.
Well because some php configurations had an absurdly low default max upload size, which made the rce way harder.
Plesk for example ships with 2m for some reason.
The fact that a subset of systems are in a less vulnerable configuration doesn't have any bearing on the CVSS score.
> Specific configurations should not impact any attribute contributing to the CVSS Base metric assessment , i.e., if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration. [1]
For a vulnerability to score a 10 its Attack Complexity must be 'Low' (broadly speaking: it doesn't require target-specific customizations or mitigations [1]), which isn't the case with php2shell.
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).
so how many firmwares actually compile in this ICMP stuff? because edk2 builds in a way that it will only package the stuff actually used. u include protocola and handles etc.
personally never found a reason why to include icmp in there for what i was building using edk2.
as others noted pxe is also already very fragile and enough network access to perform the icmp attack is likely enough access to mitm the entire pxe run and slap in your own boot image or modules etc.
i dont think most servers boot using PXE so that is grossly overstated? or would it include the attacker going into the boot menu and selecting to pxe boot... because why use an exploit then if you can just point it to your own server and again pull the image like that.
all u need is a konboot or similar tool inserted to then subsequently load the original image -_-
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.
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.
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.
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
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
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.
Do one thing, and do it well.
The unix philosophy prevails!
I've taken to saying Donald Knuth was wrong, premature optimization isn't the root of all evil.
Dependencies are.
Part of that is reading bits and pieces of what Nancy Leveson had to say about the subject. Subsystems even when working to spec can produce spectacular failures.
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.
So you need to send an ICMP packet to a server while it's booting? That seems like an extremely small attack surface. I dont know when the last time our enterprise servers actually booted up, they just stay on forever
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?
You can technically send then all the time and it is enough that they boot once. No need to know the time beforehand.
The worst part of that is that you can't even configure your host firewall to block it, since the OS it runs on won't be running during the boot, obviously. It has to be blocked upstream. Which means that if you just have one host at a hosting provider, you depend on them to do it (although, you may still have the option to access your BIOS settings to disable PXE, or your host provider may provide upstream firewall configuration).
At least some enterprise IDS /AFW could presumably have a signature configured for this traffic scenario.
Before you manually configure a rule in your WAF you might as well just fix the vulnerability in the vulnerable component directly ^^
especially in free/open source software like edk2
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've always been downright suspicious of the creation of UEFI. It executes code before the operating system but doesn't really provide a hardware abstraction layer like BIOS does. Most operating system don't use BIOS or any other software layer and configure the hardware themselves. Why is it there then?
And unlike BIOS which is relatively small UEFI is "full-fat" almost the size of an operating system itself. It can even run its own applications.
The 1 million lines of C code comprising UEFI are riddled with bugs and this is just one of them. No doubt LLMs will be able to uncover a lot more of them.
> 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.
they also provide device trees to the kernel on modern arm uefi environments. And in servers they provide an interface for the baseboard management controller to interact with the firmware directly.
> 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.
I think uboot is kinda doing that?
some arm64 sbcs support edk2/uefi btw. I make sure I just use those. Look for "Arm SystemReady" certification, which requires this
The beatings will continue until cybersecurity improves.
I imagine AI will expose many backdoors created by three letter agencies. This could be one.
> There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights.
This is literally some security people crying wolf until everyone just stops listening to them.
They're admitting it though, at least?
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.
Yes - all the times I've seen PXE boot used, the usage has been "Hold F12 during boot to reformat the disk and re-install the OS from scratch"
Which is something that happens inside a trust boundary. After all, if an untrusted third party gets to install your OS it's game over, UEFI bug or not.
And consumer devices often don't have a network card - or come with PXE disabled in the BIOS.
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.
Would this mean any TPM based decryption keys could potentially be compromised in this kind of attack? E.g. when they're used for LUKS disk encryption.
Yup, if there's no passphrase involved.
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.
Do any of the locked down consoles or phones use a vulnerable UEFI implementation by any chance?
Phones most commonly use their own bootloader stack.
UEFI is pretty common on phones now, but it's unlikely that any of them are running this network stack there.
Is it? I'd like a UEFI phone booting GNU/Linux but last I looked it was a bunch of hacky aftermarket firmwares.
PS your profile links a blog that says you moved
It being UEFI doesn't mean it's a standard platform, there's no ACPI and you're going to need a custom kernel that targets that specific device. UEFI alone isn't enough to support booting a generic OS.
And thanks! Updated my profile.
Except that a sensible deployment of PXE boot would also have the servers attest to their state prior to giving them any secrets. This vulnerability breaks this workflow.
On planet earth? Thank god the ai servers in space are safe!!
The astronauts on the ISS must be breathing a sigh of relief, I imagine.
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.
How is this a 9.5 if php2shell was a 9.2?
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.
Well because some php configurations had an absurdly low default max upload size, which made the rce way harder. Plesk for example ships with 2m for some reason.
The fact that a subset of systems are in a less vulnerable configuration doesn't have any bearing on the CVSS score.
> Specific configurations should not impact any attribute contributing to the CVSS Base metric assessment , i.e., if a specific configuration is required for an attack to succeed, the vulnerable system should be assessed assuming it is in that configuration. [1]
For a vulnerability to score a 10 its Attack Complexity must be 'Low' (broadly speaking: it doesn't require target-specific customizations or mitigations [1]), which isn't the case with php2shell.
Here's a breakdown of that 9.2: https://www.first.org/cvss/calculator/4.0#CVSS:4.0/AV:N/AC:H...
[1] https://www.first.org/cvss/v4.0/specification-document#Attac...
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).
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...
“These go to eleven”
And this is the reason why we need datacenters in space.
I'd argue datacenters in Space implies datacenters outside of Space.
Fools! That is why I don't keep my servers on the planet Earth. Mua ha ha ha ha....
so how many firmwares actually compile in this ICMP stuff? because edk2 builds in a way that it will only package the stuff actually used. u include protocola and handles etc.
personally never found a reason why to include icmp in there for what i was building using edk2.
as others noted pxe is also already very fragile and enough network access to perform the icmp attack is likely enough access to mitm the entire pxe run and slap in your own boot image or modules etc.
i dont think most servers boot using PXE so that is grossly overstated? or would it include the attacker going into the boot menu and selecting to pxe boot... because why use an exploit then if you can just point it to your own server and again pull the image like that.
all u need is a konboot or similar tool inserted to then subsequently load the original image -_-
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.
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!?
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.
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.
There is also HTTPS boot, which might be a lot more secure than PXE
https://tianocore-docs.github.io/EDKIIHttpsBootGettingStarte...
> 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.
> Another breathless fearmongering.
It's Ars; you come to expect it.
Aah, that‘s why Musk wants space datacenters
Not only this is clickbait, they want me to solve a captcha in order to open it. What a trash website.
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.