Most patch reports end with one line: install the update and you're covered. A new report from Kaspersky's Global Research and Analysis Team (GReAT) shows a case where that line is wrong. The researchers describe a UEFI bootkit they call BlackX. It was used against diplomatic agencies in Central Asia and ran on Windows machines that were fully patched. According to the researchers, it got through because the fix for the flaw it abuses doesn't take effect until an administrator performs extra manual steps, which they say few organizations realized were necessary.
The report on Kaspersky's Securelist blog was written by Georgy Kucherin, Vladimir Nestor and Vasily Berdnikov. It says BlackX closely resembles BlackLotus, the well-known bootkit, and that it exploits the same Secure Boot weakness: CVE-2022-21894, nicknamed "Baton Drop." Below are the key questions and what the sources say.
What is BlackX, and who was hit?
A bootkit is malware that runs during the boot process, before Windows loads. A UEFI bootkit sits in the firmware-driven startup chain, the code a PC runs between power-on and the operating system. Because it starts before the OS, it can hide from, or interfere with, the security tools that load later. It also survives reboots. That is why defenders treat this class of malware so seriously.
According to The Hacker News, which reported on the research on Oct. 23, 2026, the targets were diplomatic entities in Tajikistan, Uzbekistan and Turkmenistan, and the attacks took place in early 2026. Kaspersky says BlackX was not an initial-access tool. Attackers deployed it after they had already gained administrator rights on a victim's network. In other words, it was used to keep a foothold, not to break in.
Why did it work on patched machines?
Baton Drop is old. The National Vulnerability Database lists CVE-2022-21894 as published on Jan. 11, 2022, and describes it as a "Secure Boot Security Feature Bypass Vulnerability." Secure Boot is the firmware feature meant to ensure that only trusted, signed boot software runs. Baton Drop lets an attacker get around that check.
According to Kaspersky, Microsoft's patch does not fully neutralize the attack when it is installed. To shut Baton Drop down, the old, vulnerable boot components have to be untrusted. That means revoking the Windows Production PCA 2011 certificate that signed them. Kaspersky says the revocation does not happen automatically on installation. The user has to trigger it by setting a registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot and creating a scheduled task named Secure-Boot-Update. Without those steps, the machine can be patched yet still accept the vulnerable boot code that BlackX relies on.
The researchers say the BlackX victims were fully patched. The update was installed. The revocation step that makes it effective was not done.
Doesn't the old certificate expire anyway?
It did. The Hacker News reports that the Windows Production PCA 2011 certificate expired on Oct. 19, 2026. Expiry does not solve the problem. The outlet notes that an expired certificate does not stop vulnerable binaries it signed from loading unless those binaries are blocklisted in the DBX, the Secure Boot "forbidden" database the firmware checks before running boot code. Expiry is a date on the certificate. Revocation and blocklisting are what actually stop the old code from running.
Is this just BlackLotus again?
Not exactly. Kaspersky describes BlackX as resembling BlackLotus. The Hacker News adds a point about where it could have come from: BlackLotus's source code was never made public. So whoever built BlackX either reverse-engineered BlackLotus or bought its source code. The sources don't say which.
Who is behind it?
Kaspersky attributes the activity to APT41 with medium confidence. APT41 is a label the security industry uses for a long-running threat group. Kaspersky's case rests on several overlaps. One is an "xdd" identifier the researchers link to a June 2026 ESET publication on a group ESET tracks as FishMonger. The others are tradecraft: DLL sideloading, a technique where a legitimate program is tricked into loading a malicious library, and OLLVM obfuscation, a compiler-level method for making code harder to analyze. Medium confidence means Kaspersky considers the link likely but not proven. Treat the attribution as Kaspersky's assessment, not settled fact.
How worried should I be?
On paper, CVE-2022-21894 is not a severe bug. Microsoft gave it a CVSS 3.1 base score of 4.4 (Medium). The scoring vector in the NVD record shows a local attack vector and high privileges required. The Hacker News reports that Microsoft has previously described bootkits like this as a persistence mechanism that needs administrator or physical access.
That framing is accurate, and it is also why the score understates the risk to some organizations. Nobody uses Baton Drop to get in. It is what an intruder who already has admin rights uses to make sure they stay. A foothold that loads before Windows does is harder to dislodge than ordinary malware, so persistence is the whole point. Kaspersky's driver also tampers with security software on the machine.
What It Means for Defenders
Who is affected: Any Windows machine with Secure Boot where the Baton Drop update was installed but the Windows Production PCA 2011 revocation was never completed. Kaspersky says it is extremely unusual for administrators to take extra steps after installing an update, so many fleets may be in this state, though the report gives no figure. The confirmed victims were diplomatic organizations in Central Asia. Government agencies, defense contractors and similar organizations may reasonably treat themselves as the kind of target this tooling suits; that is our inference, not a Kaspersky finding.
Check revocation, not just patch status. A green "up to date" status in your patch tool does not settle this. Based on the sources, the question to ask is whether the PCA 2011 revocation has actually been applied. Kaspersky says it depends on the Secure Boot registry flag under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot being set and the Secure-Boot-Update scheduled task being created. Work out which of your endpoints have completed that process, and follow Microsoft's official guidance for applying it. Revoking boot certificates changes what firmware will accept at startup, so test it on a pilot group of hardware models before a broad rollout.
Don't count on the certificate's expiry. The Oct. 19, 2026 expiry date does not block vulnerable boot binaries. Only blocklisting through the DBX does that, according to The Hacker News.
Guard admin rights. Kaspersky observed attackers deploying BlackX only after they had obtained administrator privileges, and Microsoft, as quoted by The Hacker News, says bootkits like this need privileged or physical access. Tight control of privileged accounts, phishing-resistant MFA for admins, and close monitoring of privilege escalation and lateral movement are the controls that keep attackers from reaching the stage where a bootkit is an option.
Plan incident response with firmware in mind. If you find admin-level compromise on a high-value system, the response should account for persistence below the operating system. A clean OS reinstall may not be enough, since the bootkit installs files to the UEFI partition (our inference for response planning). Kaspersky's indicators of compromise and technical details are in the Securelist report linked below.
For CMMC and other compliance programs: Treat the completed Secure Boot revocation as an explicit configuration baseline item. "Patch installed" and "mitigation in effect" are separate controls, and BlackX shows the cost of mixing them up.
