CVE-2023-24932 is a security feature bypass vulnerability in Microsoft Windows Boot Manager that enables bypass of UEFI Secure Boot protections by abusing trust in older, still-accepted boot components. The flaw is associated with rollback of the Windows boot chain to vulnerable boot managers or bootloaders that remain trusted by Secure Boot, allowing execution of untrusted code during the early boot process before the operating system fully loads. The issue became widely associated with the BlackLotus UEFI bootkit, which used this weakness together with older bootloader trust relationships to undermine Secure Boot on fully updated Windows systems. Microsoft addressed the underlying vulnerability in May 2023, but full protection also depends on applying Secure Boot revocations so vulnerable boot components and signing trust paths are no longer accepted.
Mallory correlates every CVE against your assets, your vendors, and active adversary campaigns. Know which vulnerabilities matter for you, not just which ones are loud.
What it means. What to do now. Patch path, mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
If you can’t patch tonight, do this now.
Patch, then assume compromise.
1 valid exploit after Mallory filtered fakes, detection scripts, and README-only repos (4 hidden).
This repository is a Windows C++ utility named YellowKey that presents itself as a BitLocker recovery key extractor and CVE-2026-45585 bypass assessment tool. It is not a remote exploit; it is a local/physical-access post-compromise or audit-style tool focused on BitLocker-protected systems. The core capability is sensitive: it enumerates BitLocker volumes via WMI, invokes manage-bde to retrieve protector details and parse numerical recovery passwords, tests whether a drive uses a TPM-only protector set, inspects TPM presence/status through TBS APIs, verifies installed KB patches, and exports audit reports that may contain full recovery keys. Repository structure is organized into config/, docs/, include/, modules/, and src/. The config directory contains CLI syntax, CVE metadata, protector heuristics, report templates, and runtime settings. The docs directory provides installation, remediation, troubleshooting, and CVE background. The include directory defines interfaces for BitLocker, TPM, parsing, reporting, and app control. The src directory contains the main entry point and implementations for BitLocker API access, CLI handling, GUI, key parsing, reporting, and TPM interaction. The modules directory adds operational features such as bypass testing, event logging, patch verification, remediation guidance, silent export, and volume management. Main execution starts in src/main.cpp, which selects GUI or CLI mode based on --cli. CLI commands include scan, extract, bypass-test, tpm-status, export, and remediation. The most important code paths are BitLockerAPI::EnumerateVolumes() using WMI namespace ROOT\\CIMV2\\Security\\MicrosoftVolumeEncryption and query SELECT * FROM Win32_EncryptableVolume; BitLockerAPI::GetRecoveryKey() and GetProtectorTypes() invoking manage-bde -protectors -get; KeyParser routines extracting numerical passwords and protector types; BypassTester logic marking TPM-without-PIN/StartupKey as vulnerable; and VolumeManager::UnlockVolume() invoking manage-bde -unlock with a recovery password. From an exploit-intelligence perspective, the repository’s practical capability is recovery-key disclosure and local BitLocker access assistance rather than a full autonomous exploit chain. It can expose or export recovery keys, determine whether a host is configured in a supposedly vulnerable way, and use a provided recovery key to unlock a volume. The code contains several implementation inconsistencies and simplifications, but the intent and offensive utility are clear enough to classify it as an operational local BitLocker key extraction/audit tool rather than a mere detector.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
Vendor-confirmed product mapping. Mallory continuously reconciles this list against your asset inventory.
28 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.
A referenced possible UEFI Secure Boot-related bootkit component mentioned only as limited, unconfirmed evidence in connection with the SprySOCKS campaign.
A vulnerability in older Windows bootloaders that was exploited by the BlackLotus UEFI bootkit to bypass Secure Boot.
A Windows Secure Boot-related vulnerability that may be exploited by a UEFI bootkit component to maintain persistence even after a full OS reinstall, according to the report.
A Windows Boot Manager vulnerability associated with BlackLotus and potential UEFI bootkit persistence; in this content it is mentioned as a possible exploit path used to achieve persistence that could survive OS reinstalls.
Query your assets running an affected version, and investigate the blast radius.
Every observed campaign linking this CVE to a named adversary.
Malware families riding this exploit, with evidence and IOCs.
YARA, Sigma, Snort, and vendor rules, auto-deployed to your SIEM.
Cross-references every affected SKU, including bundled OEM variants.
Community discussion across Reddit, Mastodon, and other social sources.