BlackX UEFI Bootkit: Why Patched PCs Still Fell to Baton Drop

BlackX is a UEFI bootkit, disclosed on 22 October 2026, that bypassed Secure Boot on fully patched Windows machines at diplomatic agencies in Central Asia. It abuses Baton Drop (CVE-2022-21894). The fix only works once you revoke "Windows Production PCA 2011" yourself, using Microsoft's KB5025885 steps. Check your fleet's DBX state now.

The research comes from a single security vendor, which attributes the campaign to APT41 with medium confidence. Treat that as one vendor's assessment, not a settled fact. The lesson for every Windows estate does not depend on who ran it: the patch was installed, and the boot chain was still open, because the step that closes it is a separate, manual, irreversible firmware change many organisations have never made.

What happened

According to the vendor report, its researchers found a BlackLotus-like UEFI bootkit in early 2026 while investigating an APT campaign against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. They named it BlackX. The attackers deployed it only after they had compromised the victims' networks and obtained administrator rights.

The researchers first assumed the machines were missing updates. They were not: "the targeted machines were fully patched," the report says. The Baton Drop protection depends on revoking a Microsoft signing certificate in the firmware's revocation database, and that revocation is not applied automatically when the update installs.

Timeline

One date in the vendor report differs from Microsoft's records. The report places Baton Drop's disclosure and patch in 2023, but the MSRC record shows CVE-2022-21894 was released on 11 January 2022. What arrived in 2023 was the revocation based mitigation, published under CVE-2023-24932 and documented in KB5025885. The two CVEs are related but separate.

Who is affected

The report names diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan as targets. It gives no victim count, and we do not estimate one.

How the bypass works, in plain language

Secure Boot is a chain of signatures checked by firmware before Windows starts. The firmware holds a few databases in non volatile UEFI variables:

• PK, the platform key, owned by the device maker.
• KEK, the key exchange keys, which authorise updates to the two databases below.
• DB, the allowed signatures. Certificates here are trusted to sign boot loaders.
• DBX, the forbidden signatures. Hashes or certificates here are refused, even if DB would otherwise trust them.

For years, Windows boot managers were signed under Microsoft Windows Production PCA 2011, which sits in DB. When Microsoft fixed Baton Drop in January 2022, it shipped a corrected boot manager, but the old, vulnerable boot managers stayed validly signed. Firmware does not know a binary is old. It checks the signature, sees a trusted certificate and runs it.

So an attacker with administrator rights can place an old signed boot manager in the EFI System Partition (ESP) of a fully patched machine and the firmware will run it. This is a downgrade attack. Patching the boot manager on disk does nothing about copies the attacker brings.

Blocking that means telling firmware to distrust the old signatures. Adding every vulnerable binary's hash to DBX does not scale, because DBX space is small. Microsoft's approach in KB5025885 is to move Windows boot to a new certificate, Windows UEFI CA 2023, then put PCA 2011 itself into DBX, so every boot manager signed by it is refused.

That final step is manual for a reason. KB5025885 warns that the revocations are permanent once applied with Secure Boot on, that old install and recovery media will stop booting, that some devices may enter BitLocker recovery, and that dual boot systems with un-updated Windows may fail to start. An automatic rollout would break real machines, so Microsoft staged it.

What the bootkit does after the bypass

As with BlackLotus, the vendor report says the goal of the exploit is to install custom Machine Owner Keys (MOK). MOK is the mechanism that lets the shim boot loader, used mainly by Linux distributions and signed by Microsoft under its third party UEFI CA, trust additional keys chosen by the machine's owner. If an attacker can write their own certificate into the MOK list, shim will then load attacker signed EFI binaries on every boot, without the exploit having to run again. The March 2023 analysis of BlackLotus describes the same pattern: a self signed certificate in the boot only MokList variable and a legitimate Microsoft signed shim loading the bootkit.

From there, per the vendor report:

1. The UEFI payload injects a malicious driver into the Windows kernel. The driver differs from BlackLotus's and is signed with a certificate issued to 温江区明宇网络技术服务工作室 (Wenjiang District Mingyu Network Technology Service Studio), serial 0bcdf5e0da32d68900b8b7638459d072. The report says the issuer has revoked that certificate.
2. The driver disables process, thread and registry callbacks belonging to security products and tampers with Event Tracing for Windows (ETW) providers so security tools cannot read their output. The report notes that some routines only run when two specific security products are installed, and that in its testing they did not work against its own product.
3. The driver protects the bootkit's files. When something in the kernel asks to open one of them, it hands back a handle to calc.exe instead.
4. The driver deploys user mode payloads used for espionage.

That third point matters: inspected from inside its own running Windows, an infected machine may lie. Inspect offline.

The user mode payloads

The report describes two payloads seen in the wild.

A RAT using cloud storage for command and control. Versions used Google Drive, OneDrive and Yandex.Disk. The RAT lists files in the storage account and acts on them by suffix:

Because the domains are legitimate, watch which processes talk to them rather than blocking them.

OxiDLLRunner. A malicious DLL obfuscated with OLLVM, loaded by DLL sideloading into a legitimate executable. The executable is dropped as googleupdate.exe, but its original file name is jcef_helper.exe (MD5 AF8A983B9ADA07EAE1259BF2953ABD40). The DLL decrypts v8_context_snapshot.bin from the same folder and jumps into it. The decrypted data is shellcode followed by a Rust payload that talks to www[.]archivetj[.]com and receives further DLLs exporting a function named create_plugin, each run in its own thread.

Technical details

Everything in this section comes from the sources listed at the end. Indicators are reproduced as published; domains are defanged as in the source.

Vulnerabilities

The CVE-2022-21894 record still shows "Exploited: No" because it was never revised after BlackLotus; do not read that flag as current. Both CVEs require high privileges (PR:H): a bootkit is a persistence step, not an entry point. We checked the CISA KEV JSON feed on 24 October 2026 (catalog 2026.10.23) and neither CVE was listed, so KEV driven prioritisation will not surface them.

Indicators of compromise published in the vendor report

The report publishes no SHA-1 or SHA-256 hashes, IP addresses, driver file name or storage accounts. Beware false positives: v8_context_snapshot.bin and jcef_helper.exe are legitimate Chromium related names. What is unusual is jcef_helper.exe running as googleupdate.exe with a v8_context_snapshot.bin beside it.

Artifacts from earlier BlackLotus guidance that still apply

Microsoft's April 2023 BlackLotus investigation guidance lists these artifacts. The BlackX report does not confirm them for BlackX, so treat them as leads.

The certificates involved

Source: KB5062710. The UEFI CA 2011 renewal splits boot loader signing from option ROM signing so each can be trusted separately.

Microsoft's revocation controls (KB5025885)

Registry location: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Secureboot, value AvailableUpdates (REG_DWORD). Scheduled task: \Microsoft\Windows\PI\Secure-Boot-Update. These are the "registry flag" and "Secure-Boot-Update" task the vendor report refers to.

These values are as published when we read the KB (latest change log entry 30 September 2026). It changes often; the old 0x100 step was removed in April 2026. Confirm the live KB before acting.

Status value: HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing, UEFICA2023Status, which should read Updated.

Event IDs to collect (KB5016061)

These are written by the TPM-WMI source in the System log.

Event 1037 proves the revocation is applied. Event 1033 deserves its own alert: Windows found a boot manager in the ESP that the revocation would block.

The missing enforcement step

KB5025885's final Enforcement Phase will add PCA 2011 to DBX automatically, with no option to disable it. Its date is "to be announced"; the KB says it will not begin before January 2026 and that Microsoft will give at least six months' notice. The vendor report says that as of 22 October 2026 this phase had not started. Until it does, the revocation is opt in.

What the 19 October expiry does and does not change

Windows Production PCA 2011 expired on 19 October 2026, three days before the BlackX report. An expired certificate in DB does not stop firmware loading binaries signed under it. The vendor report says expiry does not block the vulnerable binaries unless the certificate is in the blocklist.

Microsoft's KB5062710 adds the other half. Devices without the 2023 certificates keep starting normally and keep receiving standard Windows updates, but they can no longer receive new early boot protections: boot manager updates, Secure Boot database and revocation list updates, and mitigations for new boot level flaws.

So an un-updated device after 19 October gets the worst of both: vulnerable PCA 2011 signed boot managers still load, and future boot fixes cannot reach it. Expiry is a reason to finish the migration now, not a sign the problem solved itself.

The Linux and shim parallel

The mechanism BlackX abuses is shared with Linux. Most distributions boot under Secure Boot through shim, a small loader signed under Microsoft's third party UEFI CA, which then trusts the distribution's key and any keys enrolled in MOK. That lets owners run their own kernels, and it is also why MOK is an attractive target: a legitimately signed shim honours whatever MOK holds.

Linux met the signed but vulnerable problem at scale with BootHole (CVE-2020-10713) in GRUB. According to the shim project's SBAT documentation, the response added about 150 image hashes and 3 certificates to DBX, using roughly 10 kB of a typical 32 kB store. That pressure led to SBAT (Secure Boot Advanced Targeting): each component carries a generation number, and an SbatLevel UEFI variable stores the minimum firmware will accept. Microsoft revoking PCA 2011 as a whole is the same idea at a coarser grain: revoke the trust anchor, not each binary. Both only work once written to each machine's firmware.

Linux checks for mixed estates:

# Is Secure Boot enforcing?
mokutil --sb-state

# Which Machine Owner Keys are enrolled? Anything you cannot explain is a finding.
mokutil --list-enrolled

# Any pending MOK enrolment requests waiting for the next boot?
mokutil --list-new

# What does the firmware boot, and from which ESP path?
efibootmgr -v

# Unexpected EFI binaries on the ESP (path varies by distribution)
sudo find /boot/efi -iname '*.efi' -printf '%TY-%Tm-%Td %TH:%TM %p\n' | sort

On dual boot machines, remember KB5025885's warning: every Windows installation on the device must be updated before the revocation, or the un-updated one may stop booting.

What to do now

The steps below are ordered from read only checks to irreversible changes. Do the read only steps on every Windows device you own before you touch firmware anywhere.

1. Measure: find out which devices are revoked

Run as administrator on a Windows device:

# Secure Boot on?
Confirm-SecureBootUEFI

# Is Windows UEFI CA 2023 in DB? (True is good)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023'

# Is PCA 2011 in DBX? (True means the revocation BlackX needs absent is in place)
[System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'

# Servicing status (expect "Updated")
(Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing").UEFICA2023Status

# Any pending AvailableUpdates bits
Get-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Secureboot" -Name AvailableUpdates -ErrorAction SilentlyContinue

# Relevant TPM-WMI events
Get-WinEvent -FilterHashtable @{LogName='System'; Id=1033,1036,1037,1042,1795,1796,1797,1798,1799,1801,1808} -MaxEvents 50 |
  Select-Object TimeCreated, Id, LevelDisplayName, Message

To collect the same data across a fleet, wrap it in a script block and run it through your management tooling or PowerShell remoting:

$check = {
  $sb = $null; try { $sb = Confirm-SecureBootUEFI } catch { $sb = 'Unsupported' }
  $db = $dbx = $null
  if ($sb -eq $true) {
    $db  = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes)  -match 'Windows UEFI CA 2023'
    $dbx = [Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
  }
  $status = (Get-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing' -ErrorAction SilentlyContinue).UEFICA2023Status
  [pscustomobject]@{
    Computer        = $env:COMPUTERNAME
    SecureBoot      = $sb
    CA2023InDB      = $db
    PCA2011InDBX    = $dbx
    UEFICA2023Status = $status
  }
}
Invoke-Command -ComputerName (Get-Content .\hosts.txt) -ScriptBlock $check |
  Export-Csv .\secureboot-state.csv -NoTypeInformation

Sort the output into four buckets: Secure Boot off, 2023 CA missing, 2023 CA present but PCA 2011 not revoked, fully revoked. The third bucket is the one BlackX describes: patched, not mitigated.

2. Hunt: look for the published indicators

# Installer path from the report
Test-Path 'C:\ProgramData\Intel\inst.exe'
Get-ChildItem 'C:\ProgramData\Intel' -Force -ErrorAction SilentlyContinue

# Any googleupdate.exe whose original file name is jcef_helper.exe
Get-ChildItem C:\ -Recurse -Filter googleupdate.exe -ErrorAction SilentlyContinue |
  Where-Object { $_.VersionInfo.OriginalFilename -eq 'jcef_helper.exe' } |
  ForEach-Object { $_.FullName; (Get-FileHash $_.FullName -Algorithm MD5).Hash }

# Drivers signed with the revoked certificate serial from the report
Get-ChildItem C:\Windows\System32\drivers\*.sys |
  Get-AuthenticodeSignature |
  Where-Object { $_.SignerCertificate.SerialNumber -eq '0BCDF5E0DA32D68900B8B7638459D072' } |
  Select-Object Path, Status

Search DNS and proxy logs for archivetj.com, and process creation logs for inst.exe PVMDIJGKAX2. A clean result from inside a possibly infected Windows is weak evidence; image suspect disks and ESPs and inspect them offline.

3. Inspect the ESP

# Mount the EFI System Partition to S: (pick an unused letter)
mountvol S: /S
Get-ChildItem S:\EFI -Recurse -Force |
  Select-Object FullName, Length, LastWriteTime | Sort-Object LastWriteTime -Descending
Get-ChildItem S:\EFI -Recurse -Force -Filter *.efi | Get-FileHash -Algorithm SHA256
mountvol S: /D

On a Windows only device, grubx64.efi or a shim under \EFI\Microsoft\Boot\ is not expected. Compare with a known good device of the same model, and check for a leftover S:\system32\ directory.

4. Prepare before you revoke

KB5025885 is explicit that the revocations cannot be undone while Secure Boot is in use, and that reformatting the disk does not remove them. Before applying them anywhere:

# Back up the BitLocker recovery key (48 digits) and confirm it is escrowed
manage-bde -protectors -get $env:SystemDrive

• Update install and recovery media. KB5025885 says existing media may not boot after revocation, and that after the April 2026 or later updates and the PCA 2011 revocation, SVN 5.0 can invalidate external boot media built before January 2025. Use FAT32 for USB media.
• Update every Windows installation on dual boot machines first.
• Test on one device per hardware class. KB5025885 lists known issues including HP Sure Start, Arm64 Qualcomm devices (with a SkipDeviceCheck workaround), VMware virtual machines with Secure Boot, a third party disk encryption product, and TPM 2.0 systems on Windows Server 2012 and 2012 R2.
• Check with your device maker for firmware updates. KB5016061 events 1802 and 1803 mean the firmware itself is blocking the update or has no suitable KEK.

5. Apply the revocation, in stages

Following KB5025885 as published when we read it:

# Stage A: add Windows UEFI CA 2023 and move to the 2023 signed boot manager
reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Restart when prompted, then confirm events 1036 and 1799 and the DB check above

# Stage B: revoke Windows Production PCA 2011 (irreversible)
reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Restart, then confirm event 1037 and the DBX check above

# Stage C (optional): SVN update
reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x200 /f
Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update"
# Confirm event 1042

KB5025885 says a restart may be needed, particularly when Virtual Secure Mode features such as Credential Guard are on. Do not chain stage B onto stage A on the same run without checking stage A succeeded; event 1797 or 1798 means the DBX step failed because the 2023 prerequisites were not in place.

6. If you find an infection

Microsoft's 2023 guidance is to isolate the device and reformat both the OS and EFI partitions, or restore from a clean backup that includes the EFI partition. Remove unexpected MOK entries, which the 2023 BlackLotus analysis notes needs mokutil and physical presence. Apply the revocation before the device returns to service, and treat the original admin compromise as the primary incident.

What changed since the first reports

• Attribution sources disagree on detail. The BlackX report ties its "xdd" overlap to a June 2026 report on the FishMonger group, which it says the community assumes is related to APT41. That June report itself attributes FishMonger to the Chinese contractor I-SOON, places it under the Winnti Group umbrella, lists aliases including Earth Lusca, TAG-22, Aquatic Panda and Red Dev 10, and does not mention APT41. Its PDB path is C:\Users\xdd\Desktop\今天\2023-4-11\...\DriverMemoryLoadDriver.pdb, embedded in a driver loader binary.
• The June report's UEFI mention was hedged. It cited "limited indications" of a UEFI bootkit component in some attack scenarios, possibly exploiting CVE-2023-24932. The BlackX report assesses BlackX is that component. That link is the second vendor's, not confirmed by the first.
• A news summary mixed up group names. One security news bulletin on 23 October headlined the item as APT41 but said APT42, a different group, in its body. The primary report says APT41.
• Disclosure year. The vendor report dates Baton Drop to 2023; Microsoft's record dates it to January 2022.

Open questions

• How the attackers first obtained administrator rights. The report does not say.
• The kernel driver's file name, SHA-256 hashes and IP infrastructure. None were published.
• Whether BlackX uses CVE-2023-24932 specifically, as the June report suggested, or only CVE-2022-21894 as the October report describes.
• When Microsoft's Enforcement Phase will start.
• How many organisations sit in the patched but not revoked state. No fleet level data has been published.

What would have helped

None of this is a judgement about the targeted agencies. The vendor's own conclusion is that the problem lay in how the patch is delivered. What follows is what any organisation running Windows on Secure Boot hardware can do.

Practices any team can use

• Track mitigation state, not just patch state. "KB installed" and "vulnerability mitigated" are different fields. For CVE-2023-24932 the mitigated state shows in DBX, in UEFICA2023Status and in event 1037. Report on those.
• Read the KB, not just the bulletin. Several high impact Windows fixes need follow up steps; the vendor report cites a 2025 example too. Have someone own turning every "manual steps required" note into a task.
• Plan irreversible changes like migrations. The revocation breaks old media and some hardware, which is why it gets deferred forever. Give it hardware classes, test devices, media refresh, BitLocker key escrow, staged rings and a finish date.
• Restrict administrator rights. Both CVEs need high privileges. Microsoft's BlackLotus guidance recommends least privilege, restricting local admin and avoiding domain wide admin service accounts.
• Use Measured Boot and baseline the ESP. Measured Boot logs and a per model hash list of expected EFI binaries give evidence that does not depend on a possibly compromised OS.
• Audit MOK and remove trust you do not need. Microsoft's 2023 guidance notes that removing the third party UEFI CA, where a device does not need it, blocks BlackLotus style MOK abuse without fixing the underlying flaw. Some hardware needs it for option ROMs, so test first.
• Watch for cloud storage C2. Know which processes on sensitive hosts should talk to consumer cloud storage APIs, and alert on the rest.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in an agentic mode and a deterministic scanner mode, and issues findings as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems. Windows boot managers, UEFI firmware and Secure Boot databases are outside them, and it played no part in finding BlackX or Baton Drop.

Gold Open Source at gold.safeguard.sh is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh is a paid service with hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or higher, Sigstore signed, with evidence pages; an artifact loses its badge if it regresses. Neither ships Windows boot managers or firmware, and there is no Gold build for this issue.

The transferable lesson is the one Gold is built around: a fix only counts once the fixed artifact is what runs. For open source components, that means pulling patched, signed versions from a curated source and rebuilding fast. For firmware trust, it means writing the revocation to every device and checking it landed.

Where Safeguard fits

Safeguard does not detect bootkits, read UEFI variables, inspect the ESP, enforce Secure Boot or manage Windows endpoints. If your question is whether a laptop is infected with BlackX, Safeguard is the wrong tool.

It helps with the same installed but not effective failure in the software you build and ship:

• SBOM and dependency scanning of repositories, container images and SBOM files (safeguard scan --dir ., safeguard scan --image <name>, safeguard scan --sbom <file>, JSON results under ./output), and a platform view of which projects contain a given component and version. That shows whether the fixed version is in the image you deploy, not just whether someone merged the bump.
• Vulnerability matching with reachability analysis, policies and gates evaluated in the platform, and autonomous remediation that opens fix PRs (off by default).
• The Safeguard CLI's assistant, which edits code and runs commands with your approval under /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. You could have it turn the fleet check above into a script and review each edit. For anything as permanent as a DBX revocation, use Ask or Strict. Desktop and phone apps can send work to a computer running the CLI and approve each command.

We do not claim Safeguard would have prevented this campaign or detected the bootkit.

Common mistakes and troubleshooting

• Treating update compliance as mitigation. Report DBX state separately.
• Assuming the 19 October expiry revoked PCA 2011. It did not.
• Running the DBX step before the DB step. Event 1797 means Windows UEFI CA 2023 is not in DB; 1798 means the boot manager is not yet 2023 signed. Go back to stage A.
• Ignoring event 1033. A potentially revoked boot manager is in the ESP and the update is deferred. That is stale media or something worse; investigate.
• Forgetting recovery media and BitLocker keys. Refresh media and confirm key escrow before the first device at a site is revoked. Event 1032 warns of BitLocker recovery in advance.
• Skipping VM templates and dual boot machines. KB5025885 lists VMware virtual machines with Secure Boot as a known issue, and un-updated Windows installations on dual boot devices may fail to start.
• Trusting a clean scan on a suspect host. The BlackX driver redirects file opens to calc.exe. Inspect offline.

FAQ

What is BlackX?

A UEFI bootkit a security vendor found in early 2026 in an espionage campaign against diplomatic agencies in Tajikistan, Uzbekistan and Turkmenistan. It closely resembles BlackLotus. It bypasses Secure Boot through Baton Drop (CVE-2022-21894), enrols attacker controlled Machine Owner Keys, injects a signed kernel driver that interferes with security products, and deploys espionage payloads.

Who is behind it?

The vendor attributes it to APT41 with medium confidence, citing the "xdd" identifier shared with a June 2026 report on the FishMonger group, DLL sideloading with an encrypted companion file, and OLLVM obfuscation. That is one vendor's assessment. The June report attributes FishMonger to the contractor I-SOON and does not mention APT41.

My machines are fully patched. Am I protected?

Not necessarily. The protection depends on revoking Windows Production PCA 2011 in the firmware DBX, which KB5025885 leaves manual until the Enforcement Phase. If the DBX check in this post returns False, the revocation is not in place.

Did PCA 2011 expiring on 19 October fix this?

No. Expiry does not stop firmware loading binaries signed under it; only DBX does. Devices without the 2023 certificates also cannot take future boot level fixes.

Can BlackX infect a machine remotely?

Not on its own. The attackers installed it after compromising the network and obtaining administrator rights, and both CVEs require high privileges. The bootkit adds persistence and stealth.

Is applying the revocation risky?

It is permanent while Secure Boot is in use. Old media stops booting, some devices enter BitLocker recovery, and some hardware and VM platforms have known issues. Testing and staging manage those risks.

How do I know if a machine is infected?

Look for the published indicators, unexpected ESP files and MOK entries, HVCI disabled unexpectedly, and Measured Boot log changes. The driver hides its files, so check suspect machines offline or from trusted media.

Would Safeguard have prevented this?

No, and we do not claim it would. Safeguard does not monitor firmware, endpoints or Secure Boot state. It helps with the same installed but not effective problem in the open source components and images you build.

Fix it without waiting for upstream

BlackX is a case where the fix had to come from the platform vendor and be finished by each device owner, so the steps below do not apply to the boot chain itself. They apply to the open source dependencies and images where the same "fixed upstream, still running the old version" gap is most common.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows BlackX, Secure Boot or a Windows endpoint. Each is a real Safeguard session, and each intro says how the same flow applies to this incident's lesson.

This real CLI session fixes a lodash CVE in a sample repository: the assistant reads the finding and advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this incident, you would open the CLI in your operations repository, ask the assistant to turn the read only DBX and UEFICA2023Status checks from this post into a fleet report script, and review each edit and each command before it runs.

Click through it at your own pace, or open it full screen.

This real desktop app session shows the CLI session in the conversation list, a request for work on your computer, a folder pick, and Approve or Deny on each command and file edit, ending with an upgrade done and tests passing. Applied here, you would pick the folder with your Secure Boot rollout scripts, ask for the staged A, B and C steps to be split into separate scripts with a check between each, and deny any command that writes AvailableUpdates on a machine that has not passed stage A.

Click through it at your own pace, or open it full screen.

This real Android session sends work to a computer running the CLI and approves the command on the phone with Allow once, Allow for turn or Deny. A firmware revocation is permanent, so "Allow once" is the right answer for each registry write on a test device, and "Deny" is the right answer the moment a command targets a machine outside the test ring.

Click through it at your own pace, or open it full screen.

To try it, download Safeguard and follow the CLI docs. Related reading: Detecting Bootkits (T1542.003), the eMudhra CA key compromise explained, certificate authority compromise risks and October 2026 security incidents and what would have helped.

Quick check

Sources

• Security vendor report: How APT41 revived the BlackLotus bootkit to attack diplomatic organizations in Central Asia (22 Oct 2026)
• Microsoft KB5025885: How to manage the Windows Boot Manager revocations for Secure Boot changes associated with CVE-2023-24932
• Microsoft KB5062710: Windows Secure Boot certificate expiration and CA updates
• Microsoft KB5016061: Secure Boot DB and DBX variable update events
• Microsoft Security Response Center: CVE-2022-21894
• Microsoft Security Response Center: CVE-2023-24932
• Microsoft Security blog: Guidance for investigating attacks using CVE-2022-21894, the BlackLotus campaign (11 Apr 2023)
• NVD: CVE-2022-21894
• NVD: CVE-2023-24932
• CISA Known Exploited Vulnerabilities catalog (JSON feed, version 2026.10.23)
• Security vendor analysis: BlackLotus UEFI bootkit, myth confirmed (1 Mar 2023)
• Security vendor report: FishMonger's arsenal upgraded, SprySOCKS for Windows (16 Jun 2026)
• shim project: SBAT (Secure Boot Advanced Targeting) documentation
• Security news bulletin, 23 Oct 2026

Last reviewed: 24 October 2026. This is a developing story; check the linked advisories for the latest status.