Windows

A researcher going by Chaotic Eclipse, also known online as Nightmare Eclipse, Infinite Nightmare and MSNightmare, published a public proof of concept called ShieldCrash in the days after Microsoft's September 8 Patch Tuesday. It demonstrates an arbitrary file read with SYSTEM privileges on every currently supported version of Windows, including machines that installed that month's updates in full. There is no CVE for it yet and, as of this writing, no confirmed fix.

It is the third name given to the same underlying Windows Defender problem. A bug called RoguePlanet was patched in July, a second exploit called ShieldBreak bypassed that patch in August, and Microsoft patched ShieldBreak on September 8. Chaotic Eclipse says that fix is incomplete too, and ShieldCrash is the proof. The technique needs an attacker who already has code execution on the machine, so it is a post-compromise privilege step rather than an initial way in, but anyone running Windows Defender, which is most Windows machines by default, is affected in principle.

How it works

Windows Defender's scanning engine runs with very high privileges, because it has to open, read and sometimes quarantine files that belong to other users or sit in protected parts of the system. That privilege is the constant thread through RoguePlanet, ShieldBreak and ShieldCrash: each one finds a different way to make Defender act on a file the attacker controls while Defender still believes it is acting on its own authority.

ShieldCrash's version has the exploit create a file at %TEMP%\ShieldCrash_<GUID>.BERN2:stream. That colon-and-name suffix marks an NTFS Alternate Data Stream, a lesser-known feature of the NTFS file system that lets a single file carry more than one named stream of data behind its default, visible one. Alternate data streams have a long history of being used to hide or smuggle data, because many tools, including some scanners, only look at a file's default stream and never check whether it is carrying a second one.

When Defender, still running as SYSTEM, opens and processes that file, the exploit memory-maps the stream, meaning it maps the stream's bytes directly into its own process memory instead of reading them through an ordinary file read call, then copies what it finds into an output file named <target_filename>.<GUID>, written next to the exploit binary. Point that at a file the attacker's own account has no permission to open, such as C:\Windows\System32\config\SAM, the registry hive that stores local Windows account password hashes, and the copy comes out anyway, because it was Defender's SYSTEM token that actually opened the file. Chaotic Eclipse specifically says the technique can be used to dump the SAM database. The researcher has not claimed arbitrary file write or remote code execution, only read access, so ShieldCrash on its own does not put an attacker on the machine, only lets them pull more off it once they already are.

The claim, the test and Microsoft's response

Three things are worth keeping separate. Chaotic Eclipse's own claim is that ShieldCrash works on every currently supported Windows version after the September updates and can reach the SAM database. Independent testing has not settled that: Cyderes' Howler Cell team tried to reproduce the exploit and reported that their attempts failed at a timing-sensitive step, and that they could not confirm the primitive as described. The SAM-dumping claim in particular has not been verified by anyone outside the researcher.

Microsoft's own public position is narrower than either of those. Its advisory for CVE-2026-69414, the ShieldBreak vulnerability that the September update addressed, states that the fix needs no customer action and has no effect on systems that have Windows Defender disabled. That statement is about the ShieldBreak fix, shipped as Malware Protection Engine version 1.1.26080.3. As of this writing, Microsoft has not published an advisory, a CVE or any public comment addressing ShieldCrash by name.

The chain: patched twice, bypassed twice

Lay the dates side by side and the pattern is hard to miss. RoguePlanet (CVE-2026-50656, CVSS 7.8) was weaponized in early June and patched on July 9 with engine version 1.1.26060.3008. ShieldBreak (CVE-2026-69414, also CVSS 7.8), a bypass of that same fix, went public on August 12, 34 days later. Microsoft patched ShieldBreak on September 8. ShieldCrash, a bypass of that patch, went public a day or two after it shipped.

The gap between a fix shipping and its bypass going public shrank from more than a month to under 48 hours. Each patch closed the specific proof of concept in front of it without closing the design gap underneath: Defender's privileged file handling still trusts something about the target file, whether that is a race condition, a redirected cloud sync callback, or an alternate data stream, that an unprivileged attacker can influence, so a different way to reach the same result keeps turning up. The practical lesson for defenders reaches beyond Defender. When a fix for a specific proof of concept is followed within weeks by a new one that reaches the same result a different way, that usually means the first patch addressed the demonstration rather than the design flaw, and it is worth checking exposure again rather than assuming the first fix already covered it.

What to do

There is no ShieldCrash-specific fix to apply yet, so the useful work is limited to reducing exposure and watching for the technique.

ShieldCrash needs an attacker who can already run code on the machine, so the local access that gets them there is the real risk to close. Ordinary defenses against getting to that point, keeping systems patched, cutting unnecessary local admin rights, and running endpoint detection that flags unusual process behavior, remain the first and most useful line of defense.

Hunt for the pattern rather than a signature. A file created at %TEMP%\*.BERN2:stream, or an output file with a GUID-style suffix (a long hyphenated hexadecimal string) appearing next to an executable nobody recognizes, is a concrete sign this specific technique ran on a host. Add both to your EDR or Sysmon file-creation watchlist rather than trying to catch it from process names alone, since the exploit binary itself can be renamed.

Watch Microsoft's update channel rather than assuming it is already covered. Defender's security intelligence and engine updates usually deploy automatically several times a day, but a managed fleet can still lag. Run Get-MpComputerStatus in PowerShell, or check Windows Security under Virus & threat protection, then Protection updates, and confirm the engine version is current on managed machines rather than assuming last month's Patch Tuesday already closed this one too.

If you find the pattern, treat it as a completed privilege escalation, not noise. A host showing these indicators may have had its SAM database read, so rotate the local Administrator and any other local account passwords on that machine and check whether those credentials turn up anywhere else on the network before you consider it clean.

Design gaps like this, where a highly privileged component can be tricked into acting on a file the attacker actually controls, show up in code we review for clients too, not only in Windows Defender. Our red team and code review work looks for that class of trust boundary before an attacker does. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: SecurityWeek, Security Affairs, GBHackers, Cyberpress, Cyderes Howler Cell, SOCRadar, Qualys on ShieldBreak, CyberMaxx on ShieldBreak, Help Net Security on RoguePlanet's patch, Help Net Security on RoguePlanet's disclosure.