This post is written by Milot Shala, Cybersecurity Director at ANIMARUM, a Red Team Lead and Offensive Security Architect with 25 years of experience across enterprise security, cloud infrastructure, and adversary simulation. This is a part of From the Field series of blog posts.

Note: All testing described in this post was carried out on systems we own. The three proofs of concept discussed are public releases by the GitHub user MSNightmare.

The Third Round


On September 8, five days after Microsoft's second patch to this part of Windows Defender, a proof of concept called ShieldCrash showed up on GitHub. It aims at the same Defender function two other exploits have already reached this year. A dozen outlets covered it within a day. Its own author calls it a lazy skeleton, and after checking the record, that turns out to be the more accurate description.

Why We Kept Reading

We started on this research back in August. We ran ShieldBreak ourselves and read what other researchers were saying about it.

We finished with a question we could not answer. Was ShieldBreak's bypass the specific trick it used to lie about a file path, or was it the privileged function that believed the lie?

A month later Microsoft has patched twice and a third exploit has appeared, claiming to get past the second patch. So this is still a developing story, and we will certainly be writing follow-ups.

Round One: RoguePlanet

CVE-2026-50656, known as RoguePlanet, is a local privilege escalation in mpengine.dll, the scanning core of Windows Defender. Microsoft describes it in one line: improper link resolution before file access.

The exploit points a file path somewhere else using an NTFS junction on a virtual disk it mounts itself, timed against Defender's own file access. Microsoft fixed it on July 8 in engine build 1.1.26060.3008. The fix closed the thing the advisory describes, a filesystem link pointing somewhere Defender did not expect.

Round Two: ShieldBreak

Five weeks later, on August 11, the same author released ShieldBreak under the GitHub handle MSNightmare, claiming it beat the July patch on a fully updated machine.

ShieldBreak has no virtual disks and nothing that redirects a path at the filesystem layer. It uses two other parts of Windows instead. The first is the Cloud Filter API, the plumbing behind OneDrive Files On-Demand. The second is the object manager namespace, an internal tree of names that sits above the filesystem.

It works in four moves.

Stall. ShieldBreak registers itself as a cloud sync provider over its own working folder, which any standard user is allowed to do. That gives it a callback the kernel has to wait on whenever Defender reads a file in that folder.

Swap. While Defender is stuck mid-read, the exploit changes what one name in the object manager points to. It prepares two entries with the same name, where the second is only consulted after the first is deleted. Nothing on disk moves. What changes is which of two ready answers Windows gives.

Write. The redirected path reaches MpCleanStart, the function Defender uses to clean up a threat. Defender writes attacker-chosen bytes to C:\Windows\System32\phoneinfo.dll as SYSTEM. That filename does not ship with Windows.

Execute. The exploit starts a built-in Windows Error Reporting task that runs as SYSTEM and loads the DLL that was just planted.

So the two exploits arrive at the same place by different roads. RoguePlanet lies to the filesystem. ShieldBreak lies to the object manager. Both end up calling MpCleanStart.

Will Dormann and Kevin Beaumont, who both reproduced ShieldBreak, said in public that it does not look like a RoguePlanet bypass, and they are right about the mechanism. Microsoft agreed in the most concrete way a vendor can. Instead of reopening the old CVE, it issued a new one, CVE-2026-69414, under a different weakness class, and patched it on September 3 in engine build 1.1.26080.3. That was twenty-three days after the exploit went public.

Round Three: ShieldCrash

The repository went up empty on September 7. The code arrived the next day. The README points at ShieldBreak's CVE and says Microsoft "failed to properly patch" it and "missed a spot." The same README calls the release a skeleton and says the author may finish it later. Those two claims pull in different directions, so we are keeping them apart. One says the fix failed. The other says the tool meant to prove it is not done.

The source reads as a continuation of ShieldBreak rather than something new. The stall and the swap are carried over unchanged, not rewritten. Three things are added.

It brings back redirection at the filesystem layer, the exact trick the July patch was written to stop, layered on top of the object manager swap instead of replacing it. It links against the kernel transaction manager library and the library WebDAV clients use. And it changes what you type on the command line. Rather than running by itself to a SYSTEM shell, it now takes one argument, the path of a file to steal.

That argument is the interesting part. ShieldCrash converts the path you give it into the format Windows uses internally, then sends Defender's privileged read through the same stall and swap that used to end in a fixed write. What comes back lands in a file the user who ran the tool can read.

There is no shell at the end. No token stealing, no Windows Error Reporting, no planted DLL. phoneinfo.dll does not appear anywhere in the source, and neither does the Error Reporting task. What the code is shaped to do, if it does anything, is read any file as SYSTEM.

Two details back up the author's own skeleton label. The transaction and WebDAV libraries are linked in but never used. The transaction functions are never called, and the WebDAV handle the code creates is never waited on or signaled. And the repository still ships the payload DLL and the EICAR archive from ShieldBreak, left over from a chain this code no longer completes.

How Microsoft Responded Last Time

The interesting part of this story is not the exploit. It is the shape of Microsoft's response to the last one, because that is a matter of record and it is worth walking through before anyone predicts what happens with this one.

ShieldBreak went public on August 11. By August 12 we had a step by step picture of the chain, down to the detail that wer.dll contains explicit code to load phoneinfo.dll. So this was confirmed inside twenty-four hours.

Microsoft picked it up on August 17, six days in, assigning CVE-2026-69414 and saying it was "working to provide a high quality security update that addresses this vulnerability."

Then on August 25, nine days before any patch shipped, we saw researchers report they could no longer reproduce ShieldBreak on a machine with current Defender signatures. We tried it too and could not reproduce it either. What happened was, the exploit's own temporary file was tripping a detection, Trojan:Win32/Zynonm!rfn, with the file creation call failing at 0xC0000906, and the detection fired before anything was written to the file. This was the filesystem filter catching it rather than a traditional signature, and it still fired when the directory and filename were changed. So we all thought this was fixed.

That is Microsoft shipping a block through the signature channel, more than a week ahead of the engine fix, without telling anyone. The engine patch itself landed on September 3 in build 1.1.26080.3. The advisory records the fix but not the quiet block that preceded it. Sneaky.

And This Time

Nothing yet, and the record is unusually easy to check.

Microsoft's advisory for CVE-2026-69414 has not been revised since the September 3 patch. No CVE has been assigned to ShieldCrash. September's Patch Tuesday shipped on the same day the code landed and contains no Defender engine content at all, only two unrelated Firewall Service entries. Neither CVE has ever appeared in CISA's Known Exploited Vulnerabilities catalog, and the exploitation flag on CVE-2026-69414 still reads "Exploited: No." On that advisory, the one for ShieldBreak, Microsoft credits the researcher only as "Anonymous." The live engine build Microsoft is shipping today is still 1.1.26080.3, the one that fixed ShieldBreak.

Two Patches, One Function

Put ShieldCrash's claim aside for a moment, because there is a pattern under it either way.

Three exploits, three different parts of Windows used for redirection, one function at the end. RoguePlanet goes through NTFS junctions on a virtual disk. ShieldBreak goes through the object manager and the Cloud Filter API. ShieldCrash stacks filesystem-layer redirection, a transaction and a local WebDAV handshake on top of that same foundation. All three call MpCleanStart, and that call has not changed across any of them.

Two exploits look like coincidence. A third, arriving through unrelated parts of Windows and landing on the same function, starts to look like something about that exact function.

Microsoft's position deserves a fair hearing though. It issued a new CVE under a different weakness class rather than reopening the old one, which is the vendor saying these are separate bugs. There is something to that. "Fix the function, not the trick" is true at a level general enough to describe almost any privilege escalation, and it does not tell you which lines of code to change. If July and September genuinely fixed different code solving different problems, then rewriting MpCleanStart to work from handles end to end is a re-architecture, not a patch. Fixing the door someone actually used is not unreasonable.

What tips it for us is the rate. Three techniques against the same function in three months, each needing real knowledge of a different Windows subsystem, reads more like the function being the target than like unrelated bugs that happen to share an address.

What To Do Right Now

The engine build to be on is 1.1.26080.3, which closed both RoguePlanet and ShieldBreak. There is nothing newer. That is also the build Microsoft is shipping today, so being current settles the two documented CVEs and says nothing about the third.

Watching for it is the harder problem, because most of what this chain does leaves nothing behind in standard tooling. Creating a mount point produces no Sysmon event at any version, because Windows never logged the underlying call, and mount points never needed elevated rights the way symbolic links do, so nobody built one. ShieldCrash's WebDAV use is local, a loopback handshake rather than a remote connection, so the usual WebDAV detection material about NTLM relay does not apply. The one visible trace is the WebClient service starting on a machine where it is normally off. Turning that service off where it has no reason to run removes one of the three pieces ShieldCrash adds, whether or not the claim holds.

The Close

Three exploits, three ways in, one function that has not changed. Microsoft has patched around it twice and has said nothing at all about the third attempt. If the last round is any guide, the first sign that something moved will not be an advisory. It will be a detection showing up quietly in the signature channel, the way it did in August. We are watching for it, and we will write it up when it happens.