Microsoft has closed a privilege-escalation zero-day in Defender, the anti-malware product built into Windows, after the first patch it shipped for the flaw did not actually seal the vulnerability. The closing fix is tracked as CVE-2026-50656, and the closure was reported the same day by The Register's security desk.
The bug is a privilege-escalation in Defender. Code running with low user rights on a Windows machine could use the flaw to elevate to system-level access, a position from which an attacker can disable the very anti-malware meant to contain them. Microsoft identifies the threat actor as "Nightmare Eclipse"; the public proof-of-concept that documents the chain lives in a GitHub repository named "RoguePlanet." Kudelski Security's research on the bug is the cleanest mechanism read in hand.
Microsoft issued a first patch for the issue that did not close the underlying defect, leaving Defender-protected Windows machines exposed during the interim before the second fix. That kind of patch-validation gap, where the advisory is marked resolved but the vector remains open, is rarer than the zero-day itself. The harder operational signal is that defenders usually react to a closed advisory by stopping their watch on the issue.
A public proof-of-concept has lived at the MSNightmare/RoguePlanet repository on GitHub throughout. A working PoC turns a vulnerability that only a sophisticated attacker could exploit into one that a wider audience can run. Reverse engineers, red teams, and defenders benefit. So do the attackers who don't have to reconstruct the chain themselves.
Independent analyses from Picus Security and PurpleSec reach the same mechanism conclusion: privilege-escalation in Defender, fix shipped in two parts, second one held. Two vendor analyses arriving at the same read on a single CVE carry more weight than either alone. The formal record, in the form of the Tenable CVE entry plus MSRC's affected-build list, confirms the identifier and tracking but not the corporate post-mortem.
The operational question for enterprise IT is whether the second, working patch is actually installed on every Defender-enrolled machine. "Patched" in a vulnerability management console usually means the vendor's advisory is satisfied. It does not separately track which fix revision closed the bug. For teams running Defender at scale, the verification step that matters is not whether the advisory is closed but whether the second patch landed and not just the first. Defender's update channel normally pushes new engine versions automatically; the gap to audit is the set of machines that fetched the first revision before the second was published.
Microsoft's Defender ships on hundreds of millions of Windows machines by default, where it is the front-line anti-malware on most enterprise endpoints and on consumer PCs that have not replaced it with a third-party product. A privilege-escalation in that surface is not a niche issue. The closing fix is dated 2026-07-09. Verifying it landed, on every endpoint and not just the first patch, is the work that follows the press release.