CVE-2024-0762 is a high severity (CVSS 7.5) buffer overflow in unsafe UEFI variable handling in Phoenix SecureCore firmware for select Intel platforms. Fixed builds exist for each platform family, so ask your hardware vendor for a firmware update that includes the Phoenix fix, then apply it.
What's affected
Phoenix SecureCore for select Intel platforms. The record lists these ranges, each with a first fixed build at the upper bound:
- Kaby Lake: from 4.0.1.1 before 4.0.1.998
- Coffee Lake: from 4.1.0.1 before 4.1.0.562
- Ice Lake: from 4.2.0.1 before 4.2.0.323
- Comet Lake: from 4.2.1.1 before 4.2.1.287
- Tiger Lake: from 4.3.0.1 before 4.3.0.236
- Jasper Lake: from 4.3.1.1 before 4.3.1.184
- Alder Lake: from 4.4.0.1 before 4.4.0.269
- Raptor Lake: from 4.5.0.1 before 4.5.0.218
- Meteor Lake: from 4.5.1.1 before 4.5.1.15
The CPE data also lists many Intel Celeron and other client processors as affected hardware. SecureCore is a firmware base, so the version you can see is usually your device maker's firmware release, not a Phoenix build number.
The record classifies the weakness as CWE-120 (buffer copy without checking the size of input). NVD scores it 7.5 (High) with the vector CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H.
How to check if you're exposed
Firmware versions are not visible to a package manager. On Windows, open System Information and read the BIOS Version field, or run wmic bios get smbiosbiosversion. On Linux, run sudo dmidecode -s bios-version. Record the value for each model and compare it with your device vendor's bulletin for this CVE, because vendors map their own release numbers to the Phoenix build.
What to do now
- Identify which devices run Phoenix SecureCore. Your device or laptop maker can tell you which firmware base a model uses.
- Check the Phoenix security notice for CVE-2024-0762 and your device vendor's own bulletin for the firmware version that includes the fix.
- Schedule the firmware update through the vendor's normal tooling. Firmware updates need a reboot and sometimes a BIOS password, so plan the window.
- Where no update exists for an older model, record it as an accepted risk with an owner, and tighten who can run code locally on that device.
Why it matters
UEFI firmware runs before the operating system, so a memory safety bug there sits below most security tooling. The weakness class is CWE-120, a copy into a buffer without checking the input size. The record describes unsafe handling of UEFI variables as the location.
Firmware is hard to patch at scale because the fix has to travel from Phoenix to the device maker to you. That chain is the reason to start the inventory question early. The record's attack vector is network, with high complexity, while firmware issues often need a foothold first, so read the vendor notice for the real precondition.
The record does not mark this CVE as being in the CISA Known Exploited Vulnerabilities catalog, and nothing in the record says it is exploited in the wild. That can change, so keep it on your watch list.
Quick check
Can a dependency scanner find this?
Not directly. Firmware is not a package in a lockfile. You need a hardware and firmware inventory, and the vendor bulletin for each model.
Sources
The links below are the references listed in the CVE record. The record and its description were the basis for this post, and the vendor advisory remains the authority for fixed versions.
- eclypsium.com
- news.ycombinator.com
- phoenixtech.com
- www.phoenix.com
- Safeguard Gold entry for CVE-2024-0762
Last reviewed: 19 October 2026.
