Full Report
Recently, somebody going by the name of Nightmare Eclipse has been having an online beef with Microsoft around security vulnerabilities they claim they had been trying to report. Their posts read like those of a former Microsoft employee. They’ve been dumping proof of concept exploits for said vulnerabilities publicly.As a defender myself, it’s not great — but it is what it is; Microsoft should make better products. In an age where every vendor is selling magic beans AI boxes that can “discover every vulnerability”, it is unsurprisingly real humans who are finding impactful vulnerabilities still.The vulnerabilities range from interesting to nothing. For example, one interesting one — still unpatched — is a complete and working BitLocker bypass in default deployments, allowing you bypass encryption on a device.Do I support what Nightmare Eclipse is doing with this one? Not really, it feels weird at times, almost like they think they’re entitled to payment — their blog is also awfully specific about certain Microsoft colleagues. There’s presumably more going on behind the scenes than is known.This Microsoft blog about the situation caught my attention, though:A shared responsibility: Protecting customers through Coordinated Vulnerability DisclosureIn particular, this bit (my highlights):Hang on.. proof of concept exploit creation and distribution for zero days is “criminal activity” now? Who in CELA signed off that wording? Microsoft are the biggest distributor of zero days, via Github. Not following made up “responsible disclosure” processes is not illegal.Nightmare Eclipse was also kicked off GitHub (owned by Microsoft), Gitlab (a Microsoft partner), they were doxxed on Twitter and had their MSRC — Microsoft vulnerability reporting portal — account disabled. It’s quite difficult to ‘responsibly’ report future vulnerabilities when you have been banned.GitHub has long been a source for zero days exploits in competitor products — it still is. While I worked there GitHub had a policy saying they wouldn’t remove them. By continually removing just exploits for their own products from Github and declaring “criminal activity”, it’s a rubicon you shouldn’t cross.Microsoft is attempting to misuse its ownership of Github to protect only its own products, and misuse its extensive links to law enforcement by branding publishing information about vulnerabilities in its own products as criminal behaviour, as best I can read that blog.Maybe there’s more to it that isn’t mentioned in the blog — but in which case, either mention it or shut up and let law enforcement take over.Responsible disclosure quite often is framed to protect the product owner, not the customer — using it to try to criminally prosecute people is a new low.Some historyBefore I joined Microsoft, back in 2019, somebody called SandboxEscaper published a few proof of concepts online for Microsoft products, as zero days.Microsoft hired her. SandboxEscaper did good work.Now, to be clear, SandboxEscaper claims they aren’t Nightmare Eclipse. I’m not linking the two, either — I’m making the point Microsoft has very publicly hired somebody for doing the same thing Microsoft’s latest blog alleges is criminal behaviour.There’s a lot of history.For example, Microsoft knowingly employed somebody who would repeatedly talk about selling exploits to Russia and Iran, publicly, while working there — for years.They have a long history of hiring people, some with criminal convictions for hacking offenses — and hiring people who’ve posted zero days publicly.Microsoft have also purchased zero day exploits in their own products from exploit brokers.If Microsoft’s tactic is to try to criminalise not following often arbitrary “responsible disclosure” frameworks, good luck defending that in court — because there’s a whole clown car of prior decision making within Microsoft and facts which would emerge in that process.It would also profoundly change the security industry for the worst, pivoting protecting the interests of business over the interest of collective cyber defence. Microsoft should be concentrating on making better, more secure products that one person can’t run rings around.Microsoft’s stance on zero day exploits is a dumpster fire of their own making was originally published in DoublePulsar on Medium, where people are continuing the conversation by highlighting and responding to this story.
Analysis Summary
# Vulnerability: BitLocker Encryption Bypass in Default Deployments
## CVE Details
- **CVE ID:** Not Assigned (Zero-day)
- **CVSS Score:** N/A (Estimated High)
- **CWE:** CWE-311: Missing Encryption of Sensitive Data / CWE-287: Improper Authentication
## Affected Systems
- **Products:** Microsoft Windows
- **Versions:** Multiple versions (indicated as current at the time of the article, May 2026)
- **Configurations:** Default deployments of Windows with BitLocker drive encryption enabled.
## Vulnerability Description
The vulnerability is described as a complete and working bypass for BitLocker encryption. While specific technical details of the underlying flaw (such as WinRE manipulation or TPM sniffing) are not explicitly detailed in the text, it allows an unauthorized party to bypass the full-disk encryption protecting the device's data without the recovery key or user credentials.
## Exploitation
- **Status:** PoC available; publicly disclosed by researcher "Nightmare Eclipse."
- **Complexity:** Low (Described as "complete and working" in default setups).
- **Attack Vector:** Physical (Requires access to the target device).
## Impact
- **Confidentiality:** Total (Encryption is bypassed, allowing access to all stored data).
- **Integrity:** High (If the drive is unencrypted, the operating system files can be modified).
- **Availability:** Low (Primary impact is data exposure).
## Remediation
### Patches
- **Status:** Unpatched. The article notes the vulnerability remains a zero-day as Microsoft has not yet released a formal security update to address this specific bypass.
### Workarounds
- **Configure Enhanced PINs:** Use BitLocker with a TPM+PIN protector rather than TPM-only (the likely "default deployment" mentioned).
- **Disable Windows RE:** If the bypass utilizes the Windows Recovery Environment, disabling it may mitigate certain bypass vectors.
- **Pre-Boot Authentication:** Transition from default transparent operation to a configuration requiring user interaction before the encryption keys are released.
## Detection
- **Indicators of Compromise:** Physical tampering with the device; unauthorized reboots into recovery environments; presence of external hardware used for TPM sniffing.
- **Detection methods:** Monitor for changes in BitLocker status or the disabling of security features via Unified Extensible Firmware Interface (UEFI) logs or Windows Event Logs (Event ID 4663 for object access if the system is live).
## References
- **Vendor Advisory:** hxxps[://]www[.]microsoft[.]com/en-us/msrc/blog/2026/05/a-shared-responsibility-protecting-customers-through-coordinated-vulnerability-disclosure
- **Researcher Original Thread:** hxxps[://]cyberplace[.]social/@GossiTheDog/116565662607962457
- **Article Source:** hxxps[://]doublepulsar[.]com/microsofts-stance-on-zero-day-exploits-is-a-dumpster-fire-of-their-own-making-0946117940a4