CVE-2024-0762: Phoenix SecureCore Buffer Overflow Flaw

CVE-2024-0762 Overview

CVE-2024-0762, dubbed "UEFIcanhazbufferoverflow," is a buffer overflow vulnerability in Phoenix SecureCore™ UEFI firmware affecting multiple Intel processor families. The flaw resides in unsafe handling of UEFI variables during boot, where an unchecked variable size can overflow a stack buffer. Eclypsium researchers disclosed the issue, which impacts firmware deployed across hundreds of consumer and enterprise device models built on Intel Kaby Lake through Meteor Lake platforms. Successful exploitation enables local code execution within the firmware context, below the operating system. The vulnerability falls under CWE-120: Buffer Copy without Checking Size of Input.

Critical Impact

A local attacker with privileged access can trigger a stack buffer overflow during UEFI execution to achieve code execution at the firmware level, enabling persistent implants that survive OS reinstalls.

Affected Products

• Phoenix SecureCore™ for Intel Kaby Lake (4.0.1.1 before 4.0.1.998), Coffee Lake (4.1.0.1 before 4.1.0.562), Ice Lake (4.2.0.1 before 4.2.0.323), and Comet Lake (4.2.1.1 before 4.2.1.287)
• Phoenix SecureCore™ for Intel Tiger Lake (4.3.0.1 before 4.3.0.236), Jasper Lake (4.3.1.1 before 4.3.1.184), and Alder Lake (4.4.0.1 before 4.4.0.269)
• Phoenix SecureCore™ for Intel Raptor Lake (4.5.0.1 before 4.5.0.218) and Meteor Lake (4.5.1.1 before 4.5.1.15)

Discovery Timeline

• 2024-05-14 - CVE-2024-0762 published to NVD
• 2025-09-29 - Last updated in NVD database

Technical Details for CVE-2024-0762

Vulnerability Analysis

The vulnerability exists in Phoenix SecureCore™ UEFI firmware code that processes a specific UEFI variable during the Driver Execution Environment (DXE) phase. The firmware reads variable data into a fixed-size stack buffer without validating that the supplied length fits the destination. When the variable contains attacker-controlled data exceeding the buffer size, the copy operation overwrites adjacent stack memory, including saved return addresses and control structures.

Because the flaw is exercised before or during operating system handoff, exploitation grants execution in System Management Mode-adjacent firmware context. An attacker capable of writing the targeted NVRAM variable from a privileged OS context can stage payloads that persist across reboots and reimaging. This class of issue is tracked as CWE-120: Classic Buffer Overflow.

Root Cause

The root cause is missing bounds checking on the size argument used in a memory copy when parsing a UEFI variable. The vulnerable routine trusts the variable length retrieved from non-volatile storage rather than enforcing the static size of the destination buffer. This pattern violates safe firmware coding practices and is described in detail in the Eclypsium research disclosure.

Attack Vector

The attack vector is local. An attacker who has already obtained elevated privileges on the host can write a malformed UEFI variable to NVRAM using standard operating system interfaces such as SetVariable runtime services. On the next firmware execution path that reads this variable, the overflow triggers and control can be redirected into attacker-supplied data. The flaw cannot be reached remotely without an existing foothold on the device.

The vulnerability is described in the Phoenix security advisory for CVE-2024-0762. No verified public proof-of-concept exploit was available at the time of writing.

Detection Methods for CVE-2024-0762

Indicators of Compromise

• Unexpected modifications to UEFI NVRAM variables, particularly variables with oversized data fields written from user-mode tools.
• Firmware version strings matching vulnerable Phoenix SecureCore™ builds listed in the advisory, observable via wmic bios get smbiosbiosversion on Windows or dmidecode -s bios-version on Linux.
• Unsigned or unexpected DXE drivers, boot loader changes, or measured boot log entries that differ from the known-good baseline.

Detection Strategies

• Inventory firmware versions across the fleet and correlate against the affected version ranges published by Phoenix Technologies and OEM partners.
• Use platform integrity tooling such as CHIPSEC or vendor-provided firmware attestation to detect tampering with SPI flash and NVRAM regions.
• Monitor privileged process activity that invokes UEFI variable APIs, including calls to SetFirmwareEnvironmentVariable on Windows and efivar/efibootmgr on Linux.

Monitoring Recommendations

• Forward firmware telemetry, Secure Boot state, and TPM PCR measurements to a centralized log platform for baselining and anomaly detection.
• Alert on writes to non-standard UEFI variable names by non-administrative processes or outside of patch windows.
• Track endpoints that fail platform attestation or report unexpected firmware version downgrades.

How to Mitigate CVE-2024-0762

Immediate Actions Required

• Identify all systems running Phoenix SecureCore™ firmware on affected Intel platforms from Kaby Lake through Meteor Lake.
• Apply OEM-provided firmware updates that incorporate the Phoenix patched SecureCore™ builds at or above the fixed versions listed in the advisory.
• Restrict local administrative access, since exploitation requires elevated privileges on the host operating system.

Patch Information

Phoenix Technologies released fixed SecureCore™ builds for each affected Intel platform generation. Customers must obtain updated firmware from their device OEM, since UEFI images are integrated and signed at the OEM level. Refer to the Phoenix security notification for CVE-2024-0762 and the Eclypsium technical write-up for the complete list of fixed versions per platform.

Workarounds

• Enforce least privilege so that standard users cannot invoke UEFI variable write APIs or load unsigned drivers.
• Enable Secure Boot, BIOS administrator passwords, and measured boot to limit pre-OS tampering and improve detection of firmware changes.
• Where firmware updates are not yet available from the OEM, isolate affected high-value systems and monitor for privileged write activity to UEFI variables.

# Identify firmware version on Linux to determine exposure
sudo dmidecode -s bios-vendor
sudo dmidecode -s bios-version
sudo dmidecode -s bios-release-date

# List UEFI variables and watch for unexpected entries
sudo efivar -l | sort