Loading story…
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.
Mallory correlates global threat intelligence with your attack surface — know if you’re exposed before adversaries strike.
5 events from the most recent confirmed update back to the earliest known activity.
Fedora warned users that vulnerable or outdated Microsoft-signed Shim bootloaders may still be trusted under UEFI Secure Boot until their signatures are added to the DBX revocation list. Users were advised to verify Secure Boot state, inspect installed Shim signatures, and apply firmware-related updates.
The references report that Fedora Rawhide, the development branch for Fedora 45, includes an updated Shim intended to address the Secure Boot issues. Fedora presented this as a mitigation ahead of broader revocation of vulnerable older Shim builds.
Fedora warned that the previously announced Microsoft revocation affecting older Shim bootloaders is expected to be enforced around June 2025. Once enforced through the UEFI DBX, affected systems relying on old Microsoft-signed Shim binaries could be impacted.
One reference says a Secure Boot-related revocation process was previously announced by Microsoft in 2023. This process distributes revocations through the UEFI DBX for vulnerable boot components such as outdated Shim binaries.
The references state that the legacy Shim 0.9 build from 2016 is affected by Secure Boot bypass issues later tracked as CVE-2026-8863 and CVE-2026-10797. Older distributions using this Microsoft-signed Shim build may remain exposed until its signature is revoked in the UEFI DBX.
Vulnerabilities, threat actors, malware, products, organizations, and breaches Mallory has linked to this story.
3 references tracked. Mallory keeps watching after this page renders.
fedoramagazine.org
Open sourceopennet.ru
Open sourceopennet.me
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.
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**.
Jul 15, 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
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