EN PT-BR
← Voltar ao feed
high technology data_center

CVE-2026-97631: Critical 16-Year-Old EDK II PXE Driver Flaw Enables Pre-OS Code Execution; Fix Merged Upstream but No Stable Release

4 fonte(s) · 4 atualização(ões) · publicado 28/10/2026 05:46 · coletado há 4 dias

A critical buffer overflow, tracked as CVE-2026-97631 (CVSS 9.5 per securityaffairs.com and thehackernews.com), affects the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) in TianoCore EDK II. An unauthenticated attacker who can send a unicast ICMP error message to a host that is PXE-booting could corrupt firmware memory and potentially run code in the DXE phase, before any OS security controls load. TianoCore published its advisory on October 22, 2026 and lists EDK II master as affected as of September 14, 2026. Fixes were merged in pull request #13302 on October 15, 2026, but no stable EDK II release contains them yet and the advisory still lists the patched version as "Not patched currently" (thehackernews.com). Availability in individual vendor firmware is a separate question. No exploitation in the wild is reported, and the flaw was not in CISA's KEV catalog as of October 27 (thehackernews.com).

securityaffairs.com adds that the bug is 16 years old and that EDK II is used by major UEFI vendors such as AMI, Insyde and Phoenix, and by Microsoft's Project Mu. Researchers planned to disclose in January, but an AMI fix published last month revealed the details, after which TianoCore issued a public warning. thehackernews.com specifies that a September 28 pull request signed off by an AMI engineer described the flaw by CVE number and included the fix, which led TianoCore to publish its advisory early. Attackers can now study the fix to develop exploits, while firmware updates across many devices could take a long time. wired.com (Ars Technica) notes that virtually all independent BIOS vendors use the EDK2 reference code, which a UEFI Forum representative called the "preeminent" implementation of the UEFI specifications, and that the leak came six days after another botched disclosure involving a critical PHP vulnerability (wired.com). Intel says none of its commercially supported products are known to be affected and that its reference code does not include the affected functionality, though an OEM could add it (thehackernews.com, citing Ars Technica). wired.com adds that Intel's public reference code and TianoCore documents still reference EDK2. Arm says the flaw is not directly applicable to it, although wired.com notes that Arm's firmware also borrows heavily from EDK2. AMD, Phoenix, AMI, Microsoft, Amazon and TianoCore did not respond, so which devices are affected remains unclear. The flaw was disclosed with credit to Alex Matrosov (Anthropic) and Dan Holmes (Google) (wired.com; the earlier report gave the surname as Holmes-Mitra).

Entenda a falha

A vulnerabilidade

CVE-2026-97631 (CVSS 9.5) is a critical buffer overflow in the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) of TianoCore EDK II. The affected code has been there since a November 2010 commit. An unauthenticated attacker who can deliver a unicast ICMP error (IPv4 or IPv6) to a host that is actively PXE-booting can corrupt DXE-phase memory. The usual result is a hung boot. With an exploit tuned to the exact firmware build, the attacker can run code at ring 0 before Secure Boot or the OS loads. Red Hat and SUSE rate the vector as adjacent network, and the realistic attacker is an insider or someone with a foothold on the local network. Affected: EDK II up to edk2-stable202608, with PXE on by default. No stable release has the fix, and Red Hat 8/9/10, SUSE and Debian edk2 packages are listed as affected and unfixed.

Como funciona

During a network boot, the PXE driver keeps a receive request open for ICMP error messages. When one arrives, the handler (PxeBcIcmpErrorDpcHandle for IPv4, PxeBcIcmp6ErrorDpcHandle for IPv6) copies the data into the fixed 504-byte field Mode.IcmpError in the driver's private context. If the message comes in fragments, a loop advances the destination pointer. This is where it goes wrong: messages longer than 504 bytes are still copied, and the pointer moves by the cumulative length instead of the current fragment's length. Attacker-controlled bytes therefore land in adjacent memory, and nothing earlier on the receive path limits the size. The corrupted driver data can cause a CPU exception in the DXE core when another ICMP error arrives. That is the hang scenario.

Por que é vulnerável

The root cause is missing boundary enforcement on a copy into a fixed-size buffer, combined with a wrong offset calculation in the fragment loop (cumulative length instead of per-fragment length). Turning the corruption into code execution is much harder: the advisory says an attacker who knows the firmware build can forge an event so that CoreSignalEvent() runs attacker instructions, and Eclypsium's Jesse Michael says addresses must be guessed per model, version and configuration. The fix corrects the boundary checks and offsets, truncates oversized messages at 504 bytes and clears the ICMP error buffer before copying new fragments. New unit tests for fragment packing, truncation and TFTP buffer integrity failed before the fix and passed after. Fuzzing projects started after PixieFail did not catch this bug, per Ars Technica.

Onde está

The flaw is in NetworkPkg/UefiPxeBcDxe, in PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle, which write into Mode.IcmpError. The fix was merged into EDK II master through pull request #13302 on October 15, 2026.

Como foi descoberta

The advisory credits Alex Matrosov (Anthropic) and Dan Holmes-Mitra of Google; Wired/Ars gives the surname as Holmes, probably the same person. The articles do not say how they found the bug. A coordinated disclosure was planned for January 2027. On September 28, a pull request signed off by an AMI engineer publicly described the flaw by CVE number and included the fix. The discoverers saw it, and TianoCore published its advisory early, on October 22. The upstream merge came on October 15, and Project Mu cut tagged builds with the fix on October 26. No exploitation has been reported, and it was not in CISA KEV as of October 27. Ars notes that attackers can now study the public fix to build exploits.

Explicação gerada por IA a partir da matéria e dos artigos, em 28/10/2026 18:18.

Detalhes técnicos

  • The driver copies received ICMP error data into a fixed 504-byte field, Mode.IcmpError, in its private context.
  • PxeBcIcmpErrorDpcHandle (IPv4) and PxeBcIcmp6ErrorDpcHandle (IPv6) do not enforce copy boundaries, so messages larger than 504 bytes are still copied.
  • The fragment-handling loop advances the destination pointer by the cumulative length rather than the current fragment's length, so attacker-controlled bytes overwrite adjacent memory.
  • The flawed copy loop has been in the code since a commit in November 2010 (thehackernews.com).
  • Affected versions: EDK II up to and including edk2-stable202608 (August 21), the newest stable release. PXE boot is enabled by default in the standard build (thehackernews.com, wired.com).
  • Exploitation requires the target to be actively PXE-booting and reachable by an attacker who can deliver a unicast ICMP error to its IP address, which wired.com says can be sent from any network distance. No authentication or user interaction is needed, and exposure is limited to the network-boot window.
  • Outcome 1: deterministic corruption of private driver data can trigger a CPU exception in the DXE core when another ICMP error arrives, hanging the boot and disrupting provisioning or recovery.
  • Outcome 2: an attacker who knows the target firmware build could craft a counterfeit event so that CoreSignalEvent() executes attacker-supplied instructions during DXE, at ring 0, also bypassing attestation (securityaffairs.com). Code execution is far less reliable than the crash and needs an exploit built for a specific firmware build (thehackernews.com). Jesse Michael (Eclypsium) says the attacker must guess specific addresses, so the exploit must be tuned for each target model, version and configuration and cannot be thrown at diverse devices (wired.com).
  • The attacker needs some control over the local network, such as an insider or an intruder with an existing foothold. Red Hat and SUSE rate the vector as adjacent network (thehackernews.com). There is no evidence the flaw can be used for initial access from outside. The injected code does not persist but could help install other early-boot components. HD Moore (Dragos) says it could expose the TPM and break disk encryption with short-term network access or in a theft scenario, and expects a "forever" bug that will live on in end-of-support systems (thehackernews.com, wired.com).
  • Affected systems are those booting over the network with EDK2-based firmware and PXE enabled, mainly servers and data center equipment. Home and small-office users and disk-only boot are not affected.
  • Linux distributions: Red Hat lists the edk2 package in RHEL 8, 9 and 10 as affected and not fixed, and SUSE and Debian mark their packages the same way (thehackernews.com).
  • The issue follows the earlier PixieFail flaws (nine flaws, January 2024) in EDK II's network-boot code. Fuzzing projects started after PixieFail did not catch this bug (thehackernews.com). wired.com also lists LogoFail, PKFail, BootHole, BlackLotus and Baton Drop as earlier UEFI flaws.

Remediação

  • The upstream patch fixes the boundary checks and offset calculations, truncates oversized messages at 504 bytes when the buffer is full, and clears the ICMP error buffer before copying new fragments.
  • Added unit tests cover IPv4 and IPv6 fragment packing, truncation and TFTP buffer integrity. Maintainers reported they failed before the fix and passed after.
  • Project Mu has pulled the fix into its release branches and cut tagged builds on October 26 (thehackernews.com).
  • No stable EDK II release contains the fix as of October 28, and the advisory lists no workaround. Operators must wait for BIOS/UEFI updates from their firmware makers (thehackernews.com).
  • Organizations should distinguish upstream remediation from vendor firmware availability when assessing exposure and planning updates.
  • Contact system or firmware suppliers, disable network boot (PXE) where it is not needed, and monitor boot-time network traffic and logs for suspicious activity. TPM and Secure Boot remain useful but do not stop this attack (securityaffairs.com, wired.com).
  • Jesse Michael (Eclypsium) notes that the fix is a basic code change and needs no certificate or key revocations, PK/KEK/db/dbx key updates or OS and provisioning media updates, unlike BootHole, BlackLotus or Baton Drop (thehackernews.com, wired.com).

Relatos divergentes

  • Fix timing: the earlier report cites the TianoCore upstream merge on October 15, 2026, while securityaffairs.com says an AMI fix published last month (September) exposed the details ahead of the planned January disclosure. thehackernews.com, the more detailed and more recent source, reconciles the two: a September 28 pull request signed off by an AMI engineer publicly disclosed the CVE and the fix, and the merge into the main branch came on October 15. The advisory followed on October 22.
  • Attacker position: the earlier report describes an unauthenticated attacker able to send a unicast ICMP error; securityaffairs.com and wired.com say this can be done from any network distance but requires some control over the local network, and show no evidence of external initial access. thehackernews.com says Red Hat and SUSE rate the vector as adjacent network, not across the open internet. The adjacent-network framing is the more recent and more specific one.
  • Discoverer's name: earlier sources give Dan Holmes-Mitra (Google), while wired.com (Ars Technica) gives Dan Holmes. It is likely the same person; the surname is unverified.

Linha do tempo

  1. wired.com ↗ · pub. 28/10/2026 17:30 · coletado 28/10 18:01

    CVE-2026-97631: 16-Year-Old EDK2 PXE Driver Overflow Exposes Most Servers to Pre-OS Code Execution After Botched Disclosure

    Ars Technica's report, republished on wired.com, adds the firmware-vendor context (Project Mu, IBVs), Eclypsium's point that exploitation needs per-target address tuning, Moore's "forever bug" assessment, Intel's and Arm's positions with the caveat that both draw on EDK2, and the fact that the disclosure leak came six days after another botched disclosure (PHP). It names the discoverer as Dan Holmes, whereas the case report says Holmes-Mitra.

    ler a análise desta fonte

    Ars Technica's report, republished on wired.com, adds the firmware-vendor context (Project Mu, IBVs), Eclypsium's point that exploitation needs per-target address tuning, Moore's "forever bug" assessment, Intel's and Arm's positions with the caveat that both draw on EDK2, and the fact that the disclosure leak came six days after another botched disclosure (PHP). It names the discoverer as Dan Holmes, whereas the case report says Holmes-Mitra.

    A memory-corruption flaw, CVE-2026-97631 (severity 9.5/10), in the ICMP handling of the PXE Base Code driver in TianoCore EDK II allows code execution before the OS and firmware defenses such as Secure Boot and TPM-based attestation come into play. EDK2 is the reference code used by virtually all UEFI suppliers, including AMI, Insyde and Phoenix, and by Microsoft's Project Mu. The bug was found by Alex Matrosov (Anthropic) and Dan Holmes (Google) and was due for coordinated disclosure in January, but an AMI pull request published last month included the fix and exposed the details, prompting TianoCore to issue an advisory early. Public patch code makes exploit development easier for advanced attackers, while fixing UEFI in millions of devices will be slow. Exploitation needs some control of the local network and per-target tuning, and no in-the-wild exploitation or initial-access use has been shown.

    Technical Details

    • The flaw is a 16-year-old buffer overflow in NetworkPkg/UefiPxeBcDxe. During PXE boot the driver listens for ICMP errors and copies each message into the fixed 504-byte field Mode.IcmpError.
    • The IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle, PxeBcIcmp6ErrorDpcHandle) still copy bytes when a message exceeds 504 bytes and advance the destination pointer by the cumulative rather than the per-fragment length, so attacker-controlled bytes overwrite adjacent data.
    • The malicious error can be delivered as a simple unicast to the target's IP address from any network distance, but only during the PXE boot sequence.
    • Outcomes: a denial of service (boot hang), or, if the attacker knows the firmware build, a counterfeit event that runs code in ring 0 in the UEFI environment, bypassing attestation. The final payload does not persist but can open the way to other early-boot payloads.
    • Jesse Michael (Eclypsium) says the attacker must guess specific addresses, so the exploit has to be tuned per model, version and configuration; a single exploit will not yield RCE across diverse devices.
    • HD Moore (Dragos) says hijacking flow while the boot process can still reach the TPM could break disk encryption with short-term network access, and more easily in a theft scenario. He expects a "forever" bug in end-of-support systems.
    • Prerequisite: some control over the local network (insider, or nation-state or ransomware operator with a foothold). There is no evidence yet of use as an initial entry point.
    • Only organizations that network-boot are affected, on EDK2-based firmware with PXE enabled (default). Home and small-office users and disk-only boot are not affected.
    • Related prior UEFI flaws: PixieFail (also PXE flaws in EDK2), LogoFail, PKFail, BootHole, BlackLotus, Baton Drop. Fuzzing projects launched after PixieFail missed this one.
    • Intel says no commercially supported products are known to be affected, but OEMs may integrate the code; its public reference code and TianoCore documents reference EDK2. Arm says the CVE is not directly applicable, though its firmware also draws on EDK2. AMD, Phoenix, AMI, Microsoft, Amazon and TianoCore did not respond.

    Remediation

    • Ask the firmware or system maker for guidance and deploy BIOS/UEFI updates when available. Michael notes the fix is a basic code change and needs no key revocations or DB/DBX updates, unlike Secure Boot bypasses such as BootHole.
    • Consider disabling network boot, at least temporarily.
    • Keep TPM and Secure Boot enabled, though they do not protect against this flaw.
    • Monitor logs for exploitation attempts.
  2. thehackernews.com ↗ · pub. 28/10/2026 08:50 · coletado 28/10 12:00

    Critical 16-year-old EDK II PXE flaw CVE-2026-97631 allows pre-Secure Boot code execution; no stable fix released yet

    The article adds the advisory date (October 22), the confirmation that no stable EDK II release contains the fix (edk2-stable202608 is the newest affected), the September 28 AMI-signed pull request that leaked the details, Project Mu's tagged fixed builds (October 26), the affected Linux distributions (Red Hat, SUSE, Debian), vendor statements, the November 2010 origin of the bug and the KEV status as of October 27.

    ler a análise desta fonte

    The article adds the advisory date (October 22), the confirmation that no stable EDK II release contains the fix (edk2-stable202608 is the newest affected), the September 28 AMI-signed pull request that leaked the details, Project Mu's tagged fixed builds (October 26), the affected Linux distributions (Red Hat, SUSE, Debian), vendor statements, the November 2010 origin of the bug and the KEV status as of October 27.

    A critical buffer overflow, CVE-2026-97631 (CVSS 9.5), affects the PXE network-boot code in TianoCore EDK II, the reference code behind most UEFI firmware. An attacker on an adjacent network who sends one crafted ICMP error message to a machine during a network boot can hang the boot or, with an exploit tailored to the exact firmware build, run code before Secure Boot and other startup defenses load. TianoCore published its advisory on October 22. A fix was merged into the main development branch on October 15, but no stable EDK II release contains it, so most users have nothing to install. No exploitation has been reported, and the flaw was not in CISA's KEV catalog as of October 27.

    Technical Details

    • The PXE driver copies ICMP error messages into a fixed 504-byte memory area. The size checks are wrong in both the IPv4 and IPv6 code paths, so longer messages overwrite adjacent memory.
    • The flawed copy loop has been in the code since a commit in November 2010 (The Hacker News traced the project history).
    • The simple outcome is a boot hang. Code execution requires knowing the exact firmware build, which lets the attacker plant a "counterfeit event". The injected code runs once and does not persist, but it can install other code that runs on every boot.
    • Affected: EDK II up to and including edk2-stable202608 (August 21). This covers the firmware of AMI, Insyde, Phoenix and Microsoft's Project Mu. PXE boot is enabled by default in the standard build. Machines booting only from a local disk are not affected; servers and data center equipment that boot over the network are.
    • Red Hat (RHEL 8, 9, 10 edk2 package), SUSE and Debian list their packages as affected and not yet fixed. Red Hat and SUSE rate the attack vector as adjacent network.
    • Intel says none of its commercially supported products are known to be affected, and Arm says the flaw is not directly applicable. AMD, Phoenix, AMI, Microsoft, Amazon and TianoCore did not respond, so their status is unclear.
    • Realistic attackers are insiders or intruders with a local network foothold. HD Moore (Dragos) notes the bug could expose the TPM and break disk encryption in short-term network access or theft scenarios.
    • It follows PixieFail (January 2024, nine flaws in the same EDK II network-boot code). Fuzzing projects started after PixieFail did not catch this bug.

    Remediation

    • The fix truncates oversized messages at 504 bytes. It reached the main branch on October 15. Project Mu pulled it into its release branches and cut tagged builds on October 26.
    • The advisory lists the patched version as "Not patched currently" and gives no workaround. Operators must wait for BIOS/UEFI updates from their firmware makers.
    • Disable PXE where it is not needed, and watch boot-time network traffic and logs for attempts.
    • The fix needs only a code change and no certificate or key revocations, unlike BootHole or BlackLotus (Jesse Michael, Eclypsium).
    • The patch is public, so skilled attackers can study it to build exploits.

    Disclosure

    The flaw was found by Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google). Disclosure was planned for January 2027, but a September 28 pull request signed off by an AMI engineer publicly described the CVE and the fix, so TianoCore published its advisory early.

  3. securityaffairs.com ↗ · pub. 28/10/2026 08:15 · coletado 28/10 10:00

    CVE-2026-97631: 16-Year-Old EDK II PXE Driver Overflow Enables Pre-OS Code Execution, Fix Details Leaked Early

    The article adds the CVSS score (9.5), the flaw's 16-year age, and the fact that an AMI fix published last month leaked details ahead of the planned January disclosure. It names AMI, Insyde, Phoenix and Project Mu as affected, says Intel and Arm are not directly affected, notes that the attacker needs a foothold on the local network, and gives mitigations (disable network boot, contact suppliers, monitor logs).

    ler a análise desta fonte

    The article adds the CVSS score (9.5), the flaw's 16-year age, and the fact that an AMI fix published last month leaked details ahead of the planned January disclosure. It names AMI, Insyde, Phoenix and Project Mu as affected, says Intel and Arm are not directly affected, notes that the attacker needs a foothold on the local network, and gives mitigations (disable network boot, contact suppliers, monitor logs).

    A critical flaw, CVE-2026-97631 (CVSS 9.5), affects the PXE Base Code driver in TianoCore EDK II, the open-source UEFI firmware base used by vendors such as AMI, Insyde and Phoenix, and by Microsoft's Project Mu. The bug is a 16-year-old buffer overflow that lets an attacker who can deliver ICMP error messages to a PXE-booting host execute code before the OS loads, ahead of Secure Boot and measured boot. Researchers planned to disclose in January, but an AMI fix published last month revealed the details, and TianoCore then issued a public warning. Attackers can study the fix to build exploits, while firmware updates across many devices may take a long time. No exploitation in the wild is reported, and there is no evidence the flaw gives initial access from outside the network.

    Technical Details

    • The flaw is in NetworkPkg/UefiPxeBcDxe, which copies ICMP error messages into the fixed 504-byte Mode.IcmpError field without enforcing the limit.
    • Both PxeBcIcmpErrorDpcHandle (IPv4) and PxeBcIcmp6ErrorDpcHandle (IPv6) mishandle bounds, and the destination pointer advances by cumulative length instead of per-fragment length.
    • Invalid data can halt boot (denial of service). An attacker who knows the firmware version can craft a fake event to run code at ring 0 and bypass attestation.
    • The attacker needs some control of the local network (insider or an intruder with a foothold). The injected code does not persist but could help install early-boot components.
    • Affected: systems booting over the network with EDK2-based firmware and PXE enabled. Home/small-office users and disk-only boot are not affected.
    • Intel and Arm say their own products are not directly affected, but manufacturers may have added vulnerable code. The full list of affected devices is unclear.

    Remediation

    • Contact system and firmware suppliers for patches.
    • Disable network boot where possible.
    • Monitor logs for suspicious activity.
    • TPM and Secure Boot remain useful but do not stop this attack.
  4. gbhackers.com ↗ · pub. 28/10/2026 05:46 · coletado 28/10 06:00 primeiro registro

    CVE-2026-97631: Critical EDK II PXE Driver Flaw Enables Pre-OS Code Execution via ICMP Error Packets

    ler a análise desta fonte

    A critical buffer overflow, tracked as CVE-2026-97631, affects the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) in TianoCore EDK II. An unauthenticated attacker who can send a unicast ICMP error message to a host that is PXE-booting could corrupt firmware memory and potentially run code in the DXE phase, before any OS security controls load. The advisory lists EDK II master as affected as of September 14, 2026. TianoCore merged fixes in pull request #13302 on October 15, 2026, but availability in individual vendor firmware is a separate question. The article does not report exploitation in the wild.

    Technical Details

    • The driver copies received ICMP error data into a fixed 504-byte field, Mode.IcmpError, in its private context.
    • PxeBcIcmpErrorDpcHandle (IPv4) and PxeBcIcmp6ErrorDpcHandle (IPv6) do not enforce copy boundaries, so messages larger than 504 bytes are still copied.
    • The fragment-handling loop advances the destination pointer by the cumulative length rather than the current fragment's length, so attacker-controlled bytes overwrite adjacent memory.
    • Exploitation requires the target to be actively PXE-booting and reachable by an attacker who can deliver a unicast ICMP error to its IP address. No authentication or user interaction is needed, and exposure is limited to the network-boot window.
    • Outcome 1: deterministic corruption of private driver data can trigger a CPU exception in the DXE core when another ICMP error arrives, hanging the boot and disrupting provisioning or recovery.
    • Outcome 2: an attacker who knows the target firmware build could craft a counterfeit event so that CoreSignalEvent() executes attacker-supplied instructions during DXE.
    • The issue follows the earlier PixieFAIL flaws in EDK II's IPv6 network stack.

    Remediation

    • The upstream patch fixes the boundary checks and offset calculations, truncates oversized messages when the buffer is full, and clears the ICMP error buffer before copying new fragments.
    • Added unit tests cover IPv4 and IPv6 fragment packing, truncation and TFTP buffer integrity. Maintainers reported they failed before the fix and passed after.
    • Organizations should distinguish upstream remediation from vendor firmware availability when assessing exposure and planning updates.
    • The article names no other mitigations. Limiting PXE boot to trusted network segments would reduce exposure, but this is general guidance, not from the article.

    The flaw was disclosed with credit to Alex Matrosov (Anthropic) and Dan Holmes-Mitra (Google).