While everyone is still talking about the php exploits an Anthropic and Google researcher found a vulnerability on how to take over a machine during a network boot. This kind of stuff just blows my mind, how can you possibly defend against this? Maybe its time to shut all the systems down and move into the woods Ars Technica article Guide on patching systems

Ars Technica reported on this yesterday <https://arstechnica.com/security/2026/10/code-execution-flaw-in-uefi-firmware-threatens-most-servers-on-planet-earth/> so let's have it here too.

Copied from the advisory <https://github.com/tianocore/edk2/security/advisories/GHSA-99cj-7hg9-mp4m> on the edk2 repo:

Summary

While a machine is PXE-booting over IPv4 or IPv6, an unauthenticated network attacker who can deliver ICMP error messages to it can corrupt DXE-phase memory and execute arbitrary code before the operating system loads, before Secure Boot or measured boot has verified or measured any OS component.

Details

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.

Impact

Unauthenticated, pre-boot, over the network, while a machine is PXE-booting over IPv4 or IPv6. The attacker needs only to deliver a unicast ICMP error message addressed to the client's IP, from any network distance; the exposure window is the duration of the PXE boot. (a) Deterministic corruption of the driver's private data and a CPU exception inside the DXE core on the next ICMP error, the boot hangs (denial of OS provisioning / recovery). (b) An attacker who knows the target firmware build can plant a counterfeit event in the same packet and have CoreSignalEvent() dispatch attacker-supplied bytes in the DXE phase (ring 0, before any OS security control exists).

Patch

#13302 <https://github.com/tianocore/edk2/pull/13302>

Credit

Thanks to Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google) for finding this issue and providing the recommended fix.

[end of copy]

CVSSv4 9.5/10 according to Github. OVMF is vulnerable according to Debian Security Tracker <https://security-tracker.debian.org/tracker/CVE-2026-97631>, with no fixes on any release yet.

-valtteri

Reading about the EDK2 PXE bug (CVE-2026-97631). If something can send a crafted ICMP error to a machine while it's network booting, it can run code before Secure Boot does anything.

What I keep coming back to is the inventory side. Not which servers use PXE, which have it enabled. I'd guess a lot of that is just factory default. And provisioning networks aren't alwys as isolated as the diagram says. Is there a sane way to audit this, or is it just checking BIOS settings machine by machine?

I found a heap buffer overflow in the Brotli glue code in EDK2 (BrotliDecompress.c). It has been there since 2017 and it’s still unfixed at HEAD.

Some background. CVE-2021-28211 was a heap overflow in EDK2’s LZMA decompressor. GetInfo took a UINT64 decoded size and truncated it to UINT32 with no check, so the decoder could write past the buffer that had been allocated. The fix added a MAXUINT32 check and bounded the output.

The Brotli decompressor was added earlier with the same structure, and it never got the same fix. BrotliDecompressInternal writes into the destination buffer with no limit. It just runs until the stream ends, whatever size the buffer is. If you control the firmware image, you declare a small output size (or use the UINT64 to UINT32 truncation), the DXE core allocates that much, and the decompressor writes past it. That’s a heap overflow in DXE, before Secure Boot.

I have an ASAN-confirmed PoC. I also built an end-to-end demo that corrupts adjacent pool objects in a controlled way: it hijacks function pointers and overwrites the Secure Boot flag with bytes I choose.

The catch is that I couldn’t find anyone using it. I scanned 200 shipping firmware images from LVFS and searched public GitHub repos, and found zero platforms that use Brotli GUIDed sections. The code is in the tree but looks unused in practice. That’s one scan of 200 images, so it doesn’t rule out private platforms. I still think it should be fixed, because anyone who adopts Brotli later would inherit the bug.

Write-up, PoC, demo and the LVFS scan: https://github.com/lukr54/edk2-security

EDK2 issue: tianocore/edk2#13391

EDK2 contains a vulnerability in BIOS where a user may cause “Out-of-bounds Write”, Classic Buffer Overflow, and “Incorrect Calculation of Buffer Size” by remote access. Successful exploitation of this vulnerability can lead to arbitrary code execution. It could also impact Confidentiality, Integrity, and Availability.

A buffer overflow vulnerability in the Brotli decoder (c/dec/decode.c) in Google Brotli versions 1.0.3 through 1.2.0 on all platforms allows a remote unauthenticated attacker to corrupt adjacent decoder state memory, disclose sensitive memory contents, cause a denial of service, or potentially execute arbitrary code using a crafted Brotli-compressed stream. Users need to update any Brotli libraries or binaries between 1.0.3 through 1.2.0 to the latest available version: 1.0.10 or 1.1.1 or 1.2.1.

Hello.

These issues were privately reported to the EDK II maintainers on 2024-12-25 (via GHSA-85f5-mjx9-mg54). Affected versions were: <= edk2-stable202411. I'm not aware of any fixes, so any later version is expected to be vulnerable.

There was some technical discussion, which ended on 2025-01-22.

On 2025-12-30, I asked for updates, also asked if my report should be marked as "WONTFIX", but got no reply to these questions.

So, here is the disclosure.

In short, one must not trust the PCR[5] measurements recording the expected GUID Partition Table (GPT) layout. This is expected to affect TPM-based FDE instances when the underlying GPT layout is somehow security-relevant.

My original report (converted to plaintext, PoC removed):

The DxeTpm2MeasureBootLib library can measure a partition table different from one parsed by the PartitionDxe driver

Summary

I have found that a logic error and relaxed checks (and one possible violation of the TCG specification) can result in the Tcg2MeasureGptTable() function (DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c) measuring (into the PCR[5]) a partition table which is different from the one parsed by the PartitionInstallGptChildHandles() function (PartitionDxe/Gpt.c) from the same block device.

And these two partition table instances can be different from another one used by the operating system.

In particular, the DxeTpm2MeasureBootLib library, the PartitionDxe driver, and the operating system can parse the same data on the same block device in three different ways, leading to three different, attacker-controlled partition table instances being used in different pieces of code (here, "instance" refers to the partition layout observed by one of those implementations listed after parsing on-disk data).

Since a partition table can include security-related metadata, these issues are reported as a vulnerability.

For example, at least one fixed (no longer embargoed) vulnerability, CVE-2024-43513, relies on an attacker being capable of setting the "noautomount" bit in the GUID partition metadata. So, it's critical to measure the same partition table instance as used by other firmware components and operating system components. Or, at least, detect possible edge cases and bail out early.

The vulnerability described here allows an attacker to change the entire partition layout or metadata of a specific partition in a way that is invisible to the measurements done using the PCR[5] and recorded in the TPM log. (An "expected" partition layout is measured, but a "malicious" partition layout is used, without executing anything unexpected... This is a data-only attack.)

Details behind vulnerability

The code responsible for parsing the GUID partition table starts here: https://github.com/tianocore/edk2/blob/1cc78814cd8812c459115749409882b7243e5581/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L233.

The code responsible for measuring the GUID partition table starts here: https://github.com/tianocore/edk2/blob/1cc78814cd8812c459115749409882b7243e5581/SecurityPkg/Library/DxeTpm2MeasureBootLib/DxeTpm2MeasureBootLib.c#L188.

The GUID partition table layout is described here (for reference): https://en.wikipedia.org/wiki/GUIDPartitionTable.

The TCG specification mentioned is here: https://trustedcomputinggroup.org/wp-content/uploads/TCG-PC-Client-Platform-Firmware-Profile-Version-1.06-Revision-52pub-2.pdf.

By design, the code for parsing the GUID partition table runs before the code that measures it (because the boot device is unknown at that stage, so it's unclear what block device to use).

The code that measures the partition table (in the DxeTpm2MeasureBootLib library) does the following: 1.1. it reads data from LBA 1 (the GPT header); 1.2. it validates the GPT header using relaxed checks (e.g., it doesn't validate the CRC32 checksums); 1.3. it reads data from LBAs containing the GPT partition entry array; 1.4. it builds a structure containing both the GPT header and the GPT partition entry array, empty partition entries are ignored (see: Note 1); 1.5. it measures and logs that structure.

This code is pretty straightforward. It assumes that the right GPT header is located in LBA 1, the code doesn't try to read it from a backup location (LBA MAX — this is the highest LBA available on the underlying drive). And the checks are relaxed (I mean, they are very relaxed compared to the PartitionDxe driver).

--- NOTE 1 ---

The corresponding condition (used to check if the partition array member is empty) is:

if (!IsZeroGuid (&PartitionEntry->PartitionTypeGUID))

This behavior violates the TCG PC Client Platform Firmware Profile Specification, table 15 (page 101). The number of partition entries to be measured "corresponds to the GPT Header NumberOfPartitonsEntires. See the UEFI Specification GPT Header". This fields counts the number of all partition slots in the array, not just allocated (used) partition entries.

Such a violation allows an attacker to change one byte in an unused (empty) partition entry, after the "PartitionTypeGUID" field (i.e., in the data area not included in the measurement), leading to the checksum validation failure.

In other words, an attacker can corrupt the partition entry array in a way that isn't covered by the PCR[5] measurement.

--- END OF NOTE ---

The code that parses the partition table (in the PartitionDxe driver) does the following: 2.1. it reads data from LBA 0 (the MBR); 2.2. it checks if the MBR contains a protective partition; 2.3. it reads data from LBA 1 (the GPT header); 2.4. it validates the GPT header using stricter checks (these include the GPT partition entry array checks); 2.5. it reads data from LBA MAX (the backup GPT header); 2.6. it validates the backup GPT header using the same (strict) checks; 2.7. if one of those GPT headers is invalid, it tries to repair the GPT header using its valid copy; 2.8. it reads data from LBAs containing the GPT partition entry array; 2.9. it validates the GPT partition entry array and then creates child device handles for valid partition entries (there is no failure if any partition entry is invalid for some reason, but this is okay).

As you can see, the code in the DxeTpm2MeasureBootLib library assumes that the partition table was checked and repaired, if required, in the PartitionDxe driver.

This is a wrong assumption, because the underlying drive could be write-protected (e.g., it's a degraded RAID volume). In this case, an attempt to write (by calling the DiskIo->WriteDisk() method in the PartitionRestoreGptTable() function) the "repaired" GPT header data to LBA 1 will result in an I/O error, so the invalid GPT header would remain there (and, thus, read later by the DxeTpm2MeasureBootLib library).

However, this is an edge case. So, let's continue...

At steps #2.3-#2.7, the following code gets executed:

// // Check primary and backup partition tables // if (!PartitionValidGptTable (BlockIo, DiskIo, PRIMARYPARTHEADERLBA, PrimaryHeader)) { DEBUG ((DEBUGINFO, " Not Valid primary partition table\n"));

if (!PartitionValidGptTable (BlockIo, DiskIo, LastBlock, BackupHeader)) { DEBUG ((DEBUGINFO, " Not Valid backup partition table\n")); goto Done; } else { DEBUG ((DEBUGINFO, " Valid backup partition table\n")); DEBUG ((DEBUGINFO, " Restore primary partition table by the backup\n")); if (!PartitionRestoreGptTable (BlockIo, DiskIo, BackupHeader)) { DEBUG ((DEBUGINFO, " Restore primary partition table error\n")); }

if (PartitionValidGptTable (BlockIo, DiskIo, BackupHeader->AlternateLBA, PrimaryHeader)) { DEBUG ((DEBUGINFO, " Restore backup partition table success\n")); } } } else if (!PartitionValidGptTable (BlockIo, DiskIo, PrimaryHeader->AlternateLBA, BackupHeader)) { DEBUG ((DEBUGINFO, " Valid primary and !Valid backup partition table\n")); DEBUG ((DEBUGINFO, " Restore backup partition table by the primary\n")); if (!PartitionRestoreGptTable (BlockIo, DiskIo, PrimaryHeader)) { DEBUG ((DEBUGINFO, " Restore backup partition table error\n")); }

if (PartitionValidGptTable (BlockIo, DiskIo, PrimaryHeader->AlternateLBA, BackupHeader)) { DEBUG ((DEBUGINFO, " Restore backup partition table success\n")); } }

DEBUG ((DEBUGINFO, " Valid primary and Valid backup partition table\n"));

// My note: the "PrimaryHeader" variable is then used to read and parse the GPT partition entry array.

If both GPT headers are valid, the code jumps to the last line quoted above.

If both GPT headers are invalid, the code bails out ("goto Done;").

If one GPT header is invalid but the other one is valid, the invalid GPT header is repaired using the valid one (by calling the PartitionRestoreGptTable() function). After this, the repaired GPT header (and the corresponding) is read and validated again (by calling the PartitionValidGptTable() function).

The logic error here is that that both functions, PartitionRestoreGptTable() and PartitionValidGptTable(), can fail (return false) and leave data referenced by the "PrimaryHeader" variable intact (in the untrusted, known to be invalid state). The code just jumps to the next block (marked with the "Valid primary and Valid backup partition table" message), which uses the "PrimaryHeader" variable.

Fortunately, this doesn't lead to out-of-bounds access in the current code.

So, the code must never assume successful writes in the PartitionRestoreGptTable() function and successful reads in the PartitionValidGptTable() function, it must bail out as soon as one error condition is encountered.

Previously, I mentioned one case when the PartitionRestoreGptTable() function returns false: when there is a write error because of write-protected media.

There is another case resulting in write and subsequent read errors: when an attempt is made to restore the GPT header beyond the end of the corresponding block device. The PartitionRestoreGptTable() function tries to restore the GPT header to the "alternate LBA" as specified in the GPT header that passed the checks (the valid one). And this "alternate LBA" can point to any location, beyond the end of the block device too. See: https://github.com/tianocore/edk2/blob/1cc78814cd8812c459115749409882b7243e5581/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L637.

This is not an edge case, because all conditions here are software-only and attacker-controlled.

Vulnerability

The idea is to keep the GPT header (LBA 1) intact, keep the measured part (everything but unused partition entries) of the GPT partition entry array intact, then invalidate the GPT partition entry array by modifying one byte within any unused partition entry (this will break the CRC32 check at step #2.4, but the final PCR[5] value will remain the same).

This will force the recovery logic (step #2.7).

During the recovery, the malformed GPT backup header is processed (and it passes all of the checks at step #2.6). Its "alternate LBA" points somewhere in the middle of the underlying drive.

After the recovery, the real GPT header (LBA 1) is intact (it wasn't overwritten during the recovery process) and the "recovered" malformed GPT header is used (its data is now referenced by the "PrimaryHeader" variable).

In particular, the "PartitionRestoreGptTable (BlockIo, DiskIo, BackupHeader)" call places the malformed GPT header into the middle of the drive and the "PartitionValidGptTable (BlockIo, DiskIo, BackupHeader->AlternateLBA, PrimaryHeader)" call reads that header into the "PrimaryHeader" variable.

This allows the attacker to "replace" the GPT header used by the PartitionDxe driver: it's taken from an unusual location (somewhere in the middle of the drive). The real GPT header, which is later used by the DxeTpm2MeasureBootLib library, is left intact (at LBA 1).

In order to "replace" the GPT partition entry array, the following actions should be performed:

(When recovering from the backup GPT header, the PartitionRestoreGptTable() function writes this array to LBAs 2+ unconditionally, see: https://github.com/tianocore/edk2/blob/1cc78814cd8812c459115749409882b7243e5581/MdeModulePkg/Universal/Disk/PartitionDxe/Gpt.c#L631.)

if the original GPT partition entry array starts at LBA different from 2 (this isn't the default layout), the attacker can simply force the recovery of a small "new" array occupying one sector only (which is going to be written to LBA 2); if the original GPT partition entry array starts at LBA 2 (this is the default layout), the attacker can force the recovery of a larger (containing more sectors) array starting with the same entries as the original one (in this case, the attacker can covertly "append" entries into the existing partition entry array — the PartitionDxe driver will use a larger array, containing "new" entries, the DxeTpm2MeasureBootLib library will use a smaller array, without "new" entries); alternatively, if the attacker doesn't care about the final PCR[5] value but wants to bypass TPM-based attestation checks, the attacker can rewrite the "PartitionEntryLBA" field (hopefully, attestation checks don't care about its value) and move the GPT partition entry array to a different location, while keeping its contents intact (thus, allowing the recovery of a "new" array to LBAs 2+).

PoC

[SECTION REMOVED]

List of issues reported

For clarity, here is a list of all issues (including edge cases) mentioned before:

1. One possible TCG specification violation covering unused (empty) GPT partition entries. Such entries are ignored in the current code. 2. One failure to repair the invalid GPT header when the underlying drive is write-protected (e.g., it's a degraded RAID volume). 3. One logic error leading to the usage of untrusted (known to be invalid) values in the GPT header (because of a failed restore attempt when the "alternate LBA" field of the valid GPT header points beyond the end of the corresponding block device). 4. One vulnerability leading to the usage of a partition table other than measured.

Possible fixes

In general, the vulnerability reported is caused by two implementations of the GPT parser, something like:

1. ProcessPartitions(ParseGPT1(InputData)), 2. MeasurePartitions(ParseGPT2(InputData)).

Here, "InputData" is the same in two cases, but "ParseGPT1" and "ParseGPT2" are functions that parse that data in different ways, returning different results in unusual cases.

One solution is to implement stricter checks in the DxeTpm2MeasureBootLib library, stopping immediately if anything is wrong.

Another solution is to share the code between the PartitionDxe driver and the DxeTpm2MeasureBootLib library. Two implementations must be equal.

Attached files

[SECTION REMOVED]

EDK2 contains a vulnerability in BIOS where an attacker may cause “Exposure of Sensitive Information to an Unauthorized Actor” by local access. Successful exploitation of this vulnerability will lead to

possible information disclosure or escalation of privilege

and impact Confidentiality.

The Ubuntu edk2 UEFI firmware packages accidentally allowed the UEFI Shell to be accessed in Secure Boot environments, possibly allowing bypass of Secure Boot constraints. Versions 2024.05-2ubuntu0.3 and 2024.02-2ubuntu0.3 disable the Shell. Some previous versions inserted a secure-boot-based decision to continue running inside the Shell itself, which is believed to be sufficient to enforce Secure Boot restrictions. This is an additional repair on top of the incomplete fix for CVE-2023-48733.

It was discovered that EDK II did not check the buffer length in XHCI, which could lead to a stack overflow. A local attacker could potentially use this issue to cause a denial of service. This issue only affected Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2019-0161) Laszlo Ersek discovered that EDK II incorrectly handled recursion. A remote attacker could possibly use this issue to cause EDK II to consume resources, leading to a denial of service. This issue only affected Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2021-28210) Satoshi Tanda discovered that EDK II incorrectly handled decompressing certain images. A remote attacker could use this issue to cause EDK II to crash, resulting in a denial of service, or possibly execute arbitrary code. This issue only affected Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2021-28211) It was discovered that EDK II incorrectly decoded certain strings. A remote attacker could use this issue to cause EDK II to crash, resulting in a denial of service, or possibly execute arbitrary code. This issue only affected Ubuntu 16.04 LTS and Ubuntu 18.04 LTS. (CVE-2021-38575) It was discovered that EDK II had integer underflow vulnerability in SmmEntryPoint, which could result in a buffer overflow. An attacker could potentially use this issue to cause a denial of service. (CVE-2021-38578) Elison Niven discovered that OpenSSL, vendored in EDK II, incorrectly handled the crehash script. A local attacker could possibly use this issue to execute arbitrary commands when crehash is run. This issue only affected Ubuntu 16.04 LTS. (CVE-2022-1292)

An insecure default to allow UEFI Shell in EDK2 was left enabled in LXD. This allows an OS-resident attacker to bypass Secure Boot.

An insecure default to allow UEFI Shell in EDK2 was left enabled in Ubuntu's EDK2. This allows an OS-resident attacker to bypass Secure Boot.

https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html https://github.com/advisories/GHSA-3r3p-444m-2g4p

https://blog.quarkslab.com/pixiefail-nine-vulnerabilities-in-tianocores-edk-ii-ipv6-network-stack.html https://github.com/tianocore/edk2/security/advisories/GHSA-hc6x-cw6p-gj7h

EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.

EDK2's Network Package is susceptible to a predictable TCP Initial Sequence Number. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.

EDK2's Network Package is susceptible to an out-of-bounds read vulnerability when processing the IANA or IATA option in a DHCPv6 Advertise message. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.

Buffer Overflow in EDK II Network Package

EDK2's Network Package is susceptible to an out-of-bounds read vulnerability when processing  Neighbor Discovery Redirect message. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality.

EDK2's Network Package is susceptible to a buffer overflow vulnerability when processing DNS Servers option from a DHCPv6 Advertise message. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.

EDK2's Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability.

EDK2's Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability.

Buffer Overflow in EDK II Network Package

EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-4hcq-p8q8-hj8j

EDK2 is susceptible to a vulnerability in the Tcg2MeasureGptTable() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-xvv8-66cq-prwr

EDK2 is susceptible to a vulnerability in the CreateHob() function, allowing a user to trigger a integer overflow to buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.

https://github.com/tianocore/edk2/security/advisories/GHSA-ch4w-v7m3-g8wx

EDK2 is susceptible to a vulnerability in the Tcg2MeasurePeImage() function, allowing a user to trigger a heap buffer overflow via a local network. Successful exploitation of this vulnerability may result in a compromise of confidentiality, integrity, and/or availability.