Nightmare Eclipse has spent much of 2026 probing the places where Windows trusts security software to act with more authority than an ordinary user. The latest releases widen that experiment. Microsoft Defender is still in scope, but so are CrowdStrike Falcon, Kaspersky Endpoint Security, Avast Antivirus, and NVIDIA’s Windows graphics components.

That does not make all five findings Windows vulnerabilities, and it does not mean an internet attacker can remotely crash or take over any Windows PC. The common prerequisite is local code execution: an attacker, malicious installer, or compromised user process must already be able to run code on the endpoint. The PoCs then test whether a trusted, more privileged component can be induced to cross a security boundary.

The distinction matters because the five releases have very different evidence. Some privilege-escalation paths have been reproduced. One crashes graphics applications but has not demonstrated a Windows kernel crash or code execution. The newest, ShieldCrash, makes an important patch-bypass claim that an independent lab could not reproduce with the code as published.

TL;DR

  • Nightmare Eclipse published five notable Windows-focused PoCs between August 28 and September 8, 2026: HardBreacher, GreenSection, PrettyPrague, FalconFlank, and ShieldCrash.
  • HardBreacher, PrettyPrague, and FalconFlank target third-party endpoint security products. GreenSection targets NVIDIA user-mode graphics components. Only ShieldCrash directly targets Microsoft Defender.
  • These are local post-compromise techniques, not remote entry points. Preventing untrusted code from running is the most useful shared control.
  • GreenSection has demonstrated application crashes, not a Windows-wide crash or privilege escalation.
  • ShieldCrash claims a SYSTEM-context arbitrary file read after Microsoft’s ShieldBreak fix, but Cyderes Howler Cell found that the released code returned its own copy of ntdll.dll instead of the requested protected file.
  • Update every security product through its own channel, verify versions and policy state fleet-wide, and hunt for behavior rather than only the public PoC filenames.

What Changed Since the Earlier Nightmare Eclipse Releases

The first part of this disclosure sequence concentrated on Windows itself: Defender remediation, Cloud Files, Windows Recovery Environment, BitLocker, and the User Profile Service. BlueHammer, RedSun, YellowKey, RoguePlanet, GreatXML, LegacyHive, and ShieldBreak all explored different ways to turn trusted Windows behavior into a security-boundary failure.

The late-August and early-September releases test the same architectural idea across a broader endpoint stack. Antivirus and EDR products must inspect hostile files, restore or rewrite content, load components, expose kernel interfaces, and act with high privilege. Graphics drivers share data across processes for performance. Those capabilities are necessary, but every transition from attacker-controlled input to privileged action needs strict validation.

This is the common thread. It is not proof that every affected vendor made the same mistake, or that Microsoft is responsible for flaws in third-party products.

Five PoCs, Five Different Evidence Levels

PoCPublic releaseTargetDemonstrated or claimed resultStatus as of September 12
HardBreacherAugust 28Kaspersky Endpoint Security for WindowsUnstable local path to influence the Kaspersky UI process and create an attacker-controlled file in System32Kaspersky told The Hacker News that it resolved the issue through an automatic database update; current update state still needs verification.
GreenSectionAugust 29NVIDIA user-mode graphics componentsCorruption of a writable shared-memory section and crashes in applications using Vulkan or OpenGLThe repository and third-party analysis describe application crashes; no demonstrated SYSTEM elevation, kernel crash, or code execution. No specific public NVIDIA advisory was identified at publication time.
PrettyPragueAugust 30Avast Antivirus sandboxAccess to a sandbox copy of the SAM database, local account manipulation, and a SYSTEM shellGen confirmed a privilege-escalation issue affecting a subset of products and said it was developing a patch. LevelBlue described the issue as remediated by September 9. Impact on AVG or Norton remains an author claim.
FalconFlankSeptember 3CrowdStrike Falcon SensorLocal elevation to SYSTEM through optional Office macro-remediation behaviorIndependently reproduced, but configuration-dependent. CrowdStrike advised disabling the affected macro-removal setting, deployed behavioral protections, and reported hotfixed sensors in testing on September 9.
ShieldCrashSeptember 8Microsoft Defender Malware Protection EngineClaimed arbitrary protected-file read as SYSTEM after the ShieldBreak fixMicrosoft has not published a ShieldCrash-specific advisory. Independent testing found that the released PoC fails before the privileged read, while leaving the underlying technique worthy of further investigation.

None of the latest five has been publicly documented as actively exploited in the wild at the time of writing. That is different from saying exploitation is impossible. Earlier Nightmare Eclipse tooling has appeared during a real intrusion investigated by Huntress, although the observed BlueHammer and RedSun attempts did not succeed in that incident.

HardBreacher: Kaspersky’s Trusted Process as a Loader

HardBreacher targets Kaspersky Endpoint Security for Windows 14.0.0.504 in the researcher’s test environment. The released code uses a session-specific Windows object namespace and a short-lived path redirection so that Kaspersky’s avpui.exe process loads an attacker-controlled DLL rather than the expected library.

LevelBlue SpiderLabs found that the payload also disguises the process relationship by recording explorer.exe as the parent and then suppresses a Kaspersky notification before terminating the UI process. This does not permanently uninstall Kaspersky, but it can blind the user-facing notification path for the session. Current Kaspersky databases detected the public exploit in LevelBlue’s online test; an offline or update-delayed endpoint did not receive that protection.

Kaspersky told The Hacker News that it had resolved the issue and that the corresponding fix arrives through automatic updates or a manually triggered database update. The operational lesson is easy to miss: checking only the installed product version is insufficient. Security-content freshness is part of the patch state.

GreenSection: An Application Crash, Not a Proven Windows Crash

GreenSection is the one release in this group that literally makes software fall over. It finds an NVIDIA global shared-memory section that an ordinary process can open with read/write access. The PoC overwrites the shared data, after which an application using Vulkan or OpenGL crashes inside an NVIDIA user-mode component.

The published result is meaningful denial of service against affected applications. It is not evidence that Windows itself blue-screens, that the NVIDIA kernel driver is compromised, or that an attacker gains SYSTEM. Nightmare Eclipse speculated that the primitive might cross user boundaries or affect dwm.exe, but the published PoC does not establish those outcomes. LevelBlue reached the same narrower conclusion: the writable section exposes a questionable trust relationship, while privilege escalation and code execution remain unproven.

For gaming workstations, CAD systems, rendering nodes, and other GPU-heavy endpoints, repeated graphics-process crashes should still be investigated. Do not automatically classify them as defective hardware if they coincide with an unknown executable mapping NVIDIA shared-memory objects.

PrettyPrague: Avast’s Sandbox Exposes Credential Material

PrettyPrague targets Avast’s sandbox driver. LevelBlue’s analysis found that a standard-user process could ask the driver to run a chosen executable inside the sandbox, where Avast maintains a virtualized copy of the Windows SAM registry hive. The exploit races the sandbox cleanup, copies the virtualized hive, decrypts local NTLM password hashes in memory, temporarily changes local administrator passwords, and uses the resulting access to start a SYSTEM process.

This is much more than an antivirus crash. If successful, it crosses from a local standard user to credential access and full local control. Gen confirmed that a vulnerability affecting a subset of its products could allow privilege elevation and said it was developing a patch; LevelBlue’s September 9 analysis subsequently described PrettyPrague as remediated. The public repository speculates that AVG and Norton may share the exposure, but that broader product impact has not been independently established. Defenders should verify the current release in the affected product’s own update and management console rather than extrapolating from the Avast test.

FalconFlank: A Cleanup Feature Becomes the Write Primitive

FalconFlank targets CrowdStrike Falcon’s optional Microsoft Office malicious-macro removal setting. The attack uses filesystem redirection and timing controls to influence where a privileged cleanup operation writes, then attempts to load the planted DLL as SYSTEM.

The exposure is configuration-dependent. LevelBlue found that the relevant prevention policy must have Office macro removal enabled, and its own test was stopped by Falcon’s cloud-based detection before the SYSTEM shell appeared. Vega and Tanium separately reported successful reproduction of the privilege-escalation path. These results are not contradictory: prevention content, sensor version, policy state, and test timing can change the outcome while the vulnerable behavior still exists.

CrowdStrike’s immediate guidance was to disable the Microsoft Office File Suspicious Macro Removal Windows policy setting while retaining Cloud Anti-malware for Microsoft Office Files. By September 4, the company said it had deployed additional behavioral protections globally. Its September 9 support update said hotfixed Windows sensors were in testing and planned for release the following week. Customers should follow the current Falcon support-portal alert because a future sensor number will supersede this article.

ShieldCrash: The Most Important Claim Is Not Yet Proven

ShieldCrash returned the focus to Microsoft Defender hours after September Patch Tuesday. Nightmare Eclipse describes it as a surviving path through Microsoft’s fix for ShieldBreak, the Defender elevation-of-privilege vulnerability tracked as CVE-2026-69414.

Microsoft’s official CVE record says ShieldBreak was an important-severity local elevation-of-privilege flaw, rated CVSS 7.8. Microsoft lists Malware Protection Engine 1.1.26080.3 as the first version that addresses it and reports no known exploitation of that CVE. ShieldCrash’s repository claims that the corrected engine can still be made to read an arbitrary protected file as SYSTEM, although the released skeleton stops short of a SYSTEM shell.

Cyderes Howler Cell tested the published code on Windows 11 25H2 with the corrected engine. The chain reached Defender remediation but failed when an open log file prevented creation of the required reparse point. Every requested protected hive produced the same output: the copy of ntdll.dll that the PoC had placed in its own alternate data stream during setup. The researcher’s screenshot showed the same size discrepancy.

The defensible conclusion is deliberately narrow:

  • The released ShieldCrash code did not perform the claimed arbitrary file read in Cyderes’ test.
  • That result does not prove the underlying Defender path is safe. The failure was an implementation error before the attempted security-boundary crossing.
  • Microsoft had not issued a ShieldCrash-specific advisory or mitigation as of September 12.
  • Calling ShieldCrash a confirmed SYSTEM compromise, or a confirmed patch bypass across all supported Windows versions, goes beyond the available evidence.

What Users Should Do

The shared control is to stop unknown local code before it reaches these privileged components. None of the five PoCs is a remote exploit that compromises a machine merely because it is online.

For personal Windows systems:

  1. Install Windows and Defender updates, then verify Defender itself. Windows Update status does not prove that the Malware Protection Engine is current. Open Windows Security and check for protection updates. Engine 1.1.26080.3 is the minimum version Microsoft identifies for the original ShieldBreak fix; use the newest version offered, not that historical floor as a target.
  2. Update third-party security products from their built-in updater. Avast and Kaspersky users should confirm both application and security-content updates. Do not download a supposed Nightmare Eclipse fix from a forum, file-sharing site, or social-media link.
  3. Update NVIDIA drivers from NVIDIA or the computer manufacturer. This is sound hygiene while GreenSection’s vendor status remains unclear, but do not claim a random new driver is a confirmed fix unless NVIDIA says so.
  4. Do not compile or run these PoCs on a normal PC. Public repositories can contain destructive binaries, embedded test files, or later malicious changes. A production workstation is not a vulnerability lab.
  5. Keep recoverable backups. A local privilege escalation can lead to credential theft, ransomware, or security-tool tampering after the attacker gains SYSTEM, even when the original PoC does not delete data itself.

Do not respond by installing several antivirus products side by side. Multiple real-time engines can introduce conflicts and more privileged attack surface. Keep one supported endpoint stack current and add controls that prevent untrusted execution.

What Enterprise Defenders Should Do

1. Inventory Products, Versions, and Exposed Features

Build a fleet view that includes Windows build, Defender engine and platform version, third-party sensor version, security-content timestamp, and relevant policy state. For Defender, Get-MpComputerStatus exposes AMEngineVersion and AMProductVersion. For Falcon, identify endpoints with the affected Office macro-removal policy enabled and follow CrowdStrike’s current mitigation and hotfix guidance.

2. Restrict Local Execution

Use Windows Defender Application Control, AppLocker, or another application-control layer to block unsigned or unapproved executables and DLLs from user-writable locations. This is not a substitute for vendor fixes. It reduces the number of footholds that can invoke a local privilege-escalation PoC while updates and detections catch up.

3. Hunt for Behavior, Not Repository Names

The public filenames and named pipes are useful for quick triage, but an attacker can change them. Higher-value signals include:

TargetBehavior worth correlating
Kasperskyavpui.exe launched through an unexpected parent or loading a DLL from %TEMP%; object-namespace or drive-letter redirection from a user process.
AvastA non-Avast process opening \\.\aswSnx; access to a transient Avast sandbox SAM hive; unusual samlib.dll use and rapid local-account changes.
NVIDIAA non-NVIDIA process mapping and modifying NVIDIA global shared-memory sections shortly before Vulkan, OpenGL, or desktop-process crashes.
CrowdStrikeReparse-point or junction creation followed by writes toward protected Windows paths; unexpected DLL staging around Office macro remediation.
DefenderUnknown software registering a Cloud Files sync root, loading MpClient.dll, using loopback access to the local administrative share, and changing Object Manager links during Defender remediation.

Correlate these events with the initial executable, user identity, download source, process ancestry, and follow-on activity. A single graphics crash or Defender detection is not proof of exploitation.

4. Treat Successful Elevation as an Incident

If telemetry indicates a SYSTEM shell, protected-hive access, unauthorized DLL placement, or security-tool disruption, isolate the endpoint and investigate the original foothold. Preserve EDR telemetry, Windows event logs, security-product logs, process trees, and relevant temporary directories before remediation. Rotate credentials when SAM or other credential material may have been exposed.

The Boundary Microsoft and Security Vendors Must Fix

The important story is not the personality conflict surrounding Nightmare Eclipse. It is the repeated failure mode: a standard-user process controls some combination of path, timing, shared state, or input, and a trusted security component later acts on it with greater authority.

Microsoft defines the security boundaries and primitives exposed by Windows. Third-party vendors are responsible for how their privileged agents use those primitives. Defenders control neither implementation, but they do control update coverage, application execution, telemetry, and response readiness.

That is the practical way to read this release streak. Do not treat every repository claim as a confirmed zero-day. Do not dismiss the code merely because one PoC is unstable or currently broken. Track the evidence for each technique, close the configurations vendors identify, and assume public exploit code will be studied by people with more time than its original author.

Sources