Eleven old shims just made Secure Boot a promise your firmware may not keep
ESET Research published findings on July 14 documenting 11 outdated Microsoft-signed UEFI shims that can be used to bypass Secure Boot on most current systems. The shims are at version 0.9 or below, were revoked by Microsoft in the June 9, 2026 Patch Tuesday update, and are tracked under CVE-2026-8863 and CVE-2026-10797.
The catch is that 'revoked in June's Patch Tuesday' and 'revoked on your specific device' are not the same statement. The revocation happens via a Secure Boot Forbidden Signature Database (dbx) update, which is a separate firmware-level operation from a standard OS patch. Plenty of patch management tools track Windows update compliance without separately auditing whether the dbx has been refreshed. That gap is what ESET is surfacing.
How the attack works
This is a variation of the bring-your-own-vulnerable-driver (BYOVD) technique, applied below the OS layer. An attacker with administrator or physical access drops one of these legacy signed shims onto the system. At next boot, the UEFI firmware sees a Microsoft-signed binary and allows it to load, because the firmware's forbidden signature list does not yet include that shim. The shim then executes attacker-controlled code before the operating system has a chance to apply its own security controls.
The practical payoff is bootkit deployment. Bootkits including Bootkitty, HybridPetya, and BlackLotus all operate from this pre-OS position, giving them persistence that survives OS reinstalls, antivirus scans, and most endpoint detection tools. Detection surface for firmware-level persistence is narrow; most enterprise security tooling does not operate there.
The gap between OS patching and dbx patching
This is the part that should concern security operations teams more than the vulnerability itself.
ESET's report is titled 'Forgotten UEFI shims undermining Secure Boot.' The word 'forgotten' is doing a lot of work. The shims were revoked months ago. The mechanism for distributing that revocation exists. What is missing, on many devices, is the operational process to confirm the revocation actually landed.
A device can have a fully current Windows installation with every June and July patch applied and still be vulnerable if the firmware's dbx was not updated. The dbx update is not automatic for all device configurations; on some hardware it requires a separate step or a BIOS/UEFI firmware update from the manufacturer. Your patch compliance dashboard showing 100% on the June rollup does not confirm dbx status.
What to do
First, verify June 9 Patch Tuesday uptake on all managed devices, specifically the Secure Boot updates, not just the Windows OS components. Second, check whether your device firmware has received a dbx update corresponding to the June revocation list. Third, for environments where UEFI Secure Boot is a meaningful security control, add dbx revocation verification to your compliance checks separately from OS patch compliance.
ESET published the list of vulnerable shim versions and their hashes in their research. Those hashes should be added to asset inventory checks if you have the capability to audit at the firmware level.
Gigia Tsiklauri is a Security Architect and founder of Infosec.ge. Get in touch if you want to discuss firmware security or Secure Boot configuration for your environment.