Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
3 events from the most recent confirmed update back to the earliest known activity.
Researchers disclosed that eleven outdated Microsoft-signed UEFI shim bootloaders could be abused to bypass UEFI Secure Boot on systems trusting the Microsoft Corporation UEFI CA 2011 certificate. The disclosures said the issue could enable arbitrary code execution during early boot and facilitate persistent UEFI bootkits.
The Hacker News reports that ESET responsibly disclosed the Secure Boot bypass issue involving outdated Microsoft-signed UEFI shim bootloaders to Microsoft in February 2026. The flaws were later tracked as CVE-2026-8863 and CVE-2026-10797.
Microsoft revoked the affected outdated shim bootloader hashes in its June 9, 2026 Patch Tuesday update via the DBX revocation list. The update addressed the Secure Boot bypass risk posed by eleven old Microsoft-signed shim bootloaders.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
7 references tracked. Mallory keeps watching after this page renders.
scworld.com
Open sourcearstechnica.com
Open sourcecybersecuritynews.com
Open sourcewelivesecurity.com
Open sourcehelpnetsecurity.com
Open sourcethehackernews.com
Open sourcegithub.com
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.
Fedora warned that older Microsoft-signed `Shim` bootloaders used to start Linux under UEFI Secure Boot can remain trusted long after fixes are available, allowing vulnerable components to load unless their signatures are added to the UEFI `DBX` revocation list. The warning highlights legacy `Shim 0.9` builds from 2016 and ties the risk to **CVE-2026-8863** and **CVE-2026-10797**, which could let attackers bypass Secure Boot protections on systems still relying on outdated binaries. Fedora said an updated Shim with additional protections is already present in Rawhide for Fedora 45, while Microsoft is expected to enforce broader revocations through the UEFI `DBX`. Users were urged to verify whether Secure Boot systems still depend on old Microsoft-signed Shim binaries and to update affected components, with older platforms such as **RHEL 7.2**, **CentOS 7.2**, **Oracle Linux 7.2**, **ROSA Linux R10/R9**, and some **openSUSE** installations identified as potentially exposed.
Jun 29, 2026
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.
Jun 29, 2026
Microsoft warned that Secure Boot certificates issued in 2011 are nearing expiration and that devices which do not receive the newer 2023 Secure Boot update will generally keep booting, but may stop receiving future boot-chain protections. The gap affects some older Windows systems whose OEMs no longer provide compatible BIOS or UEFI updates, as well as devices running Legacy BIOS, CSM mode, or unsupported Windows 11 configurations with Secure Boot disabled. Microsoft is reportedly skipping incompatible hardware rather than forcing updates that could cause failures, but enterprises may still face compliance, cyber-insurance, and lifecycle-management pressure because those endpoints could miss future `DBX` revocations, Windows Boot Manager updates, and mitigations for bootloader threats such as **BlackLotus**. The transition is also creating planning challenges beyond Windows. Linux distributions that rely on Microsoft-signed **shim** loaders are expected to continue booting on systems that already trust the older Microsoft UEFI CA, but older PCs that never receive firmware updates with the 2023 certificates may have trouble booting newer Linux media or releases. The issue follows Microsoft's broader effort to harden the pre-boot environment after flaws such as `CVE-2024-21302`, a Windows Secure Kernel Mode elevation-of-privilege bug that could let an administrator roll back VBS-related files to bypass protections; Microsoft responded with boot-time code integrity policies, an optional `SkuSiPolicy.p7b` revocation policy, and stronger protections on newer Windows releases. Administrators are being urged to verify Secure Boot update status, update firmware and recovery media where possible, and document compensating controls or replace hardware that cannot be brought forward.
Jun 29, 2026