As recently as December 2025, the SEI’s CERT Coordination Center (CERT/CC) documented a UEFI-related vulnerability in certain motherboard models, illustrating that early-boot firmware behavior continues to present security challenges despite requiring local physical access to exploit. UEFI is a critical element of system firmware because it initializes hardware and boots up the operating system. Tampering with UEFI can support attacks that are particularly difficult to detect and mitigate.
This vulnerability is the most recent issue reported, but it is not an outlier. CERT/CC reported seven UEFI vulnerability notes in 2025. While small compared to reported vulnerabilities in other software, the consequences of a potential UEFI attack are often more serious given the extremely high privileges UEFI firmware possesses. Equally important, UEFI firmware is often large, complex, and opaque, which makes it challenging to analyze for security concerns.
At the SEI we have made the discovery and remediation of UEFI vulnerabilities a priority. In this blog post, we explore UEFI and introduce CERT UEFI Parser, a new, open source tool that uses program analysis to reveal the architecture of UEFI software, and explore this veiled source of vulnerabilities. The new parser is the result of that multiyear effort and supports output in human-readable text, JSON, and SBOM-ready JSON, making it well-suited to firmware audits, investigations, asset inventories, and automated workflows. upports output in human-readable text, JSON, and SBOM-ready JSON, making it well-suited to firmware audits, investigations, asset inventories, and automated workflows.
Why Do We Need a UEFI Parser?
The Unified Extensible Firmware Interface (UEFI) specification, started by Intel in 2004, is a community-driven project aimed at creating a common bootloader for all modern computing devices. It replaces the traditional Basic Input/Output System (BIOS) that previously had the role of starting the operating system when the hardware is powered up.
UEFI is a specification, and its implementation varies by vendor. Each vendor brings different approaches, custom data structures, and their own interpretations of specifications. This fragmentation yields an ecosystem with little uniformity and even less transparency because most code is proprietary. Bootloaders hold a sensitive position in computing architecture—they are the first layer of software between the hardware and the operating system. However, where there is software, there is the possibility for vulnerabilities and exploits.
CERT began developing the UEFI parser tool in early 2020 as part of our systemic vulnerability research initiative, where we set out to understand and protect some of the most invisible and difficult-to-manage ecosystems in modern computing. We use the term “systemic vulnerability” to describe a deeply embedded flaw that is pervasive across multiple systems, vendors, or implementations; difficult to detect or remediate due to complex dependencies and elusive root causes; and often dismissed as inherent to the system itself. The UEFI ecosystem exemplifies this definition. Firmware is hard to inspect, inconsistently documented, and challenging to manage across diverse hardware platforms, which makes vulnerabilities both difficult to discover and even more difficult to understand in terms of their broader impact.
Early research in UEFI vulnerabilities uncovered a labyrinth of data formats (both in terms of binary artifacts and their metadata) in virtual UEFI environments, each with their own unique structures and assumptions, along with many more complex custom formats that live outside traditional executable file formats, such as Microsoft’s Portable Executable (PE) or the Executable and Linkable Format (ELF) commonly used by Linux systems. These elements are often undocumented, highly vendor-specific, and outside the scope of existing tools (For more on existing tools see here and here). We also encountered challenges in understanding how vulnerabilities propagated across different projects. For example, when a flaw was disclosed in a specific firmware build, it was often unclear how much of the underlying code was reused in other UEFI projects. Without a consistent way to quickly parse and compare components, determining the list of affected models for a vulnerability was extremely difficult. It was soon obvious that we needed to develop a tool to scale our research; welcome, CERT UEFI Parser.
In reverse engineering, parsing and understanding binary file formats is an essential activity to recover the structure necessary to analyze and understand binary artifacts. Effective parsing must be efficient and accurate, incrementally decoding firmware binaries into higher-level structures that support exploration and analysis. Built on using such robust and extensible parsing frameworks, CERT UEFI Parser gives researchers, system administrators, and security enthusiasts a powerful and transparent way to inspect and analyze firmware. Its features include the capabilities to:
- Decompose firmware images, expose hidden structures, and support deeper reverse engineering and code-reuse analysis across the diverse UEFI landscape
- parse firmware ROMs, UEFI firmware images, PE files, installer packages, and more
- support output in human-readable text, JSON, and SBOM-ready JSON, making it well-suited to firmware audits, investigations, asset inventories, and automated workflows
The tool reflects years of accumulated research into how the firmware is constructed, how it varies across vendors, and how it can be analyzed more systematically.
Case Study: Investigating the PKFail Vulnerability
Consider the PKFail vulnerability, published in August 2024. In the PKFail vulnerability, Platform Keys (PKs) used in development and testing were mistakenly hardcoded into the production firmware for multiple vendors. These keys often included the label “DO NOT TRUST.”
Let’s walk through how someone might investigate a binary file to determine if it is victim to PKFail. We are using the Lenovo Thinkserver 140 ROM. As a start, let’s use the parsed file in JSON format so that we can search for strings, such as “DO NOT TRUST,” an attribute commonly encoded with hard-coded test software keys.
Figure 1: CERT UEFI Parser in JSON mode allows for searching by string
This finding is particularly noteworthy: the Lenovo ThinkServer firmware contains the string “DO NOT TRUST” embedded within the Platform Key (PK). To better understand where this originates, analyst can load the same firmware image into CERT UEFI Parser’s GUI view.
From the JSON output in Figure 1, we identify the PK as an X.509 DER certificate and use this class name to search in the GUI. As shown in Figure 2, the search locates the corresponding hex region containing the same “DO NOT TRUST” string.
Figure 2 CERT UEFI Parser in GUI mode supports searching by Class Name. A hex dump is displayed to the right of the parsed classes.
The decoded hexadecimal values in the bottom right of the image also read “DO NOT TRUST.” Zooming in:
Figure 3 A closeup of the hex dump in CERT UEFI Parser GUI mode
This examination process shows how CERT UEFI Parser can accurately visualize the internals of a UEFI ROM, expediting analysis and vulnerability discovery. A researcher could use CERT UEFI Parser to further examine ROMs either in an automated way using JSON output or interactively inspect using the GUI to inspect binary files such as firmware, installers and such.
The UEFI Ecosystem
Before UEFI was EFI, and before EFI was BIOS. In the BIOS-dominated era, limited standardization made it difficult to support increasingly complex and dynamic hardware environments. Intel created EFI to address this conflict, and UEFI is its “unified” successor bringing supply-chain parties and their interactions into some common reasonably defined interfaces.
UEFI standards were published to bring such uniformity to the system software layer that bridges hardware and operating systems, while still allowing for innovation and implementation flexibility. As these standards were adopted, the UEFI community emerged under the Unified Extensible Firmware Interface Forum as a loose collaboration of silicon vendors, platform manufacturers, firmware developers, operating system vendors, and tool builders who collectively interpret, implement, and extend the specification.
In practice, the UEFI ecosystem is not a single implementation, but a wide collection of firmware codebases, configuration choices, and vendor-specific extensions deployed across globally manufactured systems. While common interfaces enable interoperability, real-world implementations vary significantly due to differing design priorities, legacy requirements, and levels of engineering rigor.
This variability creates an environment where correctness and security cannot be assumed. Misinterpretations of the specification, subtle defects, configuration errors, and unintended interactions may exist below the operating system’s visibility, particularly in security-sensitive paths. For this reason, systematic analysis and reverse engineering of UEFI implementations by security evaluators remain necessary to understand actual behavior, identify gaps, and validate security assumptions across the broader UEFI ecosystem.
Future UEFI work at the SEI
CERT UEFI Parser is at a transition stage, and its future is largely dependent on community engagement in the form of feedback, feature requests, and direct contributions. Improving UEFI transparency requires sustained, collaborative effort. We encourage readers to visit our GitHub page, explore the parser, share feedback, request new features, or contribute improvements through pull requests; such participation will help us refine and expand the tool, bringing greater maturity and visibility to firmware analysis across the ecosystem.
The SEI continues to use the parser for research in systemic vulnerabilities, in addition to our work building tools and techniques to help cybersecurity professionals evaluate UEFI security weaknesses. The complex, opaque, and privileged nature of UEFI firmware remains an underappreciated source of risk that warrants increased scrutiny.