Loading story…
Binarly identified inconsistent and outdated UEFI Secure Boot revocation databases distributed by Microsoft, the UEFI Forum, and the Linux Vendor Firmware Service (LVFS), undermining protection against known bypasses. The investigation followed ESET’s disclosure of CVE-2024-7344, a vulnerability in a Microsoft-signed Howyar Technologies UEFI application that can execute unsigned code despite Secure Boot. Binarly found that the UEFI Forum’s revocation list had lacked entries associated with publicly known bypasses for approximately six months, leaving systems relying on that list exposed.
The findings extended to firmware supply chains: 3,137 of 5,331 recently released firmware images—approximately 59%—contained outdated revocation databases, and Binarly identified discrepancies between revocation metadata and binary updates. Although the three distribution sources matched by January 21, 2025, that alignment did not establish that deployed systems had received the necessary revocations. Organizations should verify installed Secure Boot revocations rather than assume firmware recency ensures protection. Binarly also recommended coordinated vulnerability disclosures and revocation updates, alongside a single authoritative revocation source.
See affected versions and whether adversaries are exploiting it.
11 events from the most recent confirmed update back to the earliest known activity.
By January 21, Binarly confirmed that the revocation-list contents distributed by Microsoft, the UEFI Forum, and LVFS matched.
Binarly reported that the UEFI Forum had distributed an outdated dbx for approximately six months and found outdated databases in 3,137 of 5,331 recently released firmware images. Its investigation also identified discrepancies between revocation metadata and binary updates, including 61 architecture inconsistencies assessed as posing no security risk.
Binarly observed corrected UEFI Forum files at approximately 19:00 UTC, following its discovery of missing revocations.
The UEFI Forum website claimed its x86 and x64 files had been updated on January 14 to address CVE-2024-7344. Binarly found no corresponding vulnerable-application entries in either the binary files or the informational CSV.
Microsoft released signed Secure Boot revocation database updates addressing the vulnerable Howyar Technologies application.
ESET disclosed CVE-2024-7344 in a Howyar Technologies UEFI application signed with Microsoft’s third-party UEFI certificate. The vulnerability permits loading and executing unsigned code, breaking the Secure Boot chain of trust.
Microsoft issued a security bulletin for CVE-2024-7344, and CERT/CC released vulnerability note VU#529659.
Microsoft added information about Howyar Technologies’ Reloader.efi to its public microsoft/secureboot_objects GitHub repository. Binarly warned that this potentially alerted attackers before the signed revocation update became available.
Microsoft published DBX2024 packages covering CVE-2024-28924 in SecurStar modules and CVE-2024-23593 in LenovoBT.efi, but Binarly later found their revocation information in the CSV metadata rather than the binary dbx. The UEFI Forum did not incorporate the update.
Microsoft and the UEFI Forum published dbx version 371 to address BlackLotus, which exploited CVE-2022-21894 in the Windows UEFI bootloader. LVFS began distributing the update on the same day.
In 2022, the UEFI Forum mistakenly added ordinary SHA-256 hashes rather than Authenticode hashes for two vulnerable drivers. ESET subsequently found that the error left known Secure Boot bypasses unblocked for more than a year.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
See whether adversaries are exploiting this yet, and where the affected versions run in your environment.
3 references tracked. Mallory keeps watching after this page renders.
binarly.io
Open sourcewelivesecurity.com
Open sourceuefi.org
Open sourceMap indicators from this story to your assets and identify affected systems in minutes.
Every observed campaign, victim, and pivot linked to actors named in this story.
Malware, exploits, and IOCs connected to the activity described here.
YARA, Sigma, and Snort rules deployed to your SIEM as soon as they’re published.
Get matching new stories delivered to your team as they break — not the next morning.
Ask questions about this story and take action on the answers.
Other stories Mallory is tracking that overlap on entities, sources, or topic labels.
Researchers from Eclypsium discovered that nearly 200,000 Linux-based Framework laptops and desktops were shipped with signed UEFI shell components containing a powerful 'memory modify' (mm) command, which can be exploited to bypass Secure Boot protections. The mm command, intended for low-level diagnostics and firmware debugging, provides direct read and write access to system memory, including critical security variables such as gSecurity2. By abusing this command, an attacker can overwrite the gSecurity2 variable with NULL, effectively disabling signature verification for all subsequent UEFI module loads and breaking the Secure Boot trust chain. This vulnerability allows attackers to load bootkits such as BlackLotus, HybridPetya, and Bootkitty, which can evade operating system-level security controls and persist even after OS reinstallation. The attack can be automated using startup scripts, ensuring persistence across reboots. The issue is not the result of a supply chain compromise or malicious intent, but rather an oversight in the inclusion of diagnostic tools signed with trusted certificates. Eclypsium's research highlights that these signed UEFI shells, while legitimate, function as backdoors that undermine the security model of Secure Boot. The presence of such tools in production devices exposes users to significant risk, as attackers can leverage them for pre-OS infections, espionage, sabotage, or ransomware attacks. The gaming industry has already seen commercial cheat providers exploiting similar UEFI-level bypasses, and the same techniques could be adopted by nation-state actors or advanced persistent threats. Framework has acknowledged the issue and is working on remediation, with fixes planned for affected models such as the Framework 13 (11th and 12th Gen Intel). The discovery underscores the broader risk of trusted, signed components containing powerful functionality that can be misused, and the need for rigorous review of firmware-level tools included in shipping devices. The vulnerability demonstrates that even systems marketed as secure and repairable can harbor critical flaws if diagnostic utilities are not properly restricted. The incident serves as a warning to hardware manufacturers and the security community about the dangers of trusted but overly permissive firmware components. Eclypsium's findings have prompted a reassessment of trust models in firmware security, emphasizing the importance of minimizing attack surfaces in pre-boot environments. The case also illustrates how attackers are increasingly targeting lower layers of the computing stack to achieve persistence and evade detection. Framework's response and the ongoing remediation efforts will be closely watched by the industry as a test case for responsible disclosure and mitigation of firmware-level threats.
Jul 23, 2026
ESET disclosed that **11 outdated Microsoft-signed Linux `shim` bootloaders** could be abused to bypass **UEFI Secure Boot** on systems that trust the **Microsoft Corporation UEFI CA 2011** certificate. The issue affects UEFI-based machines regardless of installed operating system because an attacker can introduce an old but still-trusted signed binary even if the device never originally shipped with it. Researchers said the vulnerable shims can trust insecure second-stage loaders such as **GRUB 2**, lack later protections including **MOK denylist enforcement** and **SBAT** support, and could let an attacker with administrative access or boot-process control run arbitrary code during early boot and install persistent UEFI bootkits such as **BlackLotus**, **Bootkitty**, or **HybridPetya**.
Aug 11, 2026
Microsoft published Security Update Guide entries for **`CVE-2024-49114`** and **`CVE-2022-21899`**, identifying Windows security weaknesses that could allow a **security feature bypass**. One of the referenced advisories explicitly describes **`CVE-2022-21899`** as a **Windows Extensible Firmware Interface Security Feature Bypass Vulnerability**, pointing to risk in the platform’s boot and firmware trust chain. The available references provide limited technical detail, but both entries indicate Microsoft formally tracked and disclosed the issues through its Security Update Guide and advisory portal. For defenders, the disclosures highlight the need to review Microsoft guidance for affected Windows and firmware-related components, validate patch status, and prioritize systems where bypassing built-in protections could weaken secure boot or other platform security controls.
Jul 12, 2026