Microsoft versus Full Disclosure: The ongoing Nightmare Eclipse saga

Bug reporting rules

Microsoft continues to experience a very public confrontation with a security researcher who refuses to play by Microsoft’s own bug reporting rules.

Nightmare Eclipse, also known as Chaos Eclipse and Dead Eclipse, has recently posted six different Windows bug reports without going through Microsoft’s official bug reporting system, which is based on a principle known as “responsible disclosure.”

Historically, there have been three main ways that researchers and vendors have worked together (or against each other) to find, report, and fix bugs.

• No disclosure. In the early days of bug hunting and reporting, commercial vendors regularly issued legal threats against researchers who threatened to reveal any weaknesses in their products, hoping to sweep known bugs under the carpet by keeping them secret, and thereby to avoid the effort and expense of coming up with patches or updates. Network Associates, then owners of the McAfee cybersecurity brand, was famously taken to court in 2002 by the State of New York for selling its software with a contractual clause that prohibited even its customers from publishing any review at all of its products without permission from the company itself.
• Full disclosure. Frustrated by what they saw as self-serving and manipulative anti-security behavior by some vendors, and by widely varying rules applied by vendors who were otherwise willing to address known bugs, some researchers proposed a process that was, and remains, admirably simple. Everyone receives the details of new bugs at the same time, openly and objectively published via some public online forum. The downside is that disruptors, cybercriminals, and state-sponsored attackers get to hear about brand-new vulnerabilities at the same time as the vendors who have to patch them. The upside is that defenders and cybersecurity experts aren’t left unknowingly exposed until vendors get around to providing their own writeups of the bugs, perhaps disingenuously filtered through the company’s marketing and legal departments.
• Responsible disclosure. This approach is widely accepted today, and takes a middle ground between the previous two options. Researchers write up detailed bug reports in their own words, but share them privately with the vendor first, agreeing on a date before which they won’t share their findings publicly. On or after that date, public disclosure is permitted so that the researchers can claim credit, promote their own skills, and add any details that the vendor may have chosen to suppress. The theory is that vendors get a fair chance to patch proactively, thus avoiding the possible mayhem of full disclosure, but the sweep-it-under-the-carpet approach of no disclosure is sidestepped because recalcitrant vendors know they will eventually be outed if they fail to act.

A researcher with their own rules

Well, in April 2026, a researcher going by Nightmare Eclipse claimed that they reported a security hole to Microsoft, but the company wouldn’t accept it, apparently insisting that N. Eclipse needed to include a screencast video that provided visual corroboration of their findings.

Microsoft’s intention, presumably, is to ensure that researchers make an effort to verify their claims “in real time” before submitting them, demonstrating that the claimed vulnerability really is a security weakness that needs patching, rather than just an annoying bug or an inexpert misunderstanding.

But N. Eclipse decided that making a video would be needless extra work; that they had already sent details and proof-of-concept (PoC) code to Microsoft that explained and demonstrated the bug; and that Microsoft couldn’t very well complain if they released the same information to the public.

The public, after all, could also refuse to accept it without a supporting video, just as Microsoft had allegedly done.

Ultimately, N. Eclipse went further than that, and dropped (as hacker jargon puts it) not one but three zero-day security holes in April 2026, supposedly including at least the one alluded to above that Microsoft declined to look at without a video to support it.

For maximum PR effect, these zero-days were dropped just after April’s Patch Tuesday updates came out.

If you’re a LinkedIn user and you’re not yet following @SolCyber, do so now to keep up with the delightfully useful Amos The Armadillo’s Almanac series. SolCyber’s lovable mascot Amos provides regular, amusing, and easy-to-digest explanations of cybersecurity jargon, from MiTMs and IDSes to DDoSes and RCEs.

Even if you know all the jargon yourself, Amos will help you explain it to colleagues, friends, and family in an unpretentious, unintimidating way.

None of these security holes were of the notoriously serious RCE sort (remote code execution), where an attacker can reach out over the internet and implant malware remotely, thereby breaking into a system to initiate an attack.

But the published exploits, which included code showing how to abuse them, were deeply embarrassing to Microsoft anyway, not least because they exploited flaws in Microsoft’s own Windows Defender anti-virus toolkit to perform EoP (elevation of privilege).

An EoP typically gives an attacker who has already broken in, but has insufficient privileges to do any real harm, a chance to promote themselves to full control, for example by taking over the all-powerful SYSTEM account on Windows.

Simply put, the very software that Microsoft pitches and sells to protect you from malware and other cybercriminal intrusions turned out to be exploitable by the very attackers it was meant to keep out, and code showing how to carry out those exploits was published on Microsoft’s own GitHub code-sharing service.

At the time, N. Eclipse taunted Microsoft via text strings and comments in their exploit code, such as:

IHATEMICROSOFT
SERIOUSLYMSFT
It gets funnier as time passes...
let's see how long you can play this game,
I'm willing to go as far as you want.

The intensity of N. Eclipse’s disfavor continued in May 2026, with three more zero-days dropped as full disclosures, rather than reported privately to Microsoft in advance.

One of them, dubbed YellowKey, caused an understandable stir in the media and among corporate IT and cybersecurity teams, and is well worth understanding in detail.

This bug affects the security and privacy that Microsoft’s widely-used BitLocker FDE (full-disk encryption) is supposed to provide.

Simply put, YellowKey means that BitLocker in its most popular setup, known as TPM mode, can trivially be bypassed.

TPM is short for trusted platform module, a dedicated security chip required by Windows 11 to automate various security and cryptographic features in the operating system, including basic BitLocker security.

Loosely speaking, many companies rely on, and many regulators accept, BitLocker in TPM mode to protect the data on their laptops so that, if one of those laptops is stolen, the data is assumed to be inaccessible by the thieves.

That assumption means the missing laptop does not constitute a data breach, and doesn’t need reporting or handling as if it were, which saves time, money, and bad publicity.

But, as our recent explainer article shows in numerous video clips, YellowKey allows anyone to bypass TPM-mode BitLocker automatically, in a few seconds, and to read off all the files from the supposedly protected C: drive.

As a result, security officers around the world are quite reasonably pondering the question, “Does this trivial-to-use, public exploit mean that ‘protected’ laptops lost by or stolen from my staff in recent months now constitute reportable data breaches?”

Stunningly simple

Amazingly, the exploit involves simply copying a curious collection of data files provided by N. Eclipse, none of which are executable files (programs), scripts, or likely to arouse any particular malware-like suspicion, onto a removable drive such as a USB key, plugging it into a laptop, and booting into recovery mode.

That’s all there is to it.

These weird data files somehow trigger an “undocumented feature” in the Windows Recovery Environment (which, by default, anyone with access to your laptop can activate) that completely sidesteps the 48-digit recovery password that an attacker almost certainly won’t know, and on which the security of TPM-based recovery mode usually relies.

Microsoft has now published a PowerShell script that sysadmins can use to mitigate the risk of YellowKey on affected devices.

The script removes the abovementioned undocumented feature from the Windows Recovery Environment on your laptop, refreshes the laptop to accept the updated recovery mode image file, and prevents the attack from working in future.

A war of words

As N. Eclipse wrote at the time:

Now regarding YellowKey, lots of you are wondering how does one even find such backdoor?

I’ll tell you how, it took me more time trying to get it to work than the amount of sleep I had in two years combined. No AI involved, no help in any shape or form. I could have made some insane cash selling this but no amount of money will stand between me and my determination against Microsoft․․․

I can’t wait when I will be allowed to disclose the full story, I think people will find my crashout very reasonable and it definitely won’t be a good look for Microsoft.

As vigorous as that opening salvo may have been, both the rhetoric and the tub-thumping have ramped up significantly in the past few days.

Microsoft banned N. Eclipse from its GitHub service and blocked access to their exploit code.

N. Eclipse then moved over to rival code hosting company GitLab, which has sometimes taken a satirically anti-Microsoft approach in its marketing in the past, only to find GitLab a less-than-enthusiastic replacement provider that quickly banned them too.

Angered at this – understandably, perhaps, given that other researchers’ malware code and attack tools have for years been openly available on GitHub, pitched as being for “red team use” or “for research purposes only” – N. Eclipse retaliated with a weirdly-worded and explicit threat of more zero-days to come:

Now you take the courtesy to flag my github account and wipe it out of the public, just like that ? You are proving to everyone that you actively escalating this conflict but I’m done begging you.

I might sound like crazy idiot who is whinning [sic, presumably “whining”] around but I have proof for every single word I said, I just can’t release it yet. Why ? Microsoft still has chains in my hands, it’s been like this for years and I just can’t stay silent anymore. I hope I can release the documents soon.

Mark this date July 14th, I will make sure your bones are shattered that day. Nothing will be released this June (or maybe I will release [something], depending on circumstances).

Microsoft, in a nod to the early years of this century, responded aggressively, playing the legal card, and insisting that full disclosure should be considered eternally unacceptable:

In response to the unnecessary risk created by these disclosures, our security teams have been working around the clock to understand the impact, protect our customers, and develop security updates․․․

Uncoordinated disclosures that put proof-of-concept code for unpatched vulnerabilities into the hands of bad actors are never justifiable and have real-world consequences. Our security teams across the company work tirelessly tracking threat actors who look for weaknesses just like these to attack Microsoft and our customers. Our Digital Crimes Unit will continue bringing cases against these actors and those that enable their criminal activity – coordinating as needed with law enforcement around the world.

The tone, the comments about “unnecessary risk,” the mention of the work needed to patch dangerous vulnerabilities, and the legal finger-wagging here, are perhaps surprising.

After all, security holes need mitigating and patching quickly regardless of how they’re disclosed, and Microsoft itself happily continues to host many GitHub projects that threat actors can use to mount attacks, thereby “enabling criminal activity,” albeit that other researchers tend to avoid the sort of public venom shown by N. Eclipse.

Examples of security-sensitive GitHub projects that haven’t been shut down include: source code for creating brand new malware samples; file-by-file encryption code that mirrors the techniques used in ransomware attacks; memory-scraping and password hash-stealing tools; and software that automates the creation of pixel-perfect clones of other people’s websites to phish for their users’ login names, passwords, and one-time security codes.

At the time of writing [2026-05-30T14:00:00Z], the latest words so far in this increasingly ugly battle are from N. Eclipse, in a blog post captioned by the tasteless pun “announcing bitskrieg“:

After the recent events, multiple researchers reached out to me and some just literally gave me free vulnerabilities․․․

One of them was JonasLyk, he did most work, I just did the emotional support part․․․ We believe this be used to compromise confidential virtual machines but we’re not really sure if that’s possible since we don’t have access to such technologies.

One thing we’re sure of, is it fully bypasses bitlocker.

The bug will be released sometime in June ;)

What to do?

This is a polarizing issue.

Some researchers are siding with N. Eclipse, arguing that although responsible disclosure is widely accepted and commonly used, there will always be a place for full disclosure, which at least puts users and vendors on an equal footing, epsecially if vendors prove difficult to deal with or drag their feet in replying to reports.

If it’s OK for vendors to publish open-source software such as programs to generate phishing sites automatically, tools that are arguably more useful to cybercriminals than to users and IT departments, then why should those same vendors get to control how security research relevant to their software gets reported and published?

Other researchers and security professionals will no doubt have sympathy for Microsoft, even if they’re uneasy about the tone of Microsoft’s latest comments.

N. Eclipse seems to be deliberately dragging innocent Windows users into harm’s way as pawns in a personal vendetta against a company they don’t like.

As for the worrying issue of whether the YellowKey exploit changes the rules about breach disclosures․․․ watch this space, because we’ll soon be publishing a plain-english explainer on how Microsoft’s mitigation works, and how you can test that it’s worked.

With more to come in the N. Eclipse versus Microsoft story, why not talk to SolCyber about signing up for a human-led, human-centric cybersecurity service that will free you up to concentrate on your core business instead of keeping up with the latest cybersecurity sagas?

Why not ask how SolCyber can help you do cybersecurity in the most human-friendly way? Don’t get stuck behind an ever-expanding convoy of security tools that leave you at the whim of policies and procedures that are dictated by the tools, even though they don’t suit your IT team, your colleagues, or your customers!

More About Duck

Paul Ducklin is a respected expert with more than 30 years of experience as a programmer, reverser, researcher and educator in the cybersecurity industry. Duck, as he is known, is also a globally respected writer, presenter and podcaster with an unmatched knack for explaining even the most complex technical issues in plain English. Read, learn, enjoy!