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.
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.
> 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.
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.
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.
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
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.
They can't really call it a 12...
> 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.
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.
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.
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.