Executive Summary

Title Vulnerabilities in EDK2 NetworkPkg IP stack implementation.
Name VU#132380 First vendor Publication 2024-01-16
Vendor VU-CERT Last vendor Modification 2024-03-04
Severity (Vendor) N/A Revision M

Security-Database Scoring CVSS v3

Cvss vector : CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
Overall CVSS Score 8.8
Base Score 8.8 Environmental Score 8.8
impact SubScore 5.9 Temporal Score 8.8
Exploitabality Sub Score 2.8
Attack Vector Adjacent Attack Complexity Low
Privileges Required None User Interaction None
Scope Unchanged Confidentiality Impact High
Integrity Impact High Availability Impact High
Calculate full CVSS 3.0 Vectors scores

Security-Database Scoring CVSS v2

Cvss vector :
Cvss Base Score N/A Attack Range N/A
Cvss Impact Score N/A Attack Complexity N/A
Cvss Expoit Score N/A Authentication N/A
Calculate full CVSS 2.0 Vectors scores



Multiple vulnerabilities were discovered in the TCP/IP stack (NetworkPkg) of Tianocore EDKII, an open source implementation of Unified Extensible Firmware Interface (UEFI). Researchers at Quarkslab have identified a total of 9 vulnerabilities that if exploited via network can lead to remote code execution, DoS attacks, DNS cache poisoning, and/or potential leakage of sensitive information. Quarkslab have labeled these set of related vulnerabilities as PixieFail.


UEFI represents a contemporary firmware standard pivotal in initiating the operating system on modern computers and in facilitating communication between the hardware and OS. TianoCore's EDKII stands as an open-source implementation adhering to UEFI and UEFI Platform Initialization (PI) specifications, offering an essential firmware development environment across platforms. Within EDKII, the NetworkPkg software encompasses a TCP/IP stack, enabling crucial network functionalities available during the initial Preboot eXecution Environment (PXE) stages. The PXE environment, when enabled, allows machines to boot via network connectivity, eliminating the need for physical interaction or keyboard access. Typically employed in larger data centers, PXE is vital for automating early boot phases, particularly in high-performance computing (HPC) environments.

Quarkslab researchers have discovered several vulnerabilities within the EDKII's NetworkPkg IP stack, introduce due to classic issues like buffer overflow, predictable randomization, and improper parsing. These vulnerabilities pose risks, allowing unauthenticated local attackers (and in certain scenarios, remotely) to execute various attacks. Successful exploits can result in denial of service, leakage of sensitive data, remote code execution, DNS cache poisoning, and network session hijacking. To successfully exploit this vulnerable NetworkPkg implementation, the attacker requires the PXE boot option to be enabled.

Tianocore's EDKII is used as a reference code or adopted as-is by many vendors for their UEFI implementation and distributed via supply-chain to other vendors in the PC market. Due to the widespread use of these libraries, these vulnerabilities may be present in a large number of implementations. We recommend users consult vendor specific advisory and details that will help resolve these issues.


The impact and exploitability of these vulnerabilities depend on the specific firmware build and the default PXE boot configuration. An attacker within the local network (and, in certain scenarios remotely) could exploit these weaknesses to execute remote code, initiate DoS attacks, conduct DNS cache poisoning, or extract sensitive information.


Apply updates

Update to the latest stable version of UEFI firmware that includes fixes to these vulnerabilities. Please follow the advisory and any details provided by your vendor as part of this advisory. Downstream users of Tianocore EDKII that incorporate NetworkPkg should update to the latest version provided by Tianocore project. Please follow any vendor provided recommended configurations that can limit the exposure of these vulnerabilities as suitable to your environment.

Enforce network security

In operations environments, you may consider the following workarounds to prevent exposure and potential exploitation of these vulnerabilities * Disable PXE boot if it is not used or supported in your computing environment. * Enforce Network Isolation so the UEFI Preboot environment is available to specific network that is protected from unauthorized access. * Deploy available protection to your computing environment from rogue DHCP services using capabilities such as Dynamic ARP inspection and DHCP snooping.

Employ secure OS deployments

Follow security best practices in design of the preboot environment that provide OS deployment capabilities to your organization. UEFI supply-chain vendors should also consider migration to modern network boot environments that employ secure protocols such as UEFI HTTPS Boot that can limit abuse of the legacy PXE boot related security issues.


Thanks to the Quarkslab for researching and reporting these vulnerabilities and support coordinated disclosure.

This document was written by Vijay Sarvepalli.

Original Source

Url : https://kb.cert.org/vuls/id/132380

CWE : Common Weakness Enumeration

% Id Name
43 % CWE-119 Failure to Constrain Operations within the Bounds of a Memory Buffer
29 % CWE-338 Use of Cryptographically Weak PRNG
29 % CWE-125 Out-of-bounds Read

CPE : Common Platform Enumeration

Application 14

Alert History

If you want to see full details history, please login or register.
Date Informations
2024-04-04 00:36:20
  • Multiple Updates
2024-04-03 21:36:16
  • Multiple Updates
2024-04-03 21:22:14
  • Multiple Updates
2024-03-21 13:38:21
  • Multiple Updates
2024-03-21 09:37:35
  • Multiple Updates
2024-03-19 21:22:16
  • Multiple Updates
2024-03-05 00:36:56
  • Multiple Updates
2024-03-04 21:36:51
  • Multiple Updates
2024-03-04 21:22:13
  • Multiple Updates
2024-02-21 21:37:05
  • Multiple Updates
2024-02-21 17:36:59
  • Multiple Updates
2024-02-21 17:22:15
  • Multiple Updates
2024-02-01 02:50:04
  • Multiple Updates
2024-02-01 00:37:08
  • Multiple Updates
2024-02-01 00:22:13
  • Multiple Updates
2024-01-23 21:38:34
  • Multiple Updates
2024-01-18 21:36:28
  • Multiple Updates
2024-01-18 21:22:14
  • Multiple Updates
2024-01-16 21:36:31
  • Multiple Updates
2024-01-16 17:22:14
  • First insertion