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 might be exploited to execute untrusted code throughout system boot, enabling attackers to deploy malicious UEFI bootkits (comparable to Bootkitty, HybridPetya, or BlackLotus) even on programs with UEFI Safe Boot enabled. We reported our findings to CERT/CC in February 2026, and the susceptible UEFI purposes have been revoked on Microsoft’s June 9th, 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 is not only a couple of single bug or two that may be present in these previous shims straight. Actually, 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 recognized 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 will not be restricted to programs with the affected software program or OS put in, as attackers can carry their very own copy of the susceptible shims to any UEFI system with the Microsoft third-party UEFI certificates enrolled.
The total record of the software program merchandise counting on the reported shims together with their affected variations is obtainable in CERT/CC’s Vulnerability Word. 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 9th 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 purposes that enable bypassing UEFI Safe Boot on nearly all of UEFI-based programs.
- An attacker exploiting one among these susceptible purposes can execute untrusted code throughout system boot, enabling deployment of malicious UEFI bootkits or different malware.
- Exploitation will not be restricted to programs with the affected software program or OS put in, as attackers can carry their very own copy of the susceptible binaries to any UEFI system with the Microsoft third-party UEFI certificates enrolled.
- All UEFI programs 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 9th, 2026 Patch Tuesday replace.
Following is the coordinated disclosure timeline. We’d prefer 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 programs towards this risk, set up the most recent Microsoft dbx updates. Directions on methods 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 19th, 2026 (Microsoft’s Might Patch Tuesday).
- 2026-03-30 – dbx replace and public disclosure date was postponed to June 9th, 2026 (Microsoft’s June Patch Tuesday).
- 2026-06-09 – Microsoft’s June Patch Tuesday replace, CERT/CC Vulnerability Word printed.
- 2026-07-14 – ESET blogpost printed.
UEFI shim bootloader and UEFI Safe Boot
To grasp the impression that such susceptible shims can have on UEFI Safe Boot-protected programs, we have to perceive how UEFI Safe Boot works, and the way signed UEFI shim bootloaders lengthen the Safe Boot belief chain. On this part we’ll take a look at UEFI Safe Boot fundamentals, how UEFI shims lengthen 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 conversant in 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 hundreds 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 gadgets 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 purposes; the 2011 certificates can be added to dbx quickly on account of the BlackLotus-related vulnerabilities).
- Microsoft Company UEFI CA 2011 and Microsoft UEFI CA 2023 (used to signal third-party UEFI boot software program, comparable 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 via the Home windows {Hardware} Dev Middle, and as soon as authorised, the signed information turn into trusted on the overwhelming majority of UEFI programs. Consequently, Microsoft performs a central function in securing most UEFI-based gadgets, successfully deciding what’s, and what’s not, allowed to run throughout boot.
UEFI revocation (dbx)
UEFI Safe Boot’s revocation design is simple: 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 most recent dbx contents usually printed in Microsoft’s GitHub repository). Certificates themselves are revoked solely often.
Whereas the unique thought of revoking particular person susceptible binaries by hash may need been affordable on the time Safe Boot was launched, instances comparable to BootHole and BlackLotus show that this strategy is way from excellent. The elemental difficulty is scale, and it’s nicely captured within the Pink Hat Bootloader Staff’s SBAT proposal/specification:
As a part of the latest “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 usually accessible on UEFI platforms. As a result of manner that UEFI merges revocation lists, this plus prior revocation occasions may end up in a dbx that’s virtually 15kB in dimension, approaching 50% capability.
The identical stress 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 extensively 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 Data (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.
In brief, 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 might be captured by a model quantity a lot simpler than by an extended record 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 could be sluggish, bureaucratic, and impractical (if not not possible) to keep up 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 – often 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 hundreds 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 implies that a Linux distribution can launch bootloader and kernel updates quickly, signing them with its personal vendor key, with no need to return to Microsoft for each replace. Solely the shim itself requires Microsoft’s signature – and it adjustments sometimes.
Along with the seller certificates, the shim usually incorporates 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, comparable 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, generally 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 record (the shim-specific “extension” of the UEFI dbx database) is saved in a boot-only NVRAM variable named MokListX; bodily entry is required to change 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 providers perform ExitBootServices). To handle the lists, the shim makes use of the MokManager UEFI utility. A information on methods to handle MOKs might 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 inclined 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 era 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 information the minimal acceptable era quantity for every recognized 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 offered by way of SbatLevel. At each boot, the shim first verifies its personal SBAT metadata towards the coverage – so an outdated shim might be made to reject itself – after which applies the identical take a look at to each binary it hundreds, refusing something whose era 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 situated 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 the moment in pressure, however can’t modify it. On Home windows the identical data can also be accessible via the registry worth HKLMSYSTEMCurrentControlSetControlSecureBootSBATSbatLevel.
Bypassing UEFI Safe Boot utilizing previous shims
With the speculation a couple of shim’s Safe Boot belief chain defined within the earlier part, we are able to now concentrate on the sensible impression that forgotten and previous, although trusted, UEFI binaries can have on UEFI system safety.
We illustrate this by inspecting just a few particular points within the reported shims – points which might be simply exploitable and spotlight the breadth of the assault floor they expose.
Susceptible second-stage bootloaders
Every of the reported shims embeds each a vendor-managed and a built-in shim certificates that function a belief anchor for the shim’s second-stage bootloaders or utilities: GRUB 2 binaries, MokManager, fallback loaders, and sometimes different vendor-signed shims that stretch the belief chain even additional. The variety of binaries trusted by a given shim varies: from fewer than ten within the case of devoted, specialised software program to shut to 100 within the case of well-known Linux distributions.
Signing and compilation timestamps of the purposes trusted by the shims we reported span from 2013 to 2025 – sufficient to substantiate that a good portion of those binaries have been previous and sure affected by quite a few publicly recognized 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 programs, permits native customers to bypass supposed 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, enable 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 straightforward: there aren’t any reminiscence corruption bugs to set off, no ROP chains to assemble, and no advanced reverse engineering required. The one prerequisite is constructing a customized, unsigned multiboot2-compliant kernel picture – in follow, 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 most recent 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 identical time, many third-party distributors have taken accessible 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 virtually 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 gadgets 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 may 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, however it ignores MokListX, because it was constructed previous to the introduction of MOK denylist enforcement. Consequently, the attacker’s shim may very well 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 difficulty 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 hundreds. Consequently, it ignores any later SBAT revocations supposed to dam susceptible elements.
On this case, an assault situation could 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 hundreds the susceptible binary with out grievance – leaving the attacker free to use any vulnerability in that GRUB 2 binary.
Identified shim vulnerabilities
Lastly, previous shims are merely previous code, and far previous code carries recognized vulnerabilities. For example this, we use an instance of an previous difficulty affecting shims at model 0.9 and under. This vulnerability had no CVE ID assigned till our report – despite the fact that it was mounted and nicely described virtually 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 problem is that an Authenticode-signed PE binary information its signature’s size in two unbiased areas:
- 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 verify and the signature verification features diverged on which dimension worth they need to belief. The revocation verify used the worth from the signature header, whereas the signature verification perform used the worth from the PE header.
It’s thus doable to bypass the revocation mechanism by tampering with the second-stage bootloader’s WIN_CERTIFICATE construction in order that the revocation perform 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 should not affected by this difficulty.
Received’t expiring Microsoft UEFI certificates resolve this?
With the present Microsoft UEFI certificates expirations in thoughts (as proven in Determine 5, Microsoft Company UEFI CA 2011 expired on June 27th 2026), one would possibly wonder if reporting susceptible UEFI purposes 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 explanation why Microsoft saved signing new submissions with the previous certificates up till its expiration date.
Safety and detection
These susceptible shims might be blocked by making use of the most recent UEFI revocations from Microsoft. Home windows programs ought to be up to date mechanically. Determine 6 shows PowerShell instructions (to be run with elevated permissions) to verify whether or not the required revocations are put in in your Home windows system.
$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!"
}Determine 6. PowerShell instructions to verify UEFI revocations
For Linux programs, updates ought to be accessible via the Linux Vendor Firmware Service, and the revocation standing might be checked utilizing the uefi-dbx-audit script.
For extra common suggestions relating to methods 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 will not be a novel vulnerability, it’s that no new vulnerability is required to bypass UEFI Safe Boot. An attacker wants no sophisticated exploitation primitives – solely a replica of an previous, still-trusted, however unrevoked shim binary and a primary 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 instant difficulty, a deeper difficulty stays: visibility. The shim signing course of turned 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 authorised since then is documented – however these signed earlier should not, and nobody can reliably say what number of of these previous, still-trusted shims stay. What has not been totally and transparently catalogued can’t be successfully retired.
On a constructive word, we imagine that the development is transferring in the best route. Every disclosure like this one shrinks the pool of forgotten shims, and with improved shim-signing transparency and mechanisms comparable to SBAT, retaining monitor of what must be revoked, and successfully revoking it, might be dealt with way more effectively than previously. The following step is to increase this degree of transparency in Microsoft’s third-party UEFI signing ecosystem to non-shim third-party UEFI purposes, which, as repeatedly demonstrated (e.g., CVE-2022-34302, CVE-2023-28005, CVE-2024-7344, CVE-2026-25250, …), can even function a simple supply of UEFI Safe Boot bypasses.
IoCs
Because the susceptible shims are a part of professional software program packages which might be doubtlessly current on 1000’s of programs which have by no means been compromised by way of these loaders, we aren’t offering indicators of compromise to keep away from huge misidentification. As an alternative, defenders ought to comply with the recommendation within the Safety and detection part.
For any inquiries about our analysis printed on WeLiveSecurity, please contact us at threatintel@eset.com.ESET Analysis affords personal APT intelligence stories and knowledge feeds. For any inquiries about this service, go to the ESET Risk Intelligence web page.
