Forgot your password?
Close
typodupeerror
Security

Code-Execution Flaw In UEFI Firmware Threatens Most Servers On Planet Earth (arstechnica.com) 152

Posted by BeauHD from the here-we-go-again dept.
Ars Technica's Dan Goodin reports: Defenders across the world face the burden of responding to yet another botched code-execution vulnerability, this time in boot-time firmware used by most of the world's server vendors and data centers. The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence. Last year, a representative of the UEFI Forum called (PDF) EDK2 the "preeminent solution / implementation of the UEFI specifications." Virtually all UEFI suppliers (sometimes still called IBVs or independent BIOS vendors), including AMI, Insyde, and Phoenix, use the reference code extensively. Project Mu, Microsoft's hardened EDK2 fork, used the code containing the vulnerable component as well.

The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code that runs before the operating system and firmware can implement defenses like Secure Boot, which establishes a chain of trust for all code, including the Trusted Platform Module (TPM), loaded during boot. While final payloads delivered by CVE-2026-97631 have no persistence -- meaning they run only once -- they can give attackers a wide opening to install other payloads that also run each time early in the boot process.

The parties that discovered CVE-2026-97631 -- Alex Matrosov of Anthropic and Dan Holmes of Google -- had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January. AMI, a maker of motherboards and other hardware, published this pull request last month that detailed the vulnerability and included a code fix. Once the post came to the attention of the discovering parties, TianoCore Project members published a public advisory last week. With publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and to build working exploits. Further compounding the urgency, patching UEFI code vulnerabilities in millions of end devices sold and used by thousands of hardware makers and cloud providers is cumbersome and time-consuming.

Code-Execution Flaw In UEFI Firmware Threatens Most Servers On Planet Earth More | Reply

Code-Execution Flaw In UEFI Firmware Threatens Most Servers On Planet Earth

Comments Filter:

  • ... the machine can be affected by outside input before it's security/self-defense system is ready?

    Oops.

  • "On Planet Earth" (Score:5, Informative)

    by Petersko ( 564140 ) on Tuesday October 27, 2026 @05:54PM (#66396784)

    My apologies for the pedantic reply, but I'm just getting exhausted by the seemingly endless need people have to inject urgency into headlines. "On Planet Earth" is not necessary. At all. You can drop those words and the sentence means exactly the same thing.

    What would be useful in the summary is some information on how the attack might happen.

    For the record, during the window of a PXE-boot, a malicious unicast ICMP error message can be picked up by the driver and cause a buffer overrun. The window is closed when boot is complete.

    https://github.com/tianocore/e... [github.com]

    • The window is also closed if you disable PXE booting I would assume. Which is the default for most systems.

      • The window is also closed if you disable PXE booting I would assume.

        I'm curious as to why you'd assume that.

        • Re: "On Planet Earth" (Score:5, Insightful)

          by drinkypoo ( 153816 ) <drink@hyperlogos.org> on Tuesday October 27, 2026 @06:46PM (#66396866) Homepage Journal

          Perhaps they read the top of the announcement where it says "While a machine is PXE-booting over IPv4 or IPv6" etc etc.

          • Re: (Score:2)

            by Himmy32 ( 650060 )
            There is the other part to the statement of having PXE default off. In my experience a fair amount of machines in the past two decades where the default is on.

            • IME on home gear it's off, and on servers it's on, but I am not working on PCs for a living right now so I'm not super up to date.

              A lot of people filter ICMP on their networks. Probably more people should do that.

              • It is not off by default. I have seen a lot of different hardware in my life (I basically do booting for a living), and I have never encountered a BIOS that had PXE disabled by default.

                BIOS has a boot order, and as far as I can recall PXE is always the last option. The order of what comes before varies, e.g. whether or not USB boot is tried first.

                In fact, on most systems if they cannot boot, they keep rebooting and ending up in a loop trying PXE boot over and over, and then giving up and rebooting again. Bu

          • Re: "On Planet Earth" (Score:5, Funny)

            by 93 Escort Wagon ( 326346 ) on Tuesday October 27, 2026 @08:59PM (#66397042)

            Must I remind you about the Slashdot Code of Conduct?

            - Reading anything except the summary is against the rules and may result in a lifetime ban.

            - Reading the full summary is frowned upon, but allowable. However posters are strongly encouraged to stop reading after the first two sentences.

            - Responses which make it obvious the author only read the first half of the submission title should be modded "Insightful" if at all possible.

      • Re:"On Planet Earth" (Score:4, Informative)

        by Zero__Kelvin ( 151819 ) on Tuesday October 27, 2026 @10:00PM (#66397078) Homepage
        Network booting is used by most major corporations including Google, Meta, and Amazon. The percentage of physical bare-metal servers using network booting (either traditional PXE or modern variants like iPXE and HTTP Boot) is effectively 100%. While this CVE doesn't come into play with HTTP Boot it does affect PXE boot and iPXE when PXE is used to chainload iPXE. For more information simply commit the blasphemy of entering "For CVE-2026-97631 do systems need to use network booting, and does it affect just PXE or iPXE and HTTP Boot?" into Gemini, Claude or your most hated AI.

        • No room for iSCSI HBAs?

        • > For more information simply commit the blasphemy of entering "For CVE-2026-97631 do systems need to use network booting, and does it affect just PXE or iPXE and HTTP Boot?" into Gemini, Claude or your most hated AI.

          That could return invalid results if (1) gemini "hallucinates" or (2) gemini's servers have already been compromised. </snark>
          • Did it? Whatever you do don't try it! You need to protect your ability to make uninformed and idiotic comments on Slashdot at all cost.

      • On nearly all machines it's enabled by default, but it's usually the last boot option.

    • Re: "On Planet Earth" (Score:4, Interesting)

      by Midnight_Falcon ( 2432802 ) on Tuesday October 27, 2026 @06:04PM (#66396802)
      This is another "the sky is falling" vulnerability post. Probably written by someone with a cursory understanding of cyber security. Unlike php2shell where a remote attacker over the internet can bust into your WordPress etc website, this requires someone with access inside your network...if you've set it up right, your restricted management network. At that point, you're already hacked. It also presumes a PXE boot environment, which is rather uncommon. Nobody needs to panic and patch this thing ASAP, eventual deployment of patches should suffice for most organizations.

      • Re: (Score:3)

        by Himmy32 ( 650060 )

        This requires someone with access inside your network

        One of the big things here is that many firewall models are more permissive with ICMP. Many organizations still have the hard shell turtle model to firewall design especially when it comes to ICMP. Microsegmentation is hard and many/most organizations aren't doing a perfect job of it.

        if you've set it up right, your restricted management network.

        Noting that it isn't just management servers that this affects and that some organizations do use PXE to image workstations/thin clients or general purpose servers.

        Nobody needs to panic and patch this thing ASAP

        People with PXE enabled absolutely should, this is a firmware l

        • If you are still using PXE on workstations still then absolutely it's something to patch. There is a narrow exploit window during boot up, but still sure...patch it. That said PXE is a bit of a dinosaur at this point, and cloud-native deployments for endpoints have been heavily used for well over a decade now. Microsoft is even deprecating its PXE deployment tool in favor of autopilot, which is a lot more reliable. So the solution for those organizations is probably going to be abandon PXE for endpoints

          • Re: (Score:2)

            by Himmy32 ( 650060 )

            But it's not even if people are still using PXE, but if the systems still have PXE in the boot options. MDT didn't even retire until this year and this vulnerability goes back for 16 years. And only the biggest corps are shelling out for Management Engine / PSP stuff to do config management at that level.

            Not advocating for PXE, I hated WDS since the day I touched it close to two decades ago. But the point is simply that PXE is still enabled on a lot of stuff and a good sysadmin shouldn't ignore that even if

            • I would definitely put it in the "turn that off at the next maintenance window" bucket, but a good sysadmin (does this job title exist anymore? Infrastructure engineer? DevOps?) wouldn't just leave PXE boot on in the first place...if for no other reason after reboot the thing takes a few seconds longer to boot while it tries to discover a PXE server via DHCP.
      • PXE boot is often used to chainload iPXE and most large organizations like Google, Meta, and Amazon use network booting.

        " Nobody needs to panic and patch this thing ASAP, eventual deployment of patches should suffice for most organizations."

        So "nobody" needs to patch this ASAP because someone will do it eventually? That makes sense.

        • People need to patch it eventually, but not immediately like PHP2Shell. The reason is the risk profile. It can only be exploited if you can deliver ICMP to the server, which means the network is already compromised. Given this means management interfaces to the servers' control plane, that's quite a pre existing network compromise in the first place. So rushing to fix a vulnerability that's incredibly difficult for a threat actor to exploit simply doesn't make much sense.
          • Nobody needs to take a high severity vulnerability seriously until they don't and find out they should have, at which point it is too late. All high severity vulnerabilities should be patched as soon as possible. Any other attitude is shear incompetence. Major corporations use contractors, and not all employees can be trusted either. Your assumption that it is too hard to do by a determined attacker with internal network access where thousands of servers are installed is just plain wrong. People were just
            • I was not among the doubters of php2shell, I moved my last WordPress site to React/Vite with 8 hours of reading about it. Critical bugs on internet-facing sites are no joke. Industry-wide, it's only CRITICAL internet facing vulnerabilities that get the rush to patch treatment. For critical (this one is scored critical, not high), on internal systems, it's 7-30 days. There's always a percentage of vulns that don't meet SLA, and this is going to be one because of the difficulty patching, meaning taking ser
            • UEFI was not designed with security as a priority (that is, in UEFI, security is an advertising point, not a security point). Compare the design methodology to OpenBSD software.

              The result is that there are guaranteed to be other high severity vulnerabilities, not yet found, in UEFI. Your network/system design should take that into consideration, and not rely on UEFI being secure.

              If your system does rely on EUFI being secure, then it's not secure.
              • This was not a UEFI flaw, it was a flaw in the particular implementation of the UEFI Standard [wikipedia.org]. The TianoCore EDK is a development kit that implements the open standard. You don't understand the basics, preferring instead to try to sound like a security expert, despite the fact that you have no idea how it is developed. TianoCore enforces an explicit Secure Coding Guide. No system is perfect, but you are just someone trying to sound like you know what you are talking about, when it is easy to prove that y
                • A) You are an asshole.

                  You don't understand the basics,

                  B) Absolutely false.

                  C) You tried to deflect from my main point by attacking a strawman, which makes it seem like you don't even understand 4th grade logic. Next time address the main point: UEFI was not designed with security as a priority, which invites security bugs in the implementation. They are almost impossible to avoid.

                  UEFI is not secure, and you are trying to play logic games to avoid that fact. The systems you design are probably all insecure, because demonstrably you can

                  • "Your network/system design should take that into consideration, and not rely on UEFI being secure."

                    I can't wait to hear how you intend to do that, or for that matter what you even thinks that means. Should they not connect the hardware together by networking it? What "flaw" in the network design do you think was made that allowed packets to get to the NIC? I'm guessing you will say "don't use ICMP" as if that doesn't make it impossible to control a network of thousands of computers properly.

                    "Next time add

                    • you are a clueless fuckwit with no idea what you are talking about, saying something that is completely untrue.

                      False. Asshole.

                    • Yes. That summarizes it pretty well. You're claims are false and the only way to deal with your idiocy is to be an asshole. I'm glad to see you at least understand something.

    • Re:"On Planet Earth" (Score:5, Funny)

      by OrangeTide ( 124937 ) on Tuesday October 27, 2026 @06:20PM (#66396828) Homepage Journal

      Few servers in orbit around Earth are impacted by this flaw.

    • "On Planet Earth" is not necessary.

      So far as I know, the problem has not yet been detected on other planets or spaceships.

      I'm guessing that Martians don't run Windows on their computing machines.

    • Re: (Score:2)

      by gweihir ( 88907 )

      I agree. The "making everything scare" type of messaging (I will not elevate it by calling it "journalism") is a plague of our times. Essentially a form of slop.

      That said, I do not think UEFI even processes ICMP. This is more likely about DHCP and that makes it a local-net only attack.

      • It does indeed. See the GitHub link.

        During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field...

    • > "On Planet Earth" is not necessary.

      Of course it is necessary. It lets me know that my servers on Mars are not affected.

    • Re: (Score:2)

      by mjwx ( 966435 )

      My apologies for the pedantic reply, but I'm just getting exhausted by the seemingly endless need people have to inject urgency into headlines. "On Planet Earth" is not necessary. At all. You can drop those words and the sentence means exactly the same thing.

      Are my servers on Alpha Centauri IIC are not fine then?

      Will it be better if I relocated them to Wolf 359?

    • Perhaps they are implying that the servers in space are unaffected?

  • From TFA : "Because the driver doesn’t enforce a memory copy limit of 504 bytes, overwriting adjacent data, a malicious insider or a hacker who has gained low-level access to a local network can send an error message that appends code past this limit. The IUEFI module running on the CPU then becomes corrupted."

    I am sure that "a malicious insider or a hacker who has gained low-level access to a local network" would have no other possibility from inside a data centre to cause any havoc.

    • Re:RCE Execution pathway (Score:4, Insightful)

      by Himmy32 ( 650060 ) on Tuesday October 27, 2026 @06:35PM (#66396846)

      "low level access" is just regular ole network access on the least restricted protocol of ICMP. Getting firmware breached by a ping is pretty bad...

      No, this isn't going to spoil the milk in most people's fridges bad. But for people with PXE turned on which is some manufacturer defaults, this is deserving of the 9 CVE score.

      • Re: RCE Execution pathway (Score:4, Informative)

        by Gavino ( 560149 ) on Tuesday October 27, 2026 @06:54PM (#66396870)
        I've always hated how PXE boot always seems to be enabled by default. One of the first things I do with new servers is to update NIC firmware and turn off any PXE boot and iSCSI mount options. Things shouldn't be turned on unless actually needed. Insecure defaults play a huge role in this.

        • The biggest boys who buy the most servers provision them via netboot, which is why it's on. You are not the biggest, so you have to turn it off. Me neither, so I also have to turn it off.

          But this is a good old buffer overflow fail, so this is some 90s shit they could have caught with analysis tools, and it's really not because the manufacturers leave PXE boot on. It's because components of UEFI BIOS are apparently written by amateurs.

      • Re: (Score:2)

        by gweihir ( 88907 )

        It is not ICMP. It is DHCP. And DHCP does broadcast to find the DHCP servers, so every machine in the local network sees it. If you do remote booting without DHCP (I used to do that via floppies wayyy back, but this requires the booting machine to get the IP of the boot server in some way), you are probably a lot harder to attack.

        • Re: (Score:2)

          by Himmy32 ( 650060 )

          Did you read the article?

          The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component

          “This vulnerability in the ICMP parser of the EDK2 network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem,” said HD Moore, creator of Metasploit

          the driver uses a network listener to monitor for ICMP errors.

          As the official advisory puts it: During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length.

          • Re: (Score:2)

            by gweihir ( 88907 )

            Haha, no. My thinking was that oversized ICMP is so old and well-known that they would surely not make that mistake. Apparently I gave them far too much credit.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Sure. But with this, the attacker owns every machine in the local network that they can get to boot. The problem is this is a generic attack.

  • To be clear... (Score:3, Interesting)

    by greytree ( 7124971 ) on Tuesday October 27, 2026 @06:00PM (#66396796)
    To be clear about this ( because it wasn't to me ):

    Attackers can exploit this and fuck up your computer's UEFI *from within* Windows.

    Because you usually need to update your MB code from the UEFI interface, you might think that is necessary to access UEFI code.
    It is not.

    • Re:To be clear... (Score:4, Informative)

      by 93 Escort Wagon ( 326346 ) on Tuesday October 27, 2026 @06:26PM (#66396836)

      Because you usually need to update your MB code from the UEFI interface, you might think that is necessary to access UEFI code.
      It is not.

      Didn't we already see a significant vulnerability related to this within the past 12 months?

      Also, it's not just Windows. Just a couple months ago I updated the firmware on a bunch of Dell boxes using fwupdmgr (on AlmaLinux 9). It's very convenient, but I (mostly) wish it wasn't actually possible... but, since it is, might as well take advantage of it.

    • Re:To be clear... (Score:4, Informative)

      by Himmy32 ( 650060 ) on Tuesday October 27, 2026 @06:41PM (#66396854)

      I don't think you read the article correctly, this particular vulnerability isn't during patching. Like yes, if you install a bad patch, of course that's problematic.

      But this vulnerability it's during boot if you have PXE enabled with network access to get a bad ping. Most people don't have PXE enabled, but a lot sure do. And those people could be facing a firmware level exploit that's not dependent on the OS.

      • Yeah, the threat actor would need a foothold on the PXE network, which is a private VLAN (or better) in the competent case.

        That's why we worry about APT's and such.

        Granted, you'll find people on certain cloud providers who do far too much on a public IP.

    • No you don't usually need to update MB code form UEFI interface. All major OSes offer hooks to update and change code from outside UEFI. But in any case that has nothing to do with how this exploit works.

    • Re: (Score:2)

      by gweihir ( 88907 )

      Ah, no. When Windows (or Linux) is running and attacker manages to get to the level of hardware access to write the BIOS chips, you are screwed, no connection to this vulnerability. They can simply add a key for their own kernel or switch secure boot off. What this vulnerability does is that if you use remote boot (PXE), they can get you to bute an unsigned kernel via a an attack coming from the local network.

  • Are they caused by simpletons who are letting AI do their jobs without any oversight?

    • Re: (Score:2)

      by Himmy32 ( 650060 )

      Disclosure mistakes are just simply a bigger deal than they used to be. The time and effort for an attacker to find and deploy an exploit is now quicker than the time that it takes to get a patch promoted, available, and have everyone patch.

    • Are they caused by simpletons who are letting AI do their jobs without any oversight?

      I would hope that AMI will offer a postmortem report that will explain how they broke the embargo. And they should have their membership in the super double secret handshake club reviewed and perhaps revoked if they can't show adequate changes in their processes to avoid the issue next time (and there will always be a next time).

  • Are they saying that the window for this attack is a specially crafted ICMP packet delivered within the one minute that EUFI is booting the system, but the window closes as TMP and the OS start?

    Am I understanding this correctly? That sounds pretty low risk for a RCE rated at 9.5. Sure the RCE is bad, but the execution of the attack seems challenging.

    • Here is the risk:

      1. sneak a piece of software into a data center that can send malicious ICMP frames, and listen for DHCP broadcasts
      2. when you receive a DHCP broadcast, listen for the offered IP, and send your malicious ICMP.

      Now you can fuck around with anything on that segment that has PXE enabled when it reboots.

      That's why this is a 9+

      • Re: (Score:3)

        by gweihir ( 88907 )

        Yes. The problem is that these days, remote booting can and typically uses DHCP. And DHCP does broadcast-type requests that every machine in the network segment sees. Of course, an attack has to come from the same network segment or rather broadcast domain (which are typically the same) so this is not a regular "long-distance" remote vulnerability, but essentially a "network local" remote vulnerability. Still pretty bad.

  • They seem concerned about the servers. But, doesn't this impact all modern systems?

    • Only if PXE booting, but otherwise yes.

      • Re: (Score:2)

        by gweihir ( 88907 )

        To be fair, most regular systems will not boot over the network.

        • To be fair, most regular systems will not boot over the network.

          Many desktops (targeted for corporations) will boot over the network, but I am not sure how many do so by default. Server class hardware deployed by in datacenters often has network boot enabled, and is used to install (and reinstall, and recover) the fleet.

          • Re: (Score:2)

            by gweihir ( 88907 )

            It is a bit of a tricky set-up because you need to be in the same broadcast domain for DHCP. My guess would be that very few desktops do it these days, even though it can definitely be done.

            • You can relay DHCP.

              Netbooting desktops is one of those ideas that sounds great and then isn't. The HDD isn't that expensive. AFAICT nobody does it except for clusters and POS which is worthless without the network anyway. Plus it's an opportunity for an attacker on your network to get your machine to boot another system so they get access to a whitelisted MAC.

    • Servers in large data centers are more likely to have PXE turned on, so some poor chud doesn't have to go find the damn server in 1 of 100 racks to plug in a USB key to reimage it.

    • Re: (Score:2)

      by Himmy32 ( 650060 )

      Servers were the more traditional use case for PXE. But VMs really took the wind out of that practice. Network boot images are way more clunky than VM images.

      So honestly I think you're right on the money that workstations at large orgs are more likely to have it turned on for reimaging/thin clients.

  • My media server's bootstrap firmware doesn't understand EFI at all.

    • Re: (Score:2)

      by Himmy32 ( 650060 )
      There's undoubtedly a lot of security tooling that UEFI allows for that BIOS doesn't. So outside of "Get off my lawn" cred, this might not be the best bragging point.

    • And they laughed when I kept on using SPARC and IBM POWER servers!

  • There are apparently other unpatched vulnerabilities that are known but 'too busy':

    It sounds like this fix got done because it was 'accidentally' posted as a public PR.

    https://github.com/tianocore/e... [github.com]

  • Secure boot never was secure (Score:3)

    by gweihir ( 88907 ) on Tuesday October 27, 2026 @10:09PM (#66397082)

    And it is, incidentally, not even about security of the machine. It is DRM - Digital Restriction Management. And it is off on all my systems.

  • Anybody knows whether this is really ICMP? (Score:3)

    by gweihir ( 88907 ) on Tuesday October 27, 2026 @10:34PM (#66397116)

    I looked at a few write-ups of CVE-2026-97631, but while they all mention PXE (and PXE uses DHCP, depending on configuration), none mentions ICMP. It would not make a lot of sense for the UEFI boot process to process ICMP packets either. Not ruling it out, people have done a lot of really stupid things with UEFI, but it does not seem to make a lot of sense here.

    Does anybody know whether this is really ICMP? ICMP would could make this an attack potentially not local to the network segment, while DHCP and PXE make it network-segment local.

  • ICMP not normally accessible (Score:3)

    by felixrising ( 1135205 ) on Wednesday October 28, 2026 @12:26AM (#66397226)
    On the plus side, only if you have PXE preboot environment setup are you possibly at risk, this is a very narrow window of opportunity to exploit.

  • So Musk's Mars basis is safe, or what does the article want to tell?

Slashdot Top Deals

At the source of every error which is blamed on the computer you will find at least two human errors, including the error of blaming it on the computer.

Close