If your organization runs Windows 11 or Windows Server and relies on BitLocker for data-at-rest protection, there are two BitLocker stories this week that deserves your attention; this one comes with a CVE, a patch history, and a public proof-of-concept that works against machines Microsoft considers fully up to date.
It's called BitUnlocker. The underlying vulnerability, CVE-2025-48804, was patched in July 2025's Patch Tuesday. The patch shipped. Most organizations applied it. And yet a working exploit released this month can still defeat BitLocker on those patched machines in under five minutes, because the patch fixed the vulnerable binary without revoking the certificate that makes it trustworthy; leaving a downgrade path wide open.
And if you read or have read our article on YellowKey and thought 'we patched our systems for this in July, we're fine', you might want to rethink that thought for both of the BitLocker vulnerabilities.
This article explains what BitUnlocker is, why a patched system is still vulnerable, what the realistic risk looks like for your organization, and what you can do about it right now.
Where this came from
Unlike YellowKey, BitUnlocker traces back to legitimate, coordinated security research. The underlying vulnerabilities were discovered by Microsoft's own Security Testing & Offensive Research team (aka the STORM team) and were first presented publicly at Black Hat USA 2025 and DEF CON 33.
The research set out to ask a pointed question: the Windows Recovery Environment (WinRE) was redesigned to support BitLocker recovery operations, and those redesigns introduced new attack surfaces. Did those surfaces create exploitable paths to bypass BitLocker entirely? The answer, after extensive research, was yes...in several different ways. Microsoft patched the discovered vulnerabilities, assigned them four CVEs (CVE-2025-48800, CVE-2025-48003, CVE-2025-48804, and CVE-2025-48818), and published the full technical research on the Microsoft Security Blog in August 2025.
The public proof-of-concept now circulating, published to GitHub on April 30, 2026, was built by an independent researcher building on that STORM research. It chains CVE-2025-48804 with a boot manager downgrade attack to produce a practical exploit that requires no specialized hardware and runs in under five minutes.
This is a different situation from YellowKey in an important way: this vulnerability is patched, known, and has a defined remediation path. The problem is that the remediation requires more than simply installing the July 2025 update, and most organizations have not even completed the patching.
What is BitUnlocker?
BitUnlocker is a boot manager downgrade attack that exploits the gap between patching a vulnerable binary and revoking the certificate that authorizes it.
To understand why this matters, a brief explanation of how Secure Boot works is necessary. Secure Boot validates that the software loading at boot time is cryptographically signed by a trusted certificate authority. It validates the signature, not the version number. When Microsoft released the July 2025 patch for CVE-2025-48804, they shipped a new, fixed version of bootmgfw.efi (the Windows boot manager) signed under the newer Windows UEFI CA 2023 certificate. But the legacy Microsoft Windows PCA 2011 certificate, which was used to sign all boot managers before that fix, remains trusted in the Secure Boot databases of virtually every machine currently in use.
This means the old, vulnerable boot manager is still considered cryptographically valid by Secure Boot. An attacker who serves that old binary to a target machine, whether via a USB drive or, more practically, via a PXE network boot, can load it successfully and the machine's Secure Boot will not object.
The exploit the STORM team originally demonstrated, and that the public PoC operationalizes, works like this: the attacker prepares a modified Boot Configuration Data (BCD) file pointing to a tampered System Deployment Image (SDI), then serves the old, pre-patch boot manager to the target. The target's Secure Boot accepts the old binary because PCA 2011 is still trusted. The TPM releases the BitLocker Volume Master Key because the boot measurements it checks, PCR 7 and PCR 11, appear valid under the trusted certificate. The result is a command prompt with the OS volume fully decrypted and mounted, accessible to the attacker without the recovery key and without the user's password.
The full attack, on a default-configured enterprise Windows 11 machine, completes in under five minutes.
Why is a patched machine still vulnerable?
This is the question that makes BitUnlocker different from a standard unpatched vulnerability, and it deserves a clear answer.
The July 2025 patch fixed the flaw in the boot manager binary itself. It did not revoke the old signing certificate. Microsoft's Secure Boot relies on certificate trust, not version checks. As long as the legacy PCA 2011 certificate remains in the machine's Secure Boot trusted database, a pre-patch binary signed with that certificate is considered legitimate, regardless of the fact that a patched replacement now exists.
Revoking PCA 2011 at scale is a significant undertaking. The certificate was used to sign a large number of legitimate binaries across the Windows ecosystem, and mass revocation carries real operational risk including boot failures on systems that haven't been properly prepared. Microsoft has provided a migration path, described in KB5025885, that moves the boot manager signature to the newer CA 2023 certificate and removes trust in PCA 2011 for boot purposes. But this migration must be performed deliberately, involves multiple steps, and has not been applied automatically by Windows Update.
Systems freshly installed after early 2026 may ship with CA 2023-signed boot managers by default. Everything else, meaning the vast majority of enterprise endpoints currently in service, is almost certainly still in the vulnerable state unless someone has specifically completed the KB5025885 migration.
How is this different from YellowKey?
BitUnlocker and YellowKey are absolutely different vulnerabilities, and the distinction matters for your response planning.
YellowKey is an unpatched zero-day with no CVE and no vendor fix. Its mechanism runs through WinRE and does not depend on the boot manager or Secure Boot certificate state. It works on essentially any Windows 11, Server 2022, or Server 2025 machine regardless of patch level, and the only available mitigations are workarounds rather than fixes.
BitUnlocker is a patched vulnerability with a known remediation path. It works because organizations have not yet completed the full remediation, specifically the CA 2023 migration, even after applying the July 2025 security update. It requires PXE boot capability or USB access, its attack chain is somewhat more complex to set up than YellowKey's, and it can be definitively closed by completing the KB5025885 migration.
The practical overlap is significant, however, as both vulnerabilities require physical access, both defeat BitLocker on TPM-only configurations, both leave TPM+PIN as the most universally effective near-term control, and both result in full access to the encrypted drive contents. Organizations responding to one should be assessing their exposure to the other at the same time.
Who is affected?
Any Windows 11 or Windows Server machine with all of the following characteristics is vulnerable to BitUnlocker:
- BitLocker is enabled in TPM-only mode (no PIN required at boot)
- The Secure Boot database still trusts the Microsoft Windows PCA 2011 certificate
- The KB5025885 migration to CA 2023 has not been completed
This describes the default state of most enterprise endpoints that applied the July 2025 patch but did not take the additional migration steps. Organizations that installed Windows 11 fresh after early 2026 may be protected if the installation defaulted to a CA 2023-signed boot manager, but this should be verified rather than assumed.
Machines configured with TPM+PIN are protected against the publicly available exploit. TPM+PIN prevents the TPM from releasing the Volume Master Key without user interaction at boot, which defeats the downgrade attack regardless of certificate state.
As with YellowKey, the risk is highest wherever devices leave organizational control: traveling executives, field workers, devices used in client environments, decommissioned equipment awaiting disposal, and devices stored in unsecured IT areas.
What should you do?
1. Determine your exposure
Before taking action, establish which machines in your environment are in the vulnerable state. You need to check two things for each device:
What certificate signs the active boot manager? Mount the EFI partition and inspect the binary:
mountvol S: /s
sigcheck -i S:\EFI\Microsoft\Boot\bootmgfw.efi
If the output shows PCA 2011 rather than CA 2023, that machine is in the vulnerable state for the BitUnlocker downgrade attack. Note that C:\Windows\Boot\EFI\bootmgfw.efi may differ from what is actually used at boot so always check the EFI partition copy.
What BitLocker protectors are active? From an elevated command prompt:
manage-bde -status C:
A machine showing "TPM" as the sole key protector, combined with a PCA 2011-signed boot manager, is fully vulnerable to the public exploit.
2. Enable BitLocker TPM+PIN immediately
TPM+PIN is the single most effective near-term control for both BitUnlocker and YellowKey. It prevents the TPM from releasing the Volume Master Key during any manipulated boot sequence, regardless of which vulnerability is being exploited.
On Windows 11 Pro and Enterprise, configure via Group Policy at:
Computer Configuration → Administrative Templates → Windows Components →
BitLocker Drive Encryption → Operating System Drives
Enable "Require additional authentication at startup" and set "Configure TPM startup PIN" to "Require startup PIN with TPM." Windows 11 Home does not expose this Group Policy path.
Be prepared for the user experience impact: every device will prompt for a PIN at each boot going forward. For high-value or high-mobility devices, this is worth it immediately. For the broader enterprise, plan the rollout to avoid disruption.
3. Complete the KB5025885 migration
The definitive fix for BitUnlocker is completing Microsoft's boot manager revocation migration, which removes trust in PCA 2011 for boot purposes and establishes CA 2023 as the trusted signing authority. This is the only step that closes the downgrade attack path permanently.
The migration procedure is documented in KB5025885. It involves several steps beyond simply installing the July 2025 update, including preparing recovery media and enabling revocation controls. Read the documentation carefully before proceeding as the procedure has known edge cases and a misconfigured system may fail to boot.
After completing the migration, verify the result by re-inspecting the EFI boot manager's signing certificate as described above.
4. Ensure the July 2025 patch is applied
While the patch alone does not close the downgrade path, it remains a necessary prerequisite for the full migration. Confirm that the July 2025 cumulative update has been applied to all in-scope systems before beginning the KB5025885 migration.
5. Consider removing WinRE on high-security workloads
For devices where pre-boot authentication cannot be enforced, such as unattended servers or kiosk machines, removing the WinRE recovery partition eliminates a significant class of BitLocker attack surface. This is a drastic measure with real operational consequences (recovery from boot failures becomes significantly harder), but it is worth evaluating for the highest-sensitivity systems in your environment.
6. Reassess breach notification posture for lost or stolen devices
As with YellowKey, any lost or stolen Windows 11 or Server device running TPM-only BitLocker whose KB5025885 migration has not been completed should be treated as a potential data exposure for breach notification and incident response purposes. Work with your legal and compliance teams to understand your obligations.
A note on the broader picture
BitUnlocker and YellowKey landing in the same week is purely coincidental; they were developed independently, by different researchers, targeting different mechanisms. But the coincidence highlights something worth naming: BitLocker's security model, under default enterprise configuration, depends on assumptions that are not holding up well under current scrutiny.
TPM-only BitLocker was always a qualified protection; it protects against unsophisticated theft but has known limitations against attackers with physical access and meaningful technical capability. What this week has demonstrated is that those limitations are now being operationalized and published as working tools, not theoretical research.
Organizations that treat BitLocker as a compliance checkbox rather than an actively managed security control are in a harder position today than they were a month ago. The right response is to use these disclosures as the forcing function to complete work that should have been done when KB5025885 was released last year.
The Microsoft STORM research that underlies BitUnlocker is available on the Microsoft Security Blog and is worth reading for any technically oriented staff. The public proof-of-concept is at github.com/garatc/BitUnlocker.
Summary
| CVE | CVE-2025-48804 (primary); related: CVE-2025-48800, CVE-2025-48803, CVE-2025-48818 |
| Nickname | BitUnlocker |
| Type | BitLocker Security Feature Bypass via boot manager downgrade |
| Affected | Windows 11, Windows Server — any device with TPM-only BitLocker and PCA 2011 still trusted in Secure Boot |
| Patch applied? | July 2025 — but patch alone is insufficient without the KB5025885 CA 2023 migration |
| Exploit complexity | Moderate — requires physical access, USB or PXE boot, and a few minutes |
| TPM+PIN protected? | Yes — TPM+PIN prevents the VMK from being released during the downgrade attack |
| Definitive fix | Complete the KB5025885 boot manager migration to CA 2023 |
| Immediate mitigation | Enable BitLocker TPM+PIN; verify boot manager certificate |
| Breach notification impact? | Yes — lost or stolen TPM-only devices without completed CA 2023 migration should be assessed |
If you need help auditing your fleet's BitLocker configuration, prioritizing the KB5025885 migration across your endpoints, or assessing your breach notification exposure for devices that may have been lost or stolen before either this week's disclosures or last July's patch, get in touch. Two BitLocker stories in one week is a sign that your endpoint encryption posture deserves a close look — and that's exactly the kind of review CrowdSOC can help with.