For most organizations, Patch Tuesday represents a familiar cybersecurity routine.
Microsoft releases security updates. IT teams test them. Patches are deployed. Vulnerabilities are closed. Dashboards turn green.
But since April 2026, something unusual has been happening.
A security researcher operating under the names Nightmare Eclipse and Chaotic Eclipse has repeatedly disclosed previously unknown Windows vulnerabilities and published proof-of-concept exploits—often immediately after Microsoft's monthly Patch Tuesday updates.
The timing matters.
Organizations can install every available Microsoft security update and still find themselves facing a newly disclosed vulnerability for which no patch was available when their systems were updated.
And the pattern has now repeated for five consecutive months.
With the August release of ShieldBreak, Nightmare Eclipse has published ten Windows exploits or vulnerability disclosures since April.
The individual vulnerabilities are important.
But the larger cybersecurity lesson may be even more important.
Patching closes known vulnerabilities. It cannot prevent an attacker from exploiting a vulnerability that defenders do not yet know exists.
The Nightmare Eclipse campaign began in April and has continued through Microsoft's August Patch Tuesday cycle.
| Month | Exploit | Primary Area Targeted | Why It Matters |
|---|---|---|---|
| April | BlueHammer | Windows / Defender-related privilege escalation | Early release in the campaign; later associated with observed real-world intrusion activity |
| April | RedSun | Microsoft Defender | Demonstrated another path from local access toward elevated privileges |
| April | UnDefend | Windows security controls | Targeted the defensive mechanisms organizations depend upon |
| May | YellowKey | Windows security / recovery mechanisms | Continued the post-Patch Tuesday disclosure pattern |
| May | GreenPlasma | Windows security mechanisms | Expanded the campaign to additional Windows attack surfaces |
| May | MiniPlasma | Windows privilege escalation | Demonstrated privilege escalation against fully patched systems |
| June | RoguePlanet | Microsoft Defender | Exploited Defender behavior to obtain SYSTEM-level execution |
| June | GreatXML | Defender Offline Scan / BitLocker | Demonstrated a path to bypass BitLocker protections under specific conditions |
| July | LegacyHive | Windows User Profile Service | Allowed access to other users' registry hives, including administrative profiles |
| August | ShieldBreak | Microsoft Defender | Reported to bypass Microsoft's remediation for RoguePlanet and regain SYSTEM privileges |
That makes ShieldBreak number ten in the sequence.
But simply counting vulnerabilities misses what makes this campaign unusual.
It is the cadence.
Microsoft's Patch Tuesday model gives enterprises a predictable security-maintenance cycle.
That predictability is valuable.
But predictable defensive cycles can also create predictable windows of opportunity.
Nightmare Eclipse has repeatedly released vulnerability information around—or immediately following—Microsoft's monthly security updates.
Consider what that means operationally.
An organization could:
and then face public exploit information for another vulnerability shortly afterward.
The organization's security tools may accurately report:
Fully patched.
But fully patched does not necessarily mean:
Protected against every currently exploitable technique.
That distinction matters.
Several of the Nightmare Eclipse disclosures are especially notable because they involve Microsoft Defender itself or mechanisms associated with Windows security.
That creates an uncomfortable cybersecurity paradox.
The technology responsible for protecting the operating system can itself become part of the attack path.
RoguePlanet is a good example.
Released following Microsoft's June updates, RoguePlanet targeted Microsoft Defender behavior and demonstrated a path to SYSTEM-level privileges.
Microsoft subsequently addressed RoguePlanet as CVE-2026-50656.
Then came August.
Nightmare Eclipse released ShieldBreak, claiming that Microsoft's remediation could be bypassed.
Independent security researchers have reproduced the ShieldBreak proof of concept on updated Windows systems, although questions remain regarding precisely how the new technique relates technically to RoguePlanet and Microsoft's previous remediation.
The distinction is important.
ShieldBreak should not simply be described as “RoguePlanet again.”
The broader point is that a security control and its remediation became part of an ongoing cycle of vulnerability discovery, patching, and bypass research.
There is another development organizations should pay attention to.
Some Nightmare Eclipse tooling appears to have moved beyond proof-of-concept research.
In April, Huntress reported observing tooling associated with BlueHammer, RedSun, and UnDefend during a real-world intrusion investigation.
That changes the risk calculation.
There is a major difference between vulnerability research sitting in a repository and exploit techniques appearing during an active intrusion.
Once exploit code becomes public, defenders are no longer the only people studying it.
Threat actors can study it too.
They can modify it.
They can incorporate techniques into other attack chains.
And they can combine privilege escalation with initial-access techniques, credential theft, ransomware, remote-management tools, or other malware.
The vulnerability does not need to provide the entire attack.
It only needs to provide one useful step.
Many of these vulnerabilities involve local privilege escalation.
That phrase can make the vulnerabilities sound less dangerous than remote-code-execution flaws.
After all, an attacker generally needs some level of access to the machine first.
But modern attacks rarely depend on one vulnerability.
Attackers build chains.
Imagine an attacker compromises a user through phishing, stolen credentials, malicious software, or another initial-access technique.
The attacker may initially inherit only the privileges of that user.
That limits what the attacker can do.
A privilege-escalation vulnerability can change that.
Moving from standard-user privileges to SYSTEM can give an attacker extraordinarily powerful control over a Windows endpoint.
The first compromise opens the door.
Privilege escalation can provide the keys to the building.
The Nightmare Eclipse campaign highlights a fundamental problem facing every cybersecurity program.
There is always a period between:
Vulnerability discovery → disclosure → detection → remediation → patch deployment.
Sometimes that period is months.
Sometimes weeks.
Sometimes days.
And sometimes defenders don't know the vulnerability exists at all.
That is the zero-day problem.
Traditional vulnerability management works extremely well for something that is known.
A vulnerability is discovered.
A CVE is assigned.
A patch becomes available.
Security teams identify vulnerable systems.
The patch is deployed.
Risk declines.
But what happens before that process begins?
That is where organizations need to think beyond vulnerability management alone.
The same concept applies to malware detection.
Detection technologies—including antivirus, EDR, XDR, threat intelligence, behavioral analytics, and AI-assisted security tools—are enormously valuable.
Organizations should use them.
But detection fundamentally asks a question:
“Does this activity look malicious?”
Attackers increasingly try to make the answer difficult.
They obfuscate code.
They modify malware.
They operate in memory.
They abuse legitimate applications.
They exploit trusted Windows components.
They disable security products.
They use vulnerable drivers.
They steal legitimate credentials.
And increasingly, attackers can use automation and artificial intelligence to modify and test techniques faster than before.
Eventually, the defender encounters something it has never seen.
The question then becomes:
What happens when detection doesn't recognize the attack?
A prevention-first security model approaches the problem differently.
Instead of depending entirely on determining whether something is good or malicious, organizations can also ask:
“What is this application allowed to do?”
Can an untrusted process modify critical system resources?
Can it execute from user-controlled locations?
Can it alter protected applications?
Can a compromised application reach resources it does not legitimately require?
Can an application suddenly perform actions outside its normal business purpose?
Those are fundamentally different security questions.
And importantly, answering them does not necessarily require knowing the attacker's malware family, exploit name, CVE number, hash, signature, or technique beforehand.
That is the principle behind application containment and zero-trust execution controls.
The objective is not to predict every attack.
It is to constrain what applications can do when something unexpected happens.
None of this means organizations should stop patching.
Quite the opposite.
Patch aggressively.
Use EDR.
Monitor endpoints.
Hunt for threats.
Maintain good identity security.
Segment networks.
Back up critical systems.
Every one of those controls matters.
But organizations should recognize what each security layer can—and cannot—do.
Patching protects against vulnerabilities we know about.
Detection identifies activity we can recognize as suspicious.
Response helps us act after something has been discovered.
Containment is designed to limit what can happen even when the threat has not yet been identified.
Those capabilities should complement each other.
BlueHammer.
RedSun.
UnDefend.
YellowKey.
GreenPlasma.
MiniPlasma.
RoguePlanet.
GreatXML.
LegacyHive.
ShieldBreak.
Ten public exploit or vulnerability disclosures over approximately five months.
Some have been patched. Some involve very specific prerequisites. Some represent substantially greater practical risk than others.
They should not all be treated as equivalent.
But collectively, they demonstrate something every security leader should consider.
There will always be another vulnerability.
And sometimes it will appear immediately after you installed the patches intended to make your environment secure.
The goal therefore cannot be to predict every vulnerability before attackers discover it.
The better goal is to build an environment where discovering the next vulnerability does not automatically give an attacker unrestricted control.
That means moving beyond a security strategy based entirely on:
Find it. Detect it. Patch it. Respond to it.
And adding another question:
What if we simply prevented it from doing what it was never supposed to do in the first place?
That may be the most important lesson from five months of Nightmare Eclipse.
And if the pattern continues, ShieldBreak probably won't be the last example.
Business owners who want to better understand how prevention-first security can stop attacks before damage occurs should talk with CHIPS about how AppGuard can help prevent incidents like this through Isolation and Containment.
TechRadar — “Microsoft's nemesis returns: Nightmare Eclipse is back with a new zero day which could be bad news for Windows users”
Identifies ShieldBreak as the tenth published exploit in the Nightmare Eclipse campaign and discusses its relationship to RoguePlanet and Microsoft's previous remediation.
Huntress — “Nightmare-Eclipse Tooling Seen in Real-World Intrusion”
One of the most important sources in the series. Huntress observed BlueHammer, RedSun and UnDefend tooling during an actual intrusion involving compromised FortiGate SSL VPN access. Huntress also provides detailed technical analysis of the three techniques.
Read the Huntress investigation
Huntress — “Threat View from the Lens of Huntress Adversary Tactics: April 2026”
Additional Huntress reporting on the movement of Nightmare Eclipse tooling from public proof-of-concept code into activity observed against a real target.
Read the Huntress April threat report
Barracuda — “Nightmare-Eclipse: six zero-days, six weeks and one big grudge”
Useful background on Nightmare Eclipse/Chaotic Eclipse, the researcher's dispute with Microsoft and the first six Windows exploit releases.
TechCrunch — “Microsoft under fire for threatening security researcher with criminal investigation”
Provides important background on the increasingly adversarial relationship between Microsoft and Nightmare Eclipse and the debate surrounding the researcher's decision to publicly disclose unpatched vulnerabilities.
Picus Security — “RoguePlanet: Anatomy of the Nightmare Eclipse Microsoft Defender Zero-Day”
Technical analysis of RoguePlanet, including the Defender privilege-escalation mechanism, SYSTEM-level execution and the significance of its release immediately following Microsoft's June Patch Tuesday.
Read the Picus Security analysis
SecurityWeek — “‘GreatXML’ Zero-Day Exploit Bypasses BitLocker”
Coverage of the separate GreatXML disclosure, which targets Microsoft Defender's Offline Scan functionality and can result in a SYSTEM command prompt in Windows Recovery Mode.
SecurityWeek — “Nightmare Eclipse Drops ‘LegacyHive’ Windows Zero-Day”
Coverage of the July Patch Tuesday disclosure targeting the Windows User Profile Service. The vulnerability allows access to other users' registry hives, including administrative profiles.