On July 14, 2026, Microsoft rolled out cumulative update KB5101650 for Windows 11 versions 24H2 and 25H2. While the patch notes highlight a list of routine fixes, the update also delivered a less-publicized but critical security payload: it finally revoked trust in 11 Microsoft-signed UEFI boot shims that attackers could leverage to slip past Secure Boot and plant deeply persistent malware.

The revocations first appeared in the June 9, 2026 Patch Tuesday release KB5094126, but because Windows servicing is cumulative, installing KB5101650 brings your system up to date with the same protections. Once applied, compliant firmware will refuse to run the vulnerable bootloaders even though they carry Microsoft’s cryptographic signature.

The Revocation List: 11 Shims Sent to the Forbidden Zone

Secure Boot is supposed to stop unauthorized code from executing before your operating system loads. Firmware checks boot applications against a trusted signature database, but it also maintains a blocklist—the UEFI Forbidden Signature Database (DBX)—where known-bad binaries are recorded. KB5101650 adds the cryptographic hashes of 11 specific shim bootloaders to that DBX.

A shim is a small first-stage bootloader that bridges Microsoft’s Secure Boot trust model with Linux distributions and other third-party operating environments. Microsoft signs approved shims so they can run on PCs whose firmware trusts the Microsoft Corporation UEFI CA 2011 certificate. That interoperability, however, created a long-term security obligation. A valid signature can keep an ancient binary trusted for years unless it is explicitly revoked.

According to ESET researchers, the revoked shims—dating as far back as 2015—miss modern revocation defenses like Secure Boot Advanced Targeting (SBAT) or proper Machine Owner Key deny list handling. They were found in products including older Red Hat Enterprise Linux and CentOS media, Spyrus WTGCreator, baramundi Management Suite, WhiteCanyon WipeDrive, Finland’s Abitti examination environment, ROSA Linux, and PC-Doctor Service Center. The vulnerability is tracked under CVE-2026-8863 and CVE-2026-10797.

Crucially, an attacker does not need you to have any of those products installed. The “Bring Your Own Vulnerable Bootloader” technique means a signed, exploitable shim can be copied onto any target system. If the firmware still trusts the signing certificate and hasn’t received the DBX update, Secure Boot may wave the malicious bootloader right through.

What This Means for You – Home Users, Admins, and Developers

Home and Everyday Users

If you let Windows Update do its job, you’re already protected. The July cumulative update installs the new DBX entries automatically. Keep Secure Boot enabled in your UEFI settings—disabling it would undo the patch’s primary defense. There is no additional action required unless you use old, unsigned bootable USB drives or recovery media created with one of the vulnerable shims. Those may stop booting after the update, which is the intended behavior.

IT Administrators and Enterprise Environments

The update is not just a checkbox. Administrators must verify that the DBX entries have actually taken effect. Simply approving the update through WSUS, Windows Update for Business, or endpoint management tools does not guarantee deployment if devices are offline or have pending reboots. More importantly, any business-critical boot environment that relies on an older Linux deployment image, diagnostic tool, or disk-wiping utility may stop working. Organizations using older versions of baramundi Management Suite, WipeDrive, or PC-Doctor should test boot media before broad enforcement. Updating those products or rebuilding media with a current shim (version 15.3 or later) is vastly preferable to disabling Secure Boot to keep a legacy image running.

Inventory machines that don’t receive regular Windows updates—offline workstations, lab equipment, and systems that boot primarily into another OS. The trust decision happens in firmware, so a PC can remain exposed even if Windows isn’t its main workload. For deployment teams updating Windows installation images, Microsoft warns that the matching boot.stl file must be included with the updated image; omitting it can cause Secure Boot validation failures with error code 0xc0430001.

Developers and Linux Dual-Booters

If you maintain Linux installation media or custom bootloaders signed under the Microsoft third-party UEFI certificate, ensure you are using a shim version 15.3 or newer with SBAT support. Older builds may now be blocked. Generating new boot images against an up-to-date shim is the only supported path. This is not a Windows compatibility issue—your firmware is simply following the updated revocation list.

A Decade in the Making: How Old Signatures Became New Liabilities

The problem’s roots stretch back to the Windows 8 era, when Microsoft established the third-party UEFI certificate authority to allow non-Windows boot environments on Secure Boot PCs. The shims signed under that authority were intended to be ephemeral—replaced when the operating system’s own bootloader took over. But many of those shims remained in circulation, embedded in recovery partitions, network-boot images, and utility ISOs long after their original developers moved on.

ESET’s research revealed that some of these shims predate the introduction of modern revocation controls. Without SBAT, which allows blocking a specific generation of bootloader without nuking every signed binary from the same vendor, the only way to revoke them was through direct DBX hashing—a manual process Microsoft had not completed for these 11 binaries. One decade later, the gap was finally closed.

The timing coincides with an ongoing Secure Boot certificate replacement. Microsoft says certificates used by most Windows devices began hitting expiration milestones in June 2026, and it has been staging new certificates through Windows Update on a device-targeted basis. KB5101650 includes additional targeting data to expand that rollout. But certificate renewal and DBX revocations address different threats—receiving one does not mean your entire Secure Boot trust chain is modernized.

Your Action Plan: From Patching to Double-Checking Boot Media

1. Install the update. For Windows 11 24H2 and 25H2, KB5101650 (builds 26100.8875 and 26200.8875) supersedes the June release. If you haven’t patched yet, go to Settings > Windows Update and check for updates. A known incompatibility temporarily blocks the update on a limited number of Dell devices with Intel processors—if you own one, monitor Dell’s support channels for a resolution.

2. Confirm Secure Boot is on. Open System Information (msinfo32.exe) and look for “Secure Boot State.” It should read “On.” If it’s off or unsupported, your firmware can’t enforce the DBX and you remain vulnerable even after patching.

3. Audit your bootable devices. Gather every recovery USB, network boot image, and diagnostic ISO your team uses. If any contain bootloaders signed by the Microsoft Corporation UEFI CA 2011 certificate but don’t use a modern shim, they may be blocked. Identify those tools and check with the vendor for updates.

4. Test before broad enterprise rollout. Deploy to a pilot group and attempt to boot from each critical piece of boot media. If something breaks, rebuild it with a current shim rather than pausing the security update. The rollout is cumulative—you can’t skip the DBX entries while still applying other patches.

5. Include boot.stl when updating installation media. If you maintain custom Windows installation images, follow Microsoft’s guidance to either use the Update WinPE script or manually copy the boot.stl from Windows\Boot\EFI to your media. Missing this file will cause Secure Boot validation to fail with error 0xc0430001.

6. Track the certificate transition separately. KB5101650 expands which devices are eligible to receive new Secure Boot certificates, but the process is gradual. Use the Windows release health dashboard to monitor your estate’s readiness for future boot-critical servicing.

What’s Next: The Broader Secure Boot Overhaul

This update closes one long-neglected attack surface, but ESET cautioned that it’s impossible to guarantee every obsolete Microsoft-signed shim has been found. For administrators, July’s patch is both a required security fix and a prompt to audit every piece of boot code that still leans on the aging 2011 certificate authority.

The larger message is clear: a valid signature is not a permanent hall pass. As the Secure Boot infrastructure modernizes, expect more legacy components to be revoked—and expect to invest real effort in replacing them before they abruptly stop working at your organization’s worst possible moment.