MAY 29, 2026ANALYSIS5 MIN READ

Six Windows Zero-Days, Two Platform Bans: A Defender Triage Guide

A researcher has dropped six Windows zero-days since early April and just got banned from GitHub and GitLab. The ethics debate is loud. But for defenders, the immediate question is narrower: are you ready for the next drop?

What Happened

Since early April 2026, a researcher operating under the handle Nightmare Eclipse (also known as Chaotic Eclipse) has released six zero-day exploits targeting core Windows components — Defender, BitLocker, and kernel drivers. The researcher claims Microsoft ignored their vulnerability reports, deleted their bug-reporting account, and refused bounty payments. According to multiple reports, they began publishing working proof-of-concept exploits publicly in retaliation.

On May 23, GitHub terminated the researcher's account. GitLab followed three days later. The repositories became unavailable from the original accounts.

THE SIX EXPLOITS

BlueHammer — CVE-2026-33825 · Windows Defender privilege escalation → SYSTEM. Patched April 14.
RedSun — CVE-2026-41091 · Defender alternate exploitation path → SYSTEM. Patched May 21 (OOB).
UnDefend — CVE-2026-45498 · Can impair Defender protections and updates. Patched May 21 (OOB).
YellowKey — CVE-2026-45585 · CVSS 6.8 · BitLocker TPM-only bypass (physical access). Unpatched.
GreenPlasma — Text Input Services privilege escalation. Unpatched.
MiniPlasma — Cloud Files Mini Filter Driver → SYSTEM on fully patched Win 11. Unpatched.

Three have patches. Three don't. June 9 is the next Patch Tuesday window and the most likely delivery date for remaining fixes. The researcher has reportedly threatened to release additional exploits on July 14 and claims to have a dead man's switch that would auto-publish more if their accounts are further restricted. These claims have not been independently verified.

Why the Platform Bans Don't Help You

The debate over whether GitHub was right to ban Eclipse is interesting but ultimately irrelevant to your security posture. The exploits were public for weeks before the ban. They've been mirrored, forked, and archived. The PoC code is in the wild. Removing the repos doesn't unring the bell.

The ban may have also reduced visibility into future disclosures. The researcher has reportedly escalated threats and is now operating outside the guardrails of mainstream platforms where at least some moderation and takedown mechanisms exist. Public PoCs compress defender timelines regardless of where they're hosted.

The Defender Triage Checklist

Rather than following the drama, focus on what you can control. Here's a practical checklist for the three unpatched vulnerabilities:

1. Verify Your Patch Level

Confirm that the April 14 cumulative update and the May 21 out-of-band patches are deployed across your fleet. BlueHammer, RedSun, and UnDefend should already be closed. Verify Defender Antimalware Platform version 4.18.26040.7 or later, and Malware Protection Engine 1.1.26040.8 or later, against Microsoft's published update history.

2. Mitigate YellowKey (BitLocker Bypass)

YellowKey bypasses TPM-only BitLocker configurations and requires physical access. If your fleet uses BitLocker without a startup PIN, you're exposed. Immediate mitigations:

→ Deploy a BitLocker startup PIN via Group Policy — TPM+PIN is reported to mitigate the known YellowKey technique
→ Verify Secure Boot is enabled, restrict external boot devices, and set BIOS/UEFI passwords
→ Ensure recovery key escrow is working — test boot recovery impact before rolling PIN changes fleet-wide
→ Prioritize travel laptops, shared devices, and any hardware that regularly leaves controlled facilities

3. Harden Against Privilege Escalation

GreenPlasma and MiniPlasma are local privilege escalation chains — they turn any low-privileged foothold into SYSTEM. Assume any code execution on affected hosts may escalate until patched. Mitigations to reduce exposure:

→ Confirm Defender engine and platform health via MDE, Intune, ConfigMgr, or PowerShell
→ Hunt for unexpected interactive shells, unusual parent/child chains, or privilege transitions to SYSTEM from ctfmon.exe or cldflt.sys-related processes
→ Consider WDAC, AppLocker, or ASR rules to restrict code execution — start in audit mode and target high-risk hosts first
→ Layer telemetry and detection — don't rely solely on Defender for both prevention and visibility
→ Prioritize shared workstations, dev boxes, VDI, kiosks, and machines with many local users

4. Reduce Initial Access Surface

These are all local/physical exploits — they require an attacker to already have a foothold or physical access. The question is how they get that foothold. Reduce the initial access surface: audit internet-facing services, close unnecessary ports, and verify there are no unpatched entry points that would give an attacker the code execution these exploits need to escalate.

The Bigger Picture

This incident highlights a growing tension in vulnerability disclosure. When the coordinated disclosure process breaks down — whether due to vendor negligence, researcher frustration, or both — the fallout lands on defenders. You can't control the disclosure timeline. You can't predict when the next drop happens. What you can control is your readiness.

The June 9 Patch Tuesday is the next likely window for remaining fixes. Until then, the mitigations above buy time. After that, the reported July 14 threat date will test whether organizations have shortened their patch-to-deploy cycles. Keep your asset inventory current, your patching pipeline fast, and your detection stack layered. Public PoCs don't disappear — preparation is the only variable you control.

KEY DATES

APR 2, 2026 — First disclosure (BlueHammer)
APR 14 — BlueHammer patched (Patch Tuesday)
MAY 21 — RedSun + UnDefend patched (out-of-band)
MAY 23 — GitHub account terminated
MAY 26 — GitLab account suspended
JUN 9 — Next Patch Tuesday window (likely fix date)
JUL 14 — Threatened next release date

References

By Vladimir Slavin · Founder, RECON · [email protected]