Nightmare-Eclipse’s exploit releases target Windows Defender, CrowdStrike, Avast, Kaspersky, and NVIDIA. If you run these products, the response depends on the version, enabled features, and whether an exploit actually works.
We pulled together the release history, vendor fixes, independent tests, and evidence from real attacks so you can assess your exposure and decide what to patch, reconfigure, or investigate. ShieldCrash is the latest claim in that series.
Who is Nightmare-Eclipse?
Nightmare-Eclipse is the public name of an anonymous researcher releasing exploit code for Windows and endpoint security products. The releases include BlueHammer, ShieldBreak, and the latest, ShieldCrash.
Nightmare-Eclipse typically posts proof-of-concept code to GitHub without coordinating disclosure with the vendor. Before ShieldCrash, Huntress documented an attacker trying BlueHammer, RedSun, and UnDefend in a real intrusion. Huntress did not attribute that intrusion to the researcher.
The latest: ShieldCrash
ShieldCrash arrived on September 8 as a claimed bypass of the ShieldBreak fix. Mallory tracks the release and supporting reports. The question is whether the published code can read a protected file through Defender after the September updates.
The September 8 README claims SYSTEM-level file reads and calls the release a skeleton proof of concept. A September 9 follow-up claimed a full escalation path. The evidence reviewed does not establish a corresponding code fix or a working SYSTEM execution chain.
Cyderes tested Windows 11 25H2 build 26200.9445 with Defender engine 1.1.26080.3, which contains the ShieldBreak fix. Reads of SAM, SECURITY, and ELAM failed. Each output was the same staged ntdll.dll, not the requested hive. No SYSTEM execution was demonstrated. Mallory’s review found no second substantive independent reproduction.
CrowdStrike’s assessment also leaves validation open. As of September 9, the sources reviewed identify no separate ShieldCrash CVE, Microsoft-confirmed affected-build list, ShieldCrash-specific fix, or observed exploitation in the wild.
Keep the ShieldBreak fix installed. Record Windows and Defender versions and update times. A patched ShieldBreak build does not establish whether ShieldCrash works or is blocked. The published code failed in the documented test; the underlying bypass remains unresolved.
Release, fix, and exploitation timeline
BlueHammer was attempted on April 10, four days before its April 14 fix. A patch date alone doesn’t tell you whether an endpoint was exposed. Compare the activity window with when that endpoint actually received the update.
Kevin Beaumont reported successful verification of HardBreacher, FalconFlank, and PrettyPrague on September 3. That post predates ShieldCrash and does not validate it. Splunk also published ShieldBreak attack-simulation data, separate from evidence of real attacks.
Status through September 9, 2026. “No confirmed wild use” means none in the reporting reviewed. Lab results and attempted use are listed separately from successful exploitation.
| Exploit | Public release / code | Fix milestone | Exploitation evidence |
|---|---|---|---|
| BlueHammerCVE-2026-33825 | Apr 2: Huntress disclosure date | Apr 14Platform 4.18.26030.3011 | Apr 10: attempted; blockedKEV added Apr 22 |
| UnDefendCVE-2026-45498 | Public by Apr 16First-public day unresolved. | May 12: fixed build datedPlatform 4.18.26040.7 | Apr 16: tool executed; stoppedKEV added May 20 |
| RedSunCVE-2026-41091 | Public by Apr 16First-public day unresolved. | May 5: fixed build datedEngine 1.1.26040.8 | Apr 16: overwrite attempt failedKEV added May 20 |
| RoguePlanetCVE-2026-50656 | Jun 9: repository activity | Jun 30: fixed build datedEngine 1.1.26060.3008 | Lab reproductionNo confirmed wild use in reviewed reporting. |
| ShieldBreakCVE-2026-69414 | Aug 11: code upload | Sep 1: fixed build datedEngine 1.1.26080.3 | Aug 17: Splunk attack simulationNo confirmed wild use in reviewed reporting. |
| HardBreacherKaspersky | Aug 28–29: repository activity | Aug 30: fixed databasesAdvisory issued Aug 31. | Sep 3: Beaumont verifiedNo confirmed wild use reported. |
| GreenSectionNVIDIA | Aug 29: code upload | No confirmed public fix date | Crash demonstratedNo confirmed wild use in reviewed reporting. |
| PrettyPragueAvast | Aug 30: code upload | By Sep 7: Gen says fixedExact rollout date and build not established. | Sep 3: Beaumont verifiedNo confirmed wild use reported. |
| FalconFlankCrowdStrike | Public by Sep 3 | No confirmed public fix dateConfiguration mitigation available. | Sep 3: Beaumont verifiedNo confirmed wild use reported. |
| ShieldCrashDefender | Sep 8: code upload | No patch or mitigation reportedCrowdStrike assessment, Sep 8. | Independent validation unresolvedAssessment and failed test described above; no confirmed wild use in reviewed reporting. |
Build dates come from Microsoft’s release notes. They can precede advisory dates or later fix reporting. Repository commit dates don’t prove first public visibility. KEV dates record catalog additions, not first attacks.
The recurring weakness
Security agents run with elevated privileges and routinely inspect, quarantine, and modify files that unprivileged users can reach. Mistakes at that boundary can turn normal remediation into arbitrary file access or code execution. Qualys’ ShieldBreak analysis describes how cloud-file hydration and path manipulation can redirect a privileged Defender operation.
Every release discussed here requires local code execution first. The Huntress incident shows the sequence clearly: compromised VPN access, then attempts to use the published tools.
MITRE ATT&CK mappings
These mappings cover documented exploit behavior, including lab results and attempted use. They don’t establish successful exploitation in the wild or attribution to the publisher.
GreenSection maps to denial of service. A scheduled task or temporary service used for elevation doesn’t establish persistence.
What defenders should check
- Check whether Falcon’s Office macro-removal capability is enabled. FalconFlank depends on that configuration. Follow the CrowdStrike mitigation guidance for the affected policy.
- For Kaspersky Endpoint Security 14.0 or 14.1, check the antivirus database date. HardBreacher’s fix is in August 30 databases and later.
- For Defender, check both engine and platform versions against the timeline. Record when each endpoint received the fixed build so you can scope the exposure window.
- For Avast, confirm which installed build contains the PrettyPrague fix. Gen says the issue is fixed; the reviewed statement doesn’t identify the build or rollout date.
- Hunt for Defender writing
phoneinfo.dllinto System32, or Falcon-related creation ofbcrypt.dllin the WindowsPowerShell directory, followed by SYSTEM execution. These are ShieldBreak and FalconFlank behaviors. - Review VPN sessions alongside endpoint events during the exposure window. In the Huntress incident, the attacker used compromised VPN access before attempting the exploits.
Nightmare-Eclipse’s releases span working exploits, patched flaws, unresolved claims, and real attack attempts. Defenders need that whole history, alongside the configurations they actually run, to decide where they’re exposed.
Mallory connects exploit releases, independent validation, vendor fixes, and observed attacks to your attack surface. As the evidence changes, your team can reassess affected systems and prioritize action without rebuilding the investigation across repositories, advisories, and incident reports.
- jcran
Read the exploit analysis in Mallory
Explore our ShieldCrash assessment and ShieldBreak exploit analysis, including the supporting sources. Create an account to view the analysis and continue your investigation.
Create an account