Cybersecurity

Eleven Signed Bootloaders Can Bypass Secure Boot

ESET found eleven old Microsoft-signed bootloaders that slip past Secure Boot on almost any PC, with no admin rights needed. Patching them is the easy part. Here is the exposure most fleets never audit.

CybersecurityBy Servola Tech Desk2026-07-153 min read

AI-assisted, edited by humans. | Editor-in-Chief: Leon Soliman | Editorial standards

Eleven Signed Bootloaders Can Bypass Secure Boot

Key takeaways

ESET found eleven old Microsoft-signed bootloaders that defeat Secure Boot on almost any PC, and the attacker needs only file access to the boot partition, not administrator rights, so malware already on the machine is enough to plant code that runs before Windows even starts.
Microsoft revoked the eleven files in its 9 June update, but that block only takes effect once the firmware blocklist known as dbx reaches each device, and pushing dbx is the step administrators most often postpone because a bad entry can stop a machine from booting.
The exposure is not limited to the eleven named files, because the public record of signed bootloaders only goes back to 2017, so no one can say how many older trusted ones remain, which makes eleven a floor rather than a total.
This is a firmware problem, not a Windows problem: the same trusted signature works under any operating system, so Linux servers, appliances, and dual-boot laptops are all in scope, and under NIS2 the integrity of the boot chain now sits inside the security measures essential entities must be able to prove.

A valid signature stopped meaning safe code

Secure Boot did exactly what it was built to do, and that was the problem. On 14 July the security firm ESET published research, led by Martin Smolar, showing eleven Microsoft-signed bootloaders, all at version 0.9 or below, that a machine will happily run because the signature is genuine. The code behind that signature is a decade old and broken, but Secure Boot checks the signer, not the safety of what was signed.

The result is an attacker who can execute unverified code at boot time on nearly any UEFI computer. ESET reported the finding to the coordination centre CERT/CC in February, and Microsoft added all eleven files to its revocation list on 9 June. The gap between a trusted signature and trustworthy code is the whole story, and it is not closed by the patch alone.

How the bypass works

The attacker does not break anything; they supply something already trusted. Most UEFI systems carry Microsoft's third-party certificate, the Microsoft Corporation UEFI CA 2011, in their list of allowed signers. An attacker copies one of the old signed bootloaders onto the EFI System Partition, the small boot area of the disk, and the firmware accepts it because the signature traces back to that trusted certificate. No administrator rights are needed, only the ability to write that file.

From there, three old gaps do the work. The bootloaders trust outdated GRUB 2 code carrying a 2015 flaw that runs unverified modules; versions below 0.9 lack the revocation list that would block known-bad certificates; and versions before 15.3 ignore SBAT, the newer mechanism meant to retire vulnerable binaries. Tracked as CVE-2026-8863 and CVE-2026-10797, the chain ends with attacker code running before the operating system loads, which is the ideal place to hide.

Why the patch is the easy part

Revocation only protects a machine that actually received it. Microsoft's 9 June fix adds the eleven files to dbx, the firmware blocklist, and on managed Windows fleets that update flows through normal channels. The catch is that many organisations deliberately hold back firmware-level blocklist changes, because a wrong dbx entry can leave a device unable to boot, and that risk is higher on older or dual-boot hardware. The revocation exists; whether it reached your machines is a separate question.

The deeper issue is counting. The public shim-review record only began in 2017, and there is no comparable list of what was signed before then, so no one can state with confidence how many old, still-trusted bootloaders are out there. Eleven is the number ESET could name, not the number that exists. A control that depends on knowing every trusted signer is weak exactly where the inventory runs out.

What to actually check this week

Treat this as a revocation-hygiene task, not a single patch. Confirm that the 9 June dbx update genuinely applied across the estate rather than assuming it did; ESET points to audit tooling and PowerShell checks that report the current revocation state. Extend the check beyond Windows, because Linux servers and appliances take the same fix through the Linux Vendor Firmware Service, and dual-boot laptops are the classic blind spot.

For European operators the framing is now regulatory as well as technical. Under NIS2, the integrity of the boot chain falls within the security measures an essential entity is expected to demonstrate, and a firmware bootkit is exactly the kind of persistence a supervisor will ask about after an incident. The owner action is simple to state and easy to skip: verify what your firmware still trusts, and prove the block landed.

Frequently asked questions

Do I need to do anything if my PCs already get Windows updates automatically?

Possibly. The revocation ships through normal update channels, but many organisations pause firmware-level blocklist changes because a bad entry can stop a device from booting, especially older or dual-boot hardware. Confirm the 9 June dbx update actually applied on your fleet rather than assuming it did; the audit tools ESET points to will tell you the real state.

Can this be exploited remotely?

No. An attacker needs to place a file on the machine's EFI System Partition, which means local access or code already running on the device. That lowers the drive-by risk but makes it a strong persistence tool, because a bootkit installed this way runs before the operating system and survives an ordinary reinstall.

Does this only affect Windows machines?

No. The trust anchor is Microsoft's third-party UEFI certificate, which sits on most UEFI systems regardless of operating system. A Linux server, a network appliance, or a dual-boot laptop can be targeted with the same signed bootloader, which is why the fix belongs in firmware and boot-chain hygiene, not only in Windows patching.

Secure Boot was never a wall; it was a list of who to trust. Eleven forgotten bootloaders show how quietly that trust decays, and the only defence that keeps pace is revocation you have verified reached the machine. Patching the named files takes a day. Knowing what your firmware still trusts is the work that protects you.

Secure BootUEFIESETMicrosoftfirmwarebootkitNIS2CVE-2026-8863

Progress tells ShareFile users to pull the plug

Progress Software told ShareFile customers to physically shut down on-prem Storage Zone Controllers over a credible threat. No patch, no CVE. What owners should learn.

3 min read

Cybersecurity

CISA's First AI Agent Platform Is Now a Must-Patch

CISA added Langflow, a popular tool for building AI agents, to its must-patch list after attackers exploited a flaw to steal companies' AI and cloud keys. It is the first AI agent platform the agency has ever flagged, and the fix is upgrade plus key rotation, now.

3 min read

Digital Sovereignty

The EU Council Revived the Rule That Scans Private Messages

The EU Council revived the lapsed rule that lets providers scan private messages with AI. For owners, confidential communication is now a governance choice.

2 min read

← All articles