- The GitHub Windows zero-day dispute has escalated after Microsoft banned researcher Nightmare-Eclipse’s account without explanation.
- Nightmare-Eclipse has published six GitHub Windows zero-day exploits — three already confirmed under active exploitation in the wild.
- The researcher claims Microsoft refused communication, deleted their reporting account, and never paid promised bug bounties.
- An industry expert says Microsoft’s MSRC quality has declined sharply since layoffs gutted its experienced security staff.
- The GitHub Windows zero-day dispute has escalated after Microsoft banned researcher Nightmare-Eclipse’s account without explanation.
- Nightmare-Eclipse has published six GitHub Windows zero-day exploits — three already confirmed under active exploitation in the wild.
- The researcher claims Microsoft refused communication, deleted their reporting account, and never paid promised bug bounties.
- An industry expert says Microsoft’s MSRC quality has declined sharply since layoffs gutted its experienced security staff.
The GitHub Windows Zero-Day Ban That Set the Security World Talking
The security research community doesn’t need much to ignite a firestorm, but Microsoft handing out a GitHub account ban to a prolific vulnerability researcher — without any public explanation — has done exactly that. The GitHub Windows zero-day saga involving a researcher known as Nightmare-Eclipse (also going by Chaotic Eclipse) has become one of the ugliest public spats between a major software vendor and an independent security researcher in recent memory, and it’s not over yet.
Eclipse’s GitHub account is gone. Moved to GitLab now, apparently by necessity rather than choice. Microsoft also allegedly deleted the separate Microsoft account Eclipse had been using to file vulnerability reports through the Microsoft Security Response Center (MSRC) — the official channel for exactly this kind of disclosure. Whether that deletion was deliberate or procedural is unknown. Microsoft hasn’t said a word publicly about any of it.
Six Exploits, Zero Pennies
To understand why Eclipse is this angry, you need to look at what they’ve actually produced. This isn’t a researcher who found a single edge-case bug and got frustrated waiting for a patch. We’re talking about six distinct GitHub Windows zero-day exploits, each with evocative names and real-world impact.
- BlueHammer — achieves SYSTEM-level access through Microsoft Defender
- RedSun — also escalates to SYSTEM via Defender through a separate attack path
- UnDefend — takes Defender offline entirely, leaving the system exposed
- GreenPlasma — gains SYSTEM access via the CTFMon service
- MiniPlasma — exploits a flaw in the Windows Cloud Filter driver for SYSTEM access
- YellowKey — a BitLocker vulnerability that lets an attacker open encrypted drives with almost no friction
That last one deserves a moment. BitLocker is Microsoft’s flagship disk encryption tool — the thing enterprises and governments rely on to make sure stolen laptops don’t become data breaches. A working GitHub Windows zero-day exploit that trivialises that protection isn’t just embarrassing for Microsoft; it’s a serious enterprise security problem.
BlueHammer, RedSun, and UnDefend have all been confirmed as actively exploited in the wild. Given that Eclipse published full or partial proof-of-concept code for all six, it’d be optimistic to assume the others haven’t been picked up by threat actors by now.
And through all of this, Eclipse says they got, in their own words, “zero pennies.”
What Microsoft’s Bug Bounty Actually Promises
Microsoft’s bug bounty structure, at least on paper, is generous. MSRC pays between $30,000 and $100,000 for qualifying endpoint zero-days, depending on severity, exploitability, and a set of submission conditions. Crack Hyper-V wide open and you’re looking at up to $250,000. These aren’t token amounts — they’re designed to compete with the grey market for exploits and incentivise researchers to report responsibly rather than sell to the highest bidder.
The operative phrase, though, is “qualifying submission.” And that’s where the friction seems to have started with each GitHub Windows zero-day Eclipse attempted to report.
William Dormann, a vulnerability analyst at Tharros, offered a pointed assessment of what’s gone wrong at MSRC. “Microsoft used to be quite excellent to work with,” Dormann said. “But to save money, Microsoft fired the skilled people, leaving flowchart followers. I wouldn’t be surprised if Microsoft closed the case after the reporter refused to submit a video of the exploit, since that’s apparently an MSRC requirement now.”
That’s a damning characterisation — and Dormann isn’t a random commenter. His critique suggests a structural problem: that cost-cutting layoffs have replaced experienced security professionals with process-followers who apply rules rigidly, without the judgment to recognise when a GitHub Windows zero-day submission is clearly legitimate even if it doesn’t tick every box on a checklist.
If that’s accurate, it’s a self-defeating policy. The entire point of a bug bounty programme is to make it easier for researchers to report vulnerabilities than to exploit or sell them. If your intake process is hostile enough to alienate good-faith reporters, you’re not running a bug bounty — you’re running a bureaucratic filter that drives talent toward GitLab and full public disclosure.
Eclipse’s Account of the Dispute — Passionate, Pointed, and Hard to Verify
Eclipse’s own blog posts don’t make for neutral reading. The language is raw and emotional — pointed criticism of Microsoft and MSRC delivered with obvious frustration. Among the more striking claims: that Eclipse was told personally by someone at Microsoft that the company would “ruin my life,” that there’s some kind of dead-man switch in place, and that Microsoft’s “bones” would be shattered. There’s also a specific date flagged — July 14 — hinted at as when further GitHub Windows zero-day releases may drop.
July 14 is, notably, Microsoft’s Patch Tuesday for that month. If Eclipse is planning to release additional vulnerabilities timed to that date, the symbolic trolling is hard to miss.
The rhetoric makes it difficult to assess the underlying facts fairly. Eclipse could be a legitimate researcher who followed responsible disclosure procedures and got stonewalled by a dysfunctional bureaucracy that ultimately deleted their reporting account and banned them from GitHub in retaliation. Or this could be a researcher who refused to follow submission requirements, published GitHub Windows zero-day exploits without adequate notice, and is now framing a compliance issue as a personal vendetta. The truth is probably somewhere between those two readings.
What is clear is that the dispute began in earnest in early April, when Eclipse published the BlueHammer exploit without prior warning — a so-called “full disclosure” approach that bypasses the standard coordinated disclosure process. That’s the kind of move that typically signals a breakdown in communication has already occurred, not an opening gambit. Whether that breakdown was Eclipse’s fault, Microsoft’s, or mutual is the unanswerable question here.
The GitHub Ban Achieves Precisely Nothing
Whatever the merits of the underlying dispute, Microsoft’s decision to ban Eclipse’s GitHub account — and GitHub is, of course, a Microsoft-owned platform — looks vindictive and achieves nothing concrete. The code is already out. It’s been forked, mirrored, and replicated. Removing the account doesn’t make a single GitHub Windows zero-day exploit disappear from the internet.
What the ban does do is hand Eclipse a compelling narrative. It makes Microsoft look like a company using platform ownership as a weapon against critics. That’s a perception problem Microsoft doesn’t need, especially when its security credibility is already under scrutiny following high-profile incidents like the Storm-0558 breach in 2023, where Chinese threat actors accessed US government email accounts via forged Microsoft authentication tokens.
The broader security community’s reaction has been pointed. The consensus isn’t that Eclipse handled this perfectly — it’s that banning a researcher’s GitHub account for publishing a GitHub Windows zero-day is an inappropriate use of platform power, one that conflates content moderation with silencing criticism.
A Broken Disclosure Process — and a Ticking Clock
The GitHub Windows zero-day story is really a proxy for a larger, unresolved problem in enterprise software security: the coordinated disclosure model is straining under modern conditions, and neither vendors nor researchers have figured out how to update it.
The traditional 90-day disclosure window — where researchers notify a vendor privately, wait for a patch, and then publish — made sense when vulnerability research was slower and exploit development required significant skill. Neither of those things is as true as they were five years ago. AI-assisted security research has compressed timelines dramatically. The gap between a GitHub Windows zero-day discovery and a working exploit is shrinking. And researchers who invest weeks of work finding critical bugs are increasingly asking whether unpaid, bureaucratically hostile reporting processes are worth their time.
Microsoft’s MSRC programme, if Dormann’s characterisation is accurate, has degraded precisely when the pressure on it is increasing. Losing experienced staff who could exercise judgment and replacing them with rigid process-followers is a recipe for exactly the kind of breakdown we’re apparently watching unfold with Eclipse.
The irony is thick: three of Eclipse’s six exploits are now being actively used by attackers in the real world. Systems are being compromised right now with tools that Eclipse tried — by their account — to report through legitimate channels. Whether or not Eclipse followed every procedural requirement to the letter, that’s a security failure. And banning a GitHub account doesn’t patch a single GitHub Windows zero-day.
July 14 is approaching. If Eclipse follows through and drops more zero-days on Patch Tuesday, Microsoft will be in the uncomfortable position of scrambling to address vulnerabilities that — by their own researcher’s account — they had a chance to fix quietly months ago. That’s the real cost of getting researcher relations wrong.
