Forgotten UEFI shims undermining Safe Boot

ESET researchers recognized 11 previous and forgotten UEFI shim bootloaders at variations 0.9 and under that can be utilized to bypass UEFI Safe Boot on any UEFI-based machine that trusts Microsoft’s Microsoft Company UEFI CA 2011 third-party UEFI certificates authority (CA) certificates, whatever the put in working system (OS). Reported shims will be exploited to execute untrusted code throughout system boot, enabling attackers to deploy malicious UEFI bootkits (corresponding to Bootkitty, HybridPetya, or BlackLotus) even on techniques with UEFI Safe Boot enabled. We reported our findings to CERT/CC in February 2026, and the susceptible UEFI functions have been revoked on Microsoft’s June 9^th, 2026 Patch Tuesday.

Whereas two CVE IDs have been assigned to this case to cowl the reported shims, CVE-2026-8863 and CVE-2026-10797, exploitation of every reported shim isn’t just a few single bug or two that may be present in these previous shims straight. In actual fact, the assault floor is prolonged by the shims’ trusted, second-stage bootloaders (largely GRUB 2), which – just like the shims themselves – might embody outdated variations with identified vulnerabilities. The found shims come from varied instruments or software program packages, together with PC-diagnostics software program, Linux distributions, and different UEFI-based utilities. Importantly, exploitation shouldn’t be restricted to techniques with the affected software program or OS put in, as attackers can convey their very own copy of the susceptible shims to any UEFI system with the Microsoft third-party UEFI certificates enrolled.

The total checklist of the software program merchandise counting on the reported shims together with their affected variations is offered in CERT/CC’s Vulnerability Observe. In response to ESET researchers’ report, UEFI shim bootloaders with the next PE Authenticode hashes have been revoked within the dbx replace that was a part of Microsoft’s June 9^th Patch Tuesday:

• AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961
• 7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10
• EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A
• FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5
• A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4
• 95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06
• 236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B
• 5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B
• 8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963
• 410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373
• 96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629

Key factors of this blogpost:

• ESET researchers found 11 previous, Microsoft-signed, UEFI functions that permit bypassing UEFI Safe Boot on nearly all of UEFI-based techniques.
• An attacker exploiting one among these susceptible functions can execute untrusted code throughout system boot, enabling deployment of malicious UEFI bootkits or different malware.
• Exploitation shouldn’t be restricted to techniques with the affected software program or OS put in, as attackers can convey their very own copy of the susceptible binaries to any UEFI system with the Microsoft third-party UEFI certificates enrolled.
• All UEFI techniques with Microsoft third-party UEFI signing enabled are affected (Home windows 11 Secured-core PCs ought to have this feature disabled by default).
• The susceptible binaries have been revoked by Microsoft within the June 9^th, 2026 Patch Tuesday replace.

Following is the coordinated disclosure timeline. We’d wish to thank CERT/CC for its assist in coordinating the vulnerability disclosure course of, and the affected distributors for easy and clear communication and cooperation in the course of the vulnerability disclosure and remediation course of. To guard your techniques towards this risk, set up the newest Microsoft dbx updates. Directions on the way to do that may be discovered within the Safety and detection part.

Coordinated disclosure timeline:

• 2026-02-16 – ESET reported the findings, together with a proof of idea, to CERT/CC.
• 2026-03-18 – dbx replace and public disclosure date was set to Might 19^th, 2026 (Microsoft’s Might Patch Tuesday).
• 2026-03-30 – dbx replace and public disclosure date was postponed to June 9^th, 2026 (Microsoft’s June Patch Tuesday).
• 2026-06-09 – Microsoft’s June Patch Tuesday replace, CERT/CC Vulnerability Observe revealed.
• 2026-07-14 – ESET blogpost revealed.

UEFI shim bootloader and UEFI Safe Boot

To know the affect that such susceptible shims can have on UEFI Safe Boot-protected techniques, we have to perceive how UEFI Safe Boot works, and the way signed UEFI shim bootloaders prolong the Safe Boot belief chain. On this part we’ll have a look at UEFI Safe Boot fundamentals, how UEFI shims prolong the UEFI Safe Boot belief chain, and two shim-related options: Machine Proprietor Key (MOK) and Safe Boot Superior Concentrating on (SBAT). For anybody already aware of the speculation, we suggest leaping on to the part Bypassing UEFI Safe Boot utilizing previous shims.

UEFI Safe Boot

As proven in Determine 1, when UEFI firmware masses a boot utility – like Home windows Boot Supervisor or a UEFI shim – it verifies the binary towards two Safe Boot databases:

• db (allowed certificates and Authenticode hashes), and
• dbx (forbidden certificates and Authenticode hashes).

The picture should be trusted by db and never listed in dbx – in any other case, the boot supervisor triggers a safety violation as an alternative of executing it. To make this work out of the field on newly bought units with UEFI Safe Boot enabled, most OEMs enroll a set of Microsoft UEFI certificates within the db database, specifically:

• Microsoft Home windows Manufacturing PCA 2011 and Home windows UEFI CA 2023 (used to signal Microsoft’s personal UEFI boot functions; the 2011 certificates might be added to dbx quickly because of the BlackLotus-related vulnerabilities).
• Microsoft Company UEFI CA 2011 and Microsoft UEFI CA 2023 (used to signal third-party UEFI boot software program, corresponding to Linux shims, restoration instruments, and disk encryption utilities).

Which means anybody wanting their boot-time software program to be UEFI Safe Boot-compatible by default can submit their binaries to Microsoft for signing by way of the Home windows {Hardware} Dev Heart, and as soon as authorized, the signed recordsdata turn into trusted on the overwhelming majority of UEFI techniques. In consequence, Microsoft performs a central function in securing most UEFI-based units, successfully deciding what’s, and what’s not, allowed to run throughout boot.

UEFI revocation (dbx)

UEFI Safe Boot’s revocation design is easy: when a beforehand trusted boot utility – one whose PE authenticode hash, or the certificates that signed it, is current in db – seems to be susceptible, its PE authenticode hash is added to dbx, the Microsoft-managed forbidden-signatures database (with the newest dbx contents sometimes revealed in Microsoft’s GitHub repository). Certificates themselves are revoked solely sometimes.

Whereas the unique thought of revoking particular person susceptible binaries by hash might need been cheap on the time Safe Boot was launched, instances corresponding to BootHole and BlackLotus exhibit that this method is way from excellent. The elemental concern is scale, and it’s effectively captured within the Pink Hat Bootloader Group’s SBAT proposal/specification:

As a part of the current “BootHole” safety incident CVE-2020-10713, 3 certificates and 150 picture hashes have been added to the UEFI Safe Boot revocation database dbx on the favored x64 structure. This single revocation occasion consumes 10kB of the 32kB, or roughly one third, of revocation storage sometimes out there on UEFI platforms. Because of the method that UEFI merges revocation lists, this plus prior revocation occasions may end up in a dbx that’s nearly 15kB in dimension, approaching 50% capability.

The identical strain on dbx capability surfaced once more with the BlackLotus-related revocations of susceptible Home windows Boot Supervisor binaries. Each of those prompted Microsoft, along with its companions, to introduce extra, version-based revocation mechanisms, every tied to one of many two broadly deployed Safe Boot-compatible bootloaders:

• Safe Boot Superior Concentrating on (SBAT) – utilized by shim, a UEFI bootloader for Linux, from model 15.3.
• Microsoft’s Safe Boot Safety Model Quantity (SVN) – utilized by Home windows Boot Supervisor (launched in April 2024) – additionally known as Revocation by way of Embedded Safe Model Info (REVISE) in Invoice Demirkapi’s Booting with Warning, p. 62; nonetheless, this identify and acronym don’t appear to be used within the official Microsoft documentation.

Briefly, the place dbx revokes binaries, SBAT and Microsoft’s Safe Boot SVN revoke variations. When a vulnerability is present in a UEFI utility supporting one among these version-based revocation mechanisms, what actually must be saved out is each construct as much as and together with the damaged one – and that will be captured by a model quantity a lot simpler than by a protracted checklist of hashes. We clarify extra about SBAT within the Safe Boot Superior Concentrating on (SBAT) part.

UEFI shim bootloader and Safe Boot

With Linux distributions supporting UEFI Safe Boot, the above-described Safe Boot mechanism constructed round Microsoft keys introduces some challenges. Each Linux distribution generates its personal bootloader binaries, and every of them has a special hash. Getting each Linux bootloader signed straight by Microsoft can be sluggish, bureaucratic, and impractical (if not inconceivable) to take care of throughout all Linux distributions.

The answer to this downside is a shim: a small, minimal first-stage bootloader that Microsoft can vet and signal as soon as, and which then creates a secondary belief anchor for the remainder of the Linux distribution-specific boot stack – normally GRUB 2 and the Linux kernel. This belief anchor is one other certificates, known as a vendor certificates (managed by the distribution vendor), added to the shim binary earlier than it’s signed by Microsoft.

A simplified boot sequence on a Safe Boot-enabled Linux system utilizing a shim is depicted in Determine 2.

The UEFI firmware masses the shim and validates its signature towards the Microsoft CA saved within the firmware (the db variable). The shim then takes over and validates the second-stage bootloader (usually GRUB 2) towards its personal embedded vendor certificates – for instance, Debian’s UEFI key for Debian, Canonical’s UEFI key for Ubuntu, or Pink Hat’s key for RHEL and Fedora. GRUB 2, in flip, validates the kernel utilizing the identical vendor certificates earlier than handing over management. Each step is cryptographically vouched for by the step earlier than it.

This indirection signifies that a Linux distribution can launch bootloader and kernel updates quickly, signing them with its personal vendor key, without having to return to Microsoft for each replace. Solely the shim itself requires Microsoft’s signature – and it modifications sometimes.

Along with the seller certificates, the shim usually accommodates one other built-in certificates related solely with the precise shim construct/binary. This certificates is also known as a shim certificates and is used to signal and confirm integrity of the shim’s utilities that may be generated in the course of the shim’s construct time, corresponding to MokManager (used for managing MOKs and defined in additional element under) or the shim’s fallback.

Machine Proprietor Key (MOK)

When speaking about shims, we can’t skip one other vital mechanism that enables a shim to make use of exterior keys managed by the person, often known as Machine Proprietor Keys (MOKs). A MOK allowlist (consider it as a shim-specific “extension” of the UEFI db database) is saved in a boot-only NVRAM variable named MokList, and a forbidden checklist (the shim-specific “extension” of the UEFI dbx database) is saved in a boot-only NVRAM variable named MokListX; bodily entry is required to switch each variables on a system with UEFI Safe Boot enabled (boot-only variables can solely be modified throughout boot, earlier than the OS loader calls the UEFI boot companies operate ExitBootServices). To handle the lists, the shim makes use of the MokManager UEFI utility. A information on the way to handle MOKs will be discovered right here. Determine 3 illustrates how a MOK extends the shim’s UEFI Safe Boot belief chain.

As we described in our BlackLotus and Bootkitty discoveries, as a result of non-authenticated nature of the boot-only NVRAM variables utilized by the MOK mechanism, bootkits are likely to misuse MOKs for persistence as soon as they efficiently bypass UEFI Safe Boot.

Safe Boot Superior Concentrating on (SBAT)

Every UEFI utility (element) that helps SBAT carries a small piece of metadata in a devoted .sbat part of its PE file, protected by the identical signature because the binary itself. The metadata names the element (for instance, shim or grub) and assigns it a technology quantity that’s incremented each time a safety repair ships.

What turns these numbers right into a revocation mechanism is an identical coverage on the UEFI system itself: a boot-only UEFI variable named SbatLevel that data the minimal acceptable technology quantity for every identified element. Crucially, this variable is managed and enforced by the shim, not the firmware, which permits quicker revocation updates in comparison with a dbx replace. The shim embeds the coverage, so enforcement doesn’t rely solely on the exterior variable and incorporates any newer coverage supplied by way of SbatLevel. At each boot, the shim first verifies its personal SBAT metadata towards the coverage – so an outdated shim will be made to reject itself – after which applies the identical check to each binary it masses, refusing something whose technology quantity falls under the minimal that the coverage calls for.

Examples of SBAT revocations are proven in Determine 4. These are taken from the SbatLevel_Variable.txt file positioned within the shim repository, which serves as the only supply for SBAT revocations.

The enforced degree isn’t hidden from the OS – the shim publishes a read-only copy of SbatLevel in a runtime variable, SbatLevelRT. The OS can examine which revocation coverage is at present in power, however can’t modify it. On Home windows the identical data can also be out there by way of the registry worth HKLMSYSTEMCurrentControlSetControlSecureBootSBATSbatLevel.

Bypassing UEFI Safe Boot utilizing previous shims

Signing and compilation timestamps of the functions trusted by the shims we reported span from 2013 to 2025 – sufficient to verify that a good portion of those binaries have been previous and sure affected by quite a few publicly identified vulnerabilities, together with the already talked about BootHole within the case of GRUB 2. Whereas most of those trusted elements are sufficiently old to hold some safety threat, GRUB 2 appears to be the weakest hyperlink. It’s a advanced piece of software program, and older variations accumulate vulnerabilities accordingly.

Contemplate the shim from Oracle Linux, which is amongst these we reported. It trusts binaries signed by a certificates issued to Oracle Company (SHA‑1 thumbprint: 2E434A724B4759C981E4189AA5AD3D635096DD2F). One of many binaries signed by that certificates is a GRUB 2 binary discovered within the Oracle Linux 7.1 set up ISO (V74844-01.iso). This binary is affected by CVE-2015-5281, which – quoting the vulnerability word – “when used on UEFI techniques, permits native customers to bypass meant Safe Boot restrictions and execute non-verified code by way of a crafted (1) multiboot or (2) multiboot2 module”. Each talked about modules, multiboot and multiboot2, permit loading of unsigned code throughout system startup utilizing the identically named instructions, and ought to be forbidden in signed UEFI Safe Boot-compatible GRUB 2 binaries, as they bypass UEFI Safe Boot by design.

The exploit is easy: there are not any reminiscence corruption bugs to set off, no ROP chains to assemble, and no advanced reverse engineering required. The only prerequisite is constructing a customized, unsigned multiboot2-compliant kernel picture – in apply, little greater than an ELF binary containing the required headers and a handful of different specifics. As soon as an attacker builds this binary and copies it to the EFI System Partition (ESP) together with the susceptible shim and GRUB 2, a single GRUB 2 multiboot2 command can be utilized to load and execute it throughout boot, Safe Boot enabled or not. A proof of idea demonstrating exploitation of CVE-2015-5281 by way of the previous, reported Oracle Linux shim on a system with UEFI Safe Boot enabled (with out the newest Microsoft patches utilized) is proven within the video under:

Absence of newer options

Over time, the UEFI shim bootloader has naturally developed, with new enhancements and safety features launched in successive releases of the upstream UEFI shim repository. On the similar time, many third-party distributors have taken out there variations of the shim supply code to construct their very own binaries, which they subsequently submitted to Microsoft for signing. This conduct is anticipated and aligns with the unique design of shims. Nevertheless, inadequate consideration has been given to revoking outdated Microsoft-signed shims, a lot of which may, by design, be leveraged to bypass newer safety mechanisms. We illustrate this hole with just a few concrete examples.

MOK denylist enforcement

The MokList (MOK-based allowlisting) has been supported by the upstream UEFI shim since nearly the very starting (model 0.3). MOK revocations (MokListX), nonetheless, solely began to be enforced in model 0.9. Why is that an issue? Contemplate the next situation…

An enterprise has enrolled its personal MOK to signal customized UEFI instruments and bootloaders that it deploys throughout its community. A vulnerability surfaces in a number of of these binaries, and in response, the directors revoke the previous signing certificates by enrolling it into the MOK denylist (MokListX). Then, they enroll a recent MOK, and re-sign patched variations of the affected binaries with the brand new key. The previous, susceptible binaries are actually rejected by the shim, whereas the newly signed ones load correctly, so the enterprise’s units look safe. The previous certificates stays current and trusted within the MokList, however is revoked in MokListX, the place it’s enforced as a higher-priority rule.

On this situation, an attacker might exchange the sufferer’s up-to-date shim with an older Microsoft-signed UEFI shim from our report – for instance, model 0.8 from the Abitti 1 software program, signed by Microsoft for Finland’s Matriculation Examination Board. This shim nonetheless trusts the certificates saved within the sufferer’s MokList variable, the place the outdated MOK certificates stays legitimate, but it surely ignores MokListX, because it was constructed previous to the introduction of MOK denylist enforcement. In consequence, the attacker’s shim could possibly be used to load susceptible binaries with out restriction, permitting arbitrary code execution or the set up of a malicious UEFI bootkit.

SBAT enforcement

The identical concern applies to SBAT. Help for it was launched upstream in shim model 15.3, so any earlier shim is unaware of the mechanism: it doesn’t learn the SbatLevel revocation coverage or examine the .sbat part of the second-stage bootloader it masses. In consequence, it ignores any later SBAT revocations meant to dam susceptible elements.

On this case, an assault situation can be the next: an attacker takes a Microsoft-signed pre-v15.3 shim – such because the model 0.9 shim from Pink Hat Enterprise Linux 7.2 that was a part of our report – pairs it with one of many a number of GRUB 2 binaries that the shim nonetheless trusts however that SBAT has already revoked, after which copies each to the ESP. Throughout system boot, the shim validates the GRUB 2 binary towards its personal embedded certificates, by no means consults SBAT, and masses the susceptible binary with out grievance – leaving the attacker free to take advantage of any vulnerability in that GRUB 2 binary.

Recognized shim vulnerabilities

Lastly, previous shims are merely previous code, and far previous code carries identified vulnerabilities. As an instance this, we use an instance of an previous concern affecting shims at model 0.9 and under. This vulnerability had no CVE ID assigned till our report – though it was mounted and effectively described nearly precisely a decade in the past within the message of one of many shim repository’s upstream commits, d241bbb. It’s now tracked as CVE-2026-10797.

The difficulty is that an Authenticode-signed PE binary data its signature’s size in two impartial places:

• its PE header’s knowledge listing (IMAGE_DIRECTORY_ENTRY_SECURITY), and
• its WIN_CERTIFICATE construction, which encapsulates the signature itself.

Within the affected shims, the revocation test and the signature verification features diverged on which dimension worth they need to belief. The revocation test used the worth from the signature header, whereas the signature verification operate used the worth from the PE header.

It’s thus potential to bypass the revocation mechanism by tampering with the second-stage bootloader’s WIN_CERTIFICATE construction in order that the revocation operate compares dbx and MokListX towards bogus knowledge as an alternative of the bootloader’s precise signature.

Merely put, even when the second-stage bootloader’s certificates have been revoked in dbx or MokListX, the shim wouldn’t discover out. Two vital feedback right here:

• this bypass works solely with certificate-based revocations (not hash-based revocations), and
• the second-stage bootloader must be signed by a certificates embedded within the shim (whether or not it’s the shim’s built-in certificates generated in the course of the shim’s construct course of or the seller certificates).

These limitations come from the truth that hash-based revocations and non-embedded certificates (from MokList and db) are checked elsewhere within the code and will not be affected by this concern.

Received’t expiring Microsoft UEFI certificates remedy this?

With the present Microsoft UEFI certificates expirations in thoughts (as proven in Determine 5, Microsoft Company UEFI CA 2011 expired on June 27^th 2026), one would possibly wonder if reporting susceptible UEFI functions signed by this expired certificates is simply inflicting pointless noise.

The reality is that the UEFI certificates’s expiration date has no impact on the Safe Boot verification course of. If the Microsoft Company UEFI CA 2011 certificates stays in db, and isn’t revoked in dbx, all bootloaders validly signed with this expired certificates keep trusted if not explicitly revoked by hash. That is the rationale why Microsoft saved signing new submissions with the previous certificates up till its expiration date.

Safety and detection

$hashes="AE75F0D82BA3DF824FBFC69340CC3B4D66C598373B1AB54CDB6C8BFD83A6B961",
'7B2A3F5C96F95BD8086CE54B0825E300F9C8F11FE3401BB631B3215C8DE9EB10',
'EB86FA1386FE6E4533B8B938DCC1250616D2F1C14C15E2FCF80834A161018A0A',
'FD23D6E57DE6F4E1F9D7118DA1C5F31A8AF6BE5E5D9E8170F9493447268D50C5',
'A0DE9333442C1BF9349A460141AE5E80F911955C6506040FA3D021BF6C1AE3E4',
'95B6D71FC0C0F8C5E1533A37AEF92CF6B0C961E2CC612A97117FA6759CE5FC06',
'236A9CB0D71951C36398A32EB660CE2CD4A52CCFA7CF751CC6A35D9DE549E19B',
'5E594C448760A3135B1A3A83E07A4F2E6FBE49414EF2C7CAB1CBA77F284FA63B',
'8A964D5F8373948D20A1D4296FB92E545DAD4617A0C810F3B934B53D98AE8963',
'410260B1B6F5AF5FBEEB9EA3220658435E876CB3247126EE907A437F312DB373',
'96275DFD6282A522B011177EE049296952AC794832091F937FBBF92869028629' 
$dbx = [BitConverter]::ToString((Get-SecureBootUEFI dbx).Bytes) -replace '-'
$notRevoked = $hashes | The place-Object { $dbx -notmatch $_ }
if ($notRevoked) {
    $notRevoked | ForEach-Object { "Hash not revoked: $_" }
} else {
    "All hashes revoked in dbx!"
}

For Linux techniques, updates ought to be out there by way of the Linux Vendor Firmware Service, and the revocation standing will be checked utilizing the uefi-dbx-audit script.

For extra common suggestions concerning the way to shield towards (or a minimum of detect) exploitation of unknown susceptible signed UEFI bootloaders and deployment of UEFI bootkits, see our blogpost Beneath the cloak of UEFI Safe Boot: Introducing CVE-2024-7344.

Conclusion

What makes these previous shims harmful shouldn’t be a novel vulnerability, it’s that no new vulnerability is required to bypass UEFI Safe Boot. An attacker wants no difficult exploitation primitives – solely a duplicate of an previous, still-trusted, however unrevoked shim binary and a fundamental understanding of how UEFI shims work. That is sufficient to bypass such a vital safety characteristic as UEFI Safe Boot.

Whereas revoking these 11 shims addressed the speedy concern, a deeper concern stays: visibility. The shim signing course of grew to become considerably extra clear in 2017 with the introduction of the shim-review repository, the place vendor submissions are vetted by maintainers earlier than Microsoft indicators them. Each shim authorized since then is documented – however these signed earlier will not be, and nobody can reliably say what number of of these previous, still-trusted shims stay. What has not been absolutely and transparently catalogued can’t be successfully retired.

On a constructive word, we imagine that the pattern is shifting in the precise route. Every disclosure like this one shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms corresponding to SBAT, maintaining observe of what must be revoked, and successfully revoking it, will be dealt with much more effectively than prior to now. The following step is to increase this degree of transparency in Microsoft’s third-party UEFI signing ecosystem to non-shim third-party UEFI functions, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), may function a simple supply of UEFI Safe Boot bypasses.

IoCs

Because the susceptible shims are a part of professional software program packages which can be doubtlessly current on 1000’s of techniques which have by no means been compromised by way of these loaders, we’re not offering indicators of compromise to keep away from huge misidentification. As a substitute, defenders ought to observe the recommendation within the Safety and detection part.

For any inquiries about our analysis revealed on WeLiveSecurity, please contact us at threatintel@eset.com. 

ESET Analysis gives personal APT intelligence studies and knowledge feeds. For any inquiries about this service, go to the ESET Risk Intelligence web page.