Between February and June 2026, security researchers responsibly disclosed a set of eleven outdated UEFI shim bootloaders that carry valid Microsoft digital signatures but contain exploitable vulnerabilities in their boot-time validation logic. Because these shims were signed and trusted by Secure Boot, an attacker who could place one of them on a target system's EFI System Partition could use it to execute unsigned, untrusted code during system boot, bypassing the entire Secure Boot verification chain. Microsoft revoked the vulnerable shims as part of the June 2026 Patch Tuesday release, with the affected certificate, "Microsoft Corporation UEFI CA 2011," formally expiring on 27 June 2026 and being replaced by the Microsoft UEFI CA 2023 and Microsoft Option ROM UEFI CA 2023 certificates.
The affected shims span an unexpectedly wide range of vendors and products: distributions including Red Hat Enterprise Linux 7.2, CentOS 7.2, Oracle Linux 7.2, OpenSUSE versions 0.9 and 2.1, and ROSA Linux R10 and R9, alongside commercial and specialised tools including Baramundi Management Suite versions through 2024R1, WhiteCanyon WipeDrive versions 8.0.0 through 8.1.3, PC-Doctor Service Center versions 15 and 16, Spyrus WTGCreator, and Finland's Abitti examination software. The breadth of the list illustrates a structural characteristic of the UEFI Secure Boot trust chain: once Microsoft signs a bootloader, that signature remains valid until the certificate is explicitly revoked, regardless of how old the binary becomes or what vulnerabilities are later discovered in it.
UEFI Secure Boot is a firmware security feature built into the Unified Extensible Firmware Interface specification that is standard in modern x86-64 computers. It works by maintaining a database of trusted cryptographic signatures. When a system boots, the UEFI firmware checks every piece of code in the boot path against this database. Any code that does not carry a trusted signature is refused execution. The goal is to guarantee that the boot process from firmware to operating system kernel is running only verified, unmodified software.
The challenge for Linux distributions is that the root of trust in Secure Boot on Microsoft Windows-certified hardware is a Microsoft certificate. Linux kernels are not signed by Microsoft. To allow Linux to boot on Secure Boot-enabled hardware without requiring end users to add their own trusted keys, the Linux community developed shims: small, Microsoft-signed bootloaders whose sole purpose is to load a Linux distribution's own bootloader using the distribution's own certificate. The shim itself carries a Microsoft signature, which Secure Boot trusts. The shim then loads the distribution's signed GRUB bootloader, which loads the signed kernel. The chain of trust passes from Microsoft through the shim to the distribution.
The shim architecture was a practical solution to a real compatibility problem, but it introduced a long-term trust dependency: every shim that Microsoft has ever signed remains trusted by Secure Boot until that signature is explicitly revoked. An old, vulnerable shim is just as trusted as a current, patched one, unless Microsoft takes the specific step of adding the old shim's certificate or hash to the UEFI Secure Boot revocation database. This is the vulnerability class that CVE-2026-8863 and CVE-2026-10797 fall into. The shims themselves are not new vulnerabilities in the sense of recently introduced code changes. They are old binaries with long-known issues that were never removed from the trust chain.
CVE-2026-8863 covers the primary class of vulnerabilities in the eleven affected shims. The exact technical details vary across the different affected binaries, but the common thread is that each shim fails to correctly validate boot-time inputs in ways that allow an attacker to redirect execution to unsigned code during the boot process. Once the shim accepts and executes attacker-controlled code, it does so at the same trust level as the shim itself, which is the level that Secure Boot has validated as trustworthy. Everything that happens after that point in the boot process inherits that trust, including any malicious bootkit or kernel module that the attacker injects.
CVE-2026-10797 addresses a related but distinct issue: a mechanism in some of the affected shims that was supposed to allow certificate-based revocation of untrusted bootloaders contained a flaw that allowed the revocation check to be bypassed. This matters because SBAT, the Secure Boot Advanced Targeting mechanism that was introduced specifically to make mass revocation of old bootloaders practical, relies on the shim correctly enforcing revocation decisions. A shim that does not enforce SBAT decisions correctly can be used to load bootloaders that SBAT was supposed to block, undermining the entire revocation infrastructure that UEFI relies on for managing the trust chain over time.
The combination of these two vulnerability classes makes the affected shims doubly problematic: they can be used to execute unsigned code directly, and they can be used to circumvent the revocation mechanism that was supposed to prevent old, vulnerable bootloaders from remaining effective. An attacker who places one of the eleven affected shims on a target system's EFI System Partition can therefore use it both to bypass Secure Boot's initial execution check and to disable the revocation controls that would otherwise catch it.
The security advisory associated with CVE-2026-8863 describes the consequence of successful exploitation clearly: an attacker can execute untrusted code during system boot, enabling the deployment of malicious UEFI bootkits or other malware that persists below the operating system level. This is the level of persistence that is hardest to detect and hardest to remove.
A UEFI bootkit operates before the operating system kernel loads. This means it runs before any of the security controls that the operating system provides: before antivirus software initialises, before endpoint detection and response agents start, before kernel-level integrity checks can run. A bootkit that establishes itself in the EFI System Partition or modifies UEFI variables can survive operating system reinstalls, because the malicious code lives in firmware-level storage that an OS reinstall does not touch. It can survive hard drive replacements if the attacker's code lives in the UEFI variables rather than on the drive itself. Detecting and removing a bootkit requires specialised tools that operate at the firmware level, not standard endpoint security software.
Historically, UEFI bootkits have been associated with the most sophisticated threat actors: state-sponsored groups with the technical capability to develop persistent firmware-level implants and the motivation to maintain access that survives aggressive remediation attempts. The public disclosure and documented revocation process for the eleven shims means the attack technique will receive attention from a broader range of attackers than previously. The techniques required to exploit CVE-2026-8863 are now public, and the affected shim binaries are available in older distribution packages that remain accessible through archives and package mirrors.
Revoking a UEFI bootloader is technically more complex than revoking a software application or a standard certificate. The revocation must be applied at the firmware level, delivered to every affected system's UEFI Secure Boot revocation database, and must not break legitimate boot paths for any system that is legitimately running a revoked binary as its production bootloader. The SBAT mechanism was designed specifically to make this process more manageable: rather than requiring individual hash-level revocation of every vulnerable binary, SBAT allows revocation decisions to be expressed in terms of version numbers and vendor names, which can be applied uniformly to all binaries that match.
Microsoft's June 2026 Patch Tuesday response addressed the revocation requirement by formally expiring the "Microsoft Corporation UEFI CA 2011" certificate on 27 June 2026 and replacing it with two new certificate authorities: the Microsoft UEFI CA 2023 for standard bootloaders and the Microsoft Option ROM UEFI CA 2023 for option ROM firmware. Systems that apply the June 2026 Patch Tuesday update will no longer trust binaries signed by the 2011 certificate. Any of the eleven vulnerable shims attempting to boot on a fully patched system should be rejected by the firmware's signature verification.
The practical challenge is the update rollout. Applying the June 2026 Patch Tuesday update to a Windows system is straightforward. But many of the affected shims are associated with Linux distributions and specialised software tools, not Windows deployments. Systems running the affected versions of Red Hat, CentOS, Oracle Linux, OpenSUSE, or ROSA Linux that are dual-boot configurations or standalone Linux systems need to apply the revocation update independently, through the Linux distribution's own firmware update mechanism or through fwupd, the Linux firmware update daemon. Organisations with large, diverse device fleets need to confirm that the revocation has been applied to every system type in their inventory, not just those managed through Windows Update.
The primary audience for the June 2026 revocation is not organisations running current, patched Linux distributions. All major Linux distributions had already moved past the affected shim versions before this advisory. The risk is concentrated in three specific scenarios: systems running old Linux distributions that were never updated past the affected versions, systems using one of the commercial tools in the affected list (Baramundi, WhiteCanyon, PC-Doctor) at a vulnerable version, and environments where disk imaging or deployment tools distribute bootable media that includes old, pre-revocation shim binaries.
That third category deserves specific attention in enterprise environments. Deployment infrastructure, recovery media, and imaging systems frequently contain bootable Linux environments that are built once and used for months or years without updating the shim component. A system deployment tool based on an old Ubuntu or CentOS image might carry one of the affected shims, and that media becomes an exploitation vector if it is used to boot target systems. Reviewing and updating bootable media in deployment and recovery infrastructure is part of the appropriate response to CVE-2026-8863, not just updating production operating system installations.
For environments where the affected commercial tools are in use, updating to versions that contain revocation-compatible shims is the remediation path. Baramundi Management Suite, WhiteCanyon WipeDrive, and PC-Doctor Service Center all have vendor update channels, and the vendors in question should have issued updates that include shim binaries compatible with the post-revocation Secure Boot trust chain. Applying those vendor updates and confirming that the updated tools can still boot correctly on systems with the June 2026 Patch Tuesday update applied is the verification step that confirms the remediation is complete.
The broader lesson from CVE-2026-8863 is about the lifecycle management of cryptographic trust in boot infrastructure. Understanding your organisation's indicators of compromise at the firmware level requires different tooling than standard endpoint security provides. Organisations that depend heavily on Linux-based infrastructure should confirm that their shim versions are current and that firmware update mechanisms are functioning across their entire device inventory, including deployment tools, recovery environments, and specialised systems that may not receive standard operating system updates on a regular cycle.
SBAT, the Secure Boot Advanced Targeting mechanism, was specifically designed to solve the mass revocation problem that traditional UEFI certificate revocation struggled with. Before SBAT, revoking a vulnerable bootloader required adding its specific cryptographic hash to the Secure Boot revocation database on every affected system, a process that required distributing a database update to every system and could easily break legitimate systems whose bootloaders happened to share characteristics with revoked binaries.
SBAT works differently. It embeds version and vendor metadata directly into bootloader binaries as a standardised section. When a shim loads a subsequent bootloader, it checks that bootloader's SBAT metadata against a list of minimum acceptable versions that is stored in a UEFI variable. If the bootloader's SBAT version is below the minimum, the shim refuses to load it, regardless of whether the bootloader carries a valid certificate. This allows vendors to revoke entire version ranges of their own bootloaders without requiring cryptographic hash distribution for every individual binary.
CVE-2026-10797 addresses the finding that some of the eleven affected shims did not correctly enforce SBAT checks for the bootloaders they loaded. A shim that carries SBAT metadata itself but does not correctly enforce SBAT checks on what it loads creates a gap in the revocation chain: an attacker who places one of these shims on a system and uses it to load a bootloader that SBAT should have blocked can bypass the revocation mechanism that was supposed to prevent old, vulnerable bootloaders from remaining effective. The combined effect of CVE-2026-8863 and CVE-2026-10797 is a dual bypass: the shims can be used to execute unsigned code directly, and they can be used to undermine the revocation infrastructure that exists to manage the trust chain over time.
The range of vendors in the affected shim list reflects the breadth of the Microsoft Secure Boot shim signing programme. Red Hat, CentOS, and Oracle Linux are all in the same extended ecosystem: CentOS 7.2 is the downstream rebuild of RHEL 7.2, and Oracle Linux 7.2 was also built from RHEL sources. The affected versions of these distributions are end-of-life or approaching end-of-life, which means they may not be receiving routine security updates even though they remain deployed in production environments. A CentOS 7.2 installation in 2026 is a system running an OS released in 2015 that has not been updated to a current OS release, and it is likely to be using the same shim it shipped with.
OpenSUSE versions 0.9 and 2.1 are similarly old releases. ROSA Linux R10 and R9 are a less widely-known distribution primarily used in Russia and post-Soviet markets, which may explain their presence on the list: regional distributions often receive less security scrutiny than major international distributions, and their shim signing submissions to Microsoft may not have been reviewed as critically. Spyrus WTGCreator is a specialised tool for creating Windows-To-Go drives, a use case that involves booting from USB media, which is a context where boot-level attacks are particularly relevant. Finland's Abitti examination software is used for secondary school matriculation examinations in Finland, an environment where Secure Boot integrity is important precisely because the examination environment must be controlled and tamper-resistant.
Each of these vendors has its own update path for delivering a post-revocation compatible shim. Red Hat has issued updated shim packages for current RHEL versions; organisations running RHEL 7.2 specifically should evaluate whether upgrading to a supported RHEL version is more appropriate than trying to obtain an updated shim for an end-of-life release. WhiteCanyon, Baramundi, and PC-Doctor all have vendor support channels through which updated versions of their tools that include revocation-compatible shims can be obtained.
One of the less-discussed consequences of the June 2026 revocation is its effect on dual-boot systems that have Microsoft Windows on one partition and a Linux distribution on another. A dual-boot system running both Windows and Linux typically boots Windows through Microsoft's own bootloader and Linux through a shim-based chain. If the Linux shim used in that dual-boot configuration is one of the eleven revoked shims, and the system has applied the June 2026 Patch Tuesday update to Windows, the Linux boot path may fail when the system attempts to load the revoked shim after the revocation update has been applied.
This is a known and anticipated consequence of the revocation process, but it catches administrators who are not aware of it off guard. A system that successfully boots Windows but fails to boot Linux after a Windows update is a predictable outcome of revoking Linux shims through a Windows update. The resolution is to update the Linux shim to a version that carries a signature compatible with the post-revocation trust chain, then attempt the Linux boot again. But on systems where the Linux installation is not actively maintained, or where the Linux boot path is used infrequently and the failure is not noticed immediately, the dual-boot issue can persist for weeks before it surfaces.
Enterprise environments that have deployed dual-boot configurations on any significant number of systems, particularly those used for development work where Linux is the primary development environment but Windows may be required for specific tools, should proactively audit their shim versions before applying the June 2026 Patch Tuesday update rather than discovering boot failures after the fact. The shim version on a running Linux system can be checked by examining the EFI System Partition for the shim binary and verifying its version against the affected version list. This is a non-routine task for most system administrators, but it is a straightforward one for anyone with familiarity with UEFI boot management.
The CVE-2026-8863 disclosure illustrates a structural gap in many organisations' patch management programmes: boot-level components are not covered by the same update disciplines that apply to operating system software and applications. A shim that was signed by Microsoft in 2015 and has not been updated since is, in most enterprise asset management systems, invisible. It does not appear in vulnerability scanner output in the same way that a missing OS patch appears. It does not generate alerts when the binary ages past a certain version. It simply sits in the EFI System Partition, trusted by Secure Boot, until a research team examines it and finds that it is exploitable.
Extending patch management disciplines to include UEFI boot components requires tooling that most organisations do not currently deploy. Tools like fwupd on Linux provide a mechanism for updating firmware and EFI components through a managed, vendor-backed update channel, but fwupd coverage varies by hardware manufacturer and device type. For specialised devices like those running WhiteCanyon WipeDrive or PC-Doctor Service Center, firmware update management must go through the vendor's own update mechanism, which may not integrate with standard enterprise patch management platforms. The gap between the security requirement (keep all trusted boot components current) and the operational tooling available to meet it is one that the security industry is still working to close, and CVE-2026-8863 is a concrete illustration of what happens in that gap.
When an enterprise network appliance is compromised, the attacker's next step is almost always to monetise the access. Credentials harvested from session logs, certificates extracted from the device, and authentication tokens captured in transit have a well-established route: they end up in stealer logs on criminal forums, dark web marketplaces, or private channels where initial access brokers sell them to the next buyer in the chain.
Defendis monitors these channels continuously. If credentials or data linked to your organisation surface following a perimeter device compromise, Defendis surfaces the exposure with full context: which individual is affected, what data was taken, and how the compromise likely unfolded. That intelligence allows your security team to act on a specific, confirmed risk rather than conducting an expensive, broad investigation with no direction.
Book a demo to see how Defendis approaches dark web monitoring for enterprise security teams.
