Security researchers at ESET have detailed a hole in Microsoft Secure Boot that was quietly exploitable for over a decade. The finding is uncomfortable because Secure Boot is one of the foundational trust mechanisms on modern PCs, and the bypass hinges on eleven old firmware shims that Microsoft still signed and that UEFI systems continued to trust. By the time anyone noticed and acted, the certificates involved had been trusted trust anchors for years.
What Secure Boot is supposed to do
Secure Boot is the UEFI mechanism that checks that only signed, trusted code runs early in the boot process, before the operating system loads. Its whole purpose is to stop malware from planting itself before the OS starts, which is why bootkits that survive OS reinstallation are so dangerous. If an attacker can run unsigned code at that early stage, they can intercept everything downstream.
The trust chain depends on a database of allowed signatures and a separate list of revoked ones. Microsoft’s UEFI CA 2011 certificate sits near the top of that chain, and anything it signed was treated as trustworthy. The problem is that signed things never stop being dangerous just because they are old.
The bug itself
The researchers identified eleven Microsoft-signed UEFI shims, some dating back to 2013, that carried flaws allowing them to be abused. The core issue is tracked as CVE-2026-10797, a discrepancy in how signature verification was handled that let an attacker bypass certificate-based revocation. In plain terms: a defender could revoke a bad certificate, but the vulnerable shim checked signatures in a way that ignored the revocation and let the evil code through anyway.
Because these shims were still signed and still on the trust list, any UEFI device relying on the Microsoft UEFI CA 2011 certificate was potentially exposed. Attackers could use the flaw to drop persistent bootkits, including families like BlackLotus, onto systems where Secure Boot was, as far as the user knew, enabled and working. The bootkit survives OS reinstall because it lives below the OS.
Why it stayed hidden and why fixing it is hard
The gap persisted for a decade partly because these shims were never intended to be attack vectors, they were trusted code that in theory only ran legitimate workloads, so nobody scrutinized them as an entry point. That is the uncomfortable part of a centralized root of trust: one trusted entity, if compromised or merely flawed, undermines the whole model.
Fixing it is also technically awkward. Revocation uses the UEFI dbx database, which is limited to about 32 kilobytes of storage. When you need to revoke a growing pile of hashes, that tiny fixed-size list becomes a real constraint. You cannot simply keep appending forever, so the platform has a scaling problem baked into its design. Microsoft revoked the affected shim hashes in the June 9, 2026 Patch Tuesday update, but the mechanism itself stays cramped.
What you should do now
If you administer Windows machines, the first step is confirming the June 2026 updates are actually installed. Secure Boot and dbx updates usually flow through Windows Update, but on machines that are patched infrequently or air-gapped, they can silently lag. Verify the update applied, then spot-check a couple of representative systems rather than assuming every machine is current.
On Linux, check for firmware updates through the vendor firmware service, which on most distributions is fwupd. Kernel and userspace patches matter, but the UEFI-level fix is the one that closes the boot-path gap. If you have fleet tooling, script a check that compares the installed dbx against the list of known vulnerable shim hashes so stragglers surface instead of lingering.
The practical reality is that this particular attack typically requires physical access or a way to get code running in a privileged position first. That lowers the everyday risk for the average user. But for anyone in a high-value position, a device that is presumed clean because Secure Boot reports enabled is exactly the false confidence this bug exploits. Treat the fix as important rather than urgent, and do not skip it on the machines that matter most.
Determining whether you are exposed
The exposure window depends on which shims your hardware trusts and how observably vulnerable they are. In practice, the highest-risk targets are fleets where firmware is treated as a set-and-forget component and machines report Secure Boot as enabled without anyone confirming the dbx is current. If you cannot easily tell whether a system has the June update, that is itself the finding worth acting on, it means your firmware patch status is not being tracked.
For most single users, a straightforward approach is acceptable: keep the OS up to date, let firmware updates flow through the normal channels, and do not over-rotate on the theoretical physical-access threat. For administrators of sensitive systems, treat this like a firmware patching audit, inventory the devices, confirm dbx freshness, and close the gaps. Either way the recurring theme is the same, the weakest link is not the shim, it is the machines nobody checked.
The lesson that sticks
The Secure Boot saga is a reminder that trust is not permanent. A signature valid today is not a guarantee the code is safe forever, and a root of trust that nobody re-examines is a liability that compounds with age. The incident is also a genuine argument for keeping the trust model more open and for treating revocation infrastructure, despite its storage limits, as core security that deserves attention and capacity. The fix is rolling out, but the design tension it exposed will outlast this patch cycle.