BlackX UEFI bootkit infected Windows fleets that had CVE-2022-21894 mitigations installed
BlackX compromised Windows systems that had received Microsoft’s staged mitigations for CVE-2022-21894, the Secure Boot bypass behind BlackLotus. Those updates add a 2023 certificate and a path to revoke the 2011 production CA; they do not prove the revocation was written into firmware. OS patch compliance does not measure the boot chain.
BlackX, a UEFI bootkit, infected organizations whose Windows machines carried Microsoft’s published mitigations for CVE-2022-21894, a boot-manager logic flaw known as Baton Drop. The same class of flaw powered BlackLotus, documented in 2023 as the first in-the-wild UEFI bootkit to bypass Secure Boot on fully updated Windows 11. Victim fleets had the 2022 boot-manager fix, the May 2023 addition of Windows UEFI CA 2023, and the 2024 update that can place Windows Production PCA 2011 on the forbidden-signature list. An attacker still needs a prior compromise. The implant can outlive an OS reinstall if the EFI system partition remains.
CVE-2022-21894 was fixed in the boot manager in 2022. Microsoft did not, in that same step, revoke the certificate that still signed older vulnerable managers. Secure Boot trusts binaries signed by certificates in its allowed database and rejects those listed in the forbidden database, DBX. The May 2023 updates added Windows UEFI CA 2023 to the allowed set. The 2024 updates supplied a way to add Windows Production PCA 2011 to DBX. Installing those packages is not the same as writing the revocation into firmware non-volatile variables. The account does not assign BlackX its own CVE or a victim count.
The failure mode is the trust anchor, not a missing Windows patch. Secure Boot decides in firmware variables, DB and DBX. Windows Update cannot always rewrite them without breaking recovery media, older images, and OEM firmware that still depends on the 2011 production certificate. Revocation was staged across 2023 and 2024 and left for administrators to apply. A device Windows marks current can still execute a boot manager signed by a certificate never written into DBX. Code that runs that early can load a kernel driver before endpoint agents start. Patch dashboards then certify the OS, not the boot chain.
Operators should treat Secure Boot state as a configuration item, not an assumed feature of a current Windows build. Per device, confirm Windows UEFI CA 2023 is present in DB and that Windows Production PCA 2011 is present in DBX, then inspect the EFI system partition for a pre-revocation boot manager. Reimaging without touching that partition does not clear this class of implant. Microsoft’s own rollout already showed that blanket DBX enforcement breaks legitimate boot media, so further guidance will stay phased and OEM-dependent. Expect compliance tooling, not a single silent update, to decide whether fleets actually close CVE-2022-21894.
Sources (2)
- [1]Original source(https://arstechnica.com/security/2026/11/uefi-bootkit-infected-fully-patched-windows-machines-is-microsoft-to-blame/)
- [2]Microsoft CVE-2022-21894(https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-21894)