RoguePlanet: a Windows Defender race-condition PoC that ends in a SYSTEM shell

What RoguePlanet actually is, and who it is written for

The repository describes itself in one line: "RoguePlanet Windows Defender Vulnerability". It is a proof of concept, not a tool. The README opens with a greeting, explains that the bug is a race condition, and reports that the author achieved a 100% success rate on some machines while it struggled on others. That is the whole framing. There is no usage section, no threat model, no affected-version table, and no vendor timeline.

The audience follows from that. This is for people who read C++ exploit code and already understand Windows privilege boundaries: vulnerability researchers reproducing a Defender finding, red teamers who need to know whether a race window is reachable in a given environment, and defenders who want to see what the trigger path looks like before they write a detection. It is not a turnkey escalation utility. Anyone looking for a binary that reliably hands back a SYSTEM shell on an arbitrary host will be disappointed by the project's own account of its reliability.

The race condition and the ISO mount behind the trigger

The mechanism the README commits to is a race condition. It does not describe the two operations that race, which files or handles are involved, or what the winning interleaving looks like. The only concrete detail about the trigger path is a negative one: the author states the PoC does not work on Windows Server because standard users cannot mount an ISO image. That single sentence is the most informative line in the README, because it tells you the exploit path goes through mounting an ISO as an unprivileged user. Whatever else the race involves, an ISO mount is part of the setup, and if that primitive is unavailable the PoC cannot proceed.

The repository layout matches the scope: LICENSE, README.md, RoguePlanet.cpp, RoguePlanet.exe, RoguePlanet.png. One source file, one prebuilt binary, one screenshot. There is no build system, no header directory, no test harness, no detection rule, and no write-up beyond the README. If you want to understand the race, you read the .cpp. The author also states a belief, explicitly marked as uncertain, that a redesign of the PoC could reach a 100% success rate regardless of conditions, and adds that they are done with the bug. So the reliability question is left open on purpose, not solved.

Getting RoguePlanet from the repository

The README gives no install instructions, no build command, and no usage example. It says the exploit was tested on Windows 11 (Official channel and Canary) and Windows 10 with the June 2026 patch installed. That is the only environment guidance available, and it is a statement about testing, not a support matrix.

What the repository does give you is a single translation unit. The file is named RoguePlanet.cpp at the top level, so the compile step is a one-file build against the Windows toolchain. The repository does not document the compiler invocation, the required headers, or the libraries to link, so any build line you write is yours to figure out from the source, not something the project supplies. Read RoguePlanet.cpp first and see what it includes before you try to compile it.

If you would rather not build anything, the repository also carries RoguePlanet.exe at the top level. Running a prebuilt binary from a security repository is a decision you make with your eyes open; the README does not publish a hash, a signature, or build provenance for it.

The README's own description of the outcome is unambiguous: "If the exploit succeeds, a SYSTEM shell will be spawned". It also warns that the exploit is a race condition and therefore "a hit or miss". Run it in a disposable virtual machine with a snapshot, not on a workstation you care about. If the race is lost, the README does not say what the failure looks like, whether the process exits cleanly, or whether it leaves artefacts behind.

The Windows Server gap and the reliability problem

Two limitations are stated by the author, and both matter more than anything else on the page.

The first is the Server gap. The PoC does not work on Windows Server installations because standard users cannot mount an ISO image there. The author is explicit that this is a limitation of the proof of concept, not of the underlying bug: "I'm confident that all Windows Server versions are vulnerable as well but by the time I figured out it that the PoC doesn't work in Windows Server installations, it was a too late to redesign the exploit to overcome this issue." So the repository cannot be used to demonstrate the issue on Server as it stands. Confirming it there means rebuilding the exploit around a different primitive, which is a research project, not a configuration change.

The second is reliability. The author reports 100% success on some machines and difficulty on others, and calls the exploit a hit or miss. For a proof of concept that is acceptable; the point is to demonstrate that a window exists. For anything operational it is disqualifying, because a race you cannot win on demand gives you no signal about whether a target is patched or merely unlucky. The README does not document rollback, cleanup, or how to tell a lost race from a blocked one, so treat every negative result as inconclusive.

How RoguePlanet differs from a Metasploit module or a CVE write-up

The natural comparison is a Metasploit module for a local privilege-escalation bug. A module in that framework ships with a check method, a target list, retry logic, a payload stage, and a session handler. RoguePlanet has none of that: it is one .cpp file and one .exe, with no version detection and no retry loop documented. If you need repeatable exploitation across a fleet, with logging and a clean session, the framework is the better fit, and the difference is not the bug but the engineering around it.

The second comparison is a published CVE write-up. A write-up gives you the patch diff, the vulnerable function, the fix commit, and a timeline. The README for RoguePlanet gives none of these. It does not name the vulnerable component, the affected Defender build, or a patch state, so you cannot use it to decide whether a given machine is exposed. That is the real cost of the repository's minimalism: it proves a point and leaves the analysis to you.

Licence, maintenance and the cost of tracking this code

The repository carries an MIT licence, which permits use, modification, and redistribution provided the copyright notice and permission notice are retained. MIT offers no warranty and no patent grant, and it says nothing about whether running the code is lawful in your jurisdiction or consistent with your employer's rules. Offensive security code carries obligations that a licence file cannot address; that is a question for your legal and compliance teams, not for the LICENSE text.

The maintenance picture is thin by design. The last push to the repository was on 2026-06-09, and the author states plainly that they are done with the bug. There is no release history, no changelog, and no issue tracker activity visible in the repository contents. Upgrading is therefore not a thing you do on a schedule; there is no upstream to pull from. If you vendor RoguePlanet.cpp into your own tooling, you own it from that moment, including any fixes for new Windows builds. Given that the author describes the exploit as environment-sensitive, expect that ownership to include re-testing on every Windows and Defender update you care about.

Editorial conclusion

RoguePlanet is for Windows security engineers and red teamers who already have a lab, a snapshot, and a reason to study a Defender race condition; the README says the exploit has been tested on Windows 11 (Official channel and Canary) and Windows 10 with the June 2026 patch installed. It is not for anyone who needs a dependable, repeatable escalation, and it is not usable as shipped on Windows Server, because the README states standard users cannot mount an ISO image there. Before you touch it, read RoguePlanet.cpp and confirm two things: which build of Defender and which Windows build your target runs, and whether the ISO-mount step that the PoC depends on is permitted for a standard user. If either answer is no, the PoC's own reported hit-or-miss behaviour is the least of your problems.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. MSNightmare/RoguePlanet on GitHub
4. README