LegacyHive: PoC drops for unpatched Windows LPE zero-day

A researcher publishing as “Nightmare Eclipse” dropped a proof-of-concept on GitHub last week for a Windows local privilege escalation they’re calling LegacyHive. There’s no CVE ID yet, there’s no patch, and Microsoft’s on-record response is that it “is aware of the reported vulnerability and is actively investigating the validity and potential applicability of these claims.” That is the position of a vendor that has not yet decided whether it’s going to ship a fix, and the honest read is that defenders should assume nothing on the patch clock this week.

What the bug is

The vulnerability lives in the Windows User Profile Service and abuses the per-user classes registry hive — usrclass.dat, the file that backs HKCU\Software\Classes. Analyst Will Dormann summarized the mechanism plainly in the BleepingComputer writeup: “successful exploitation would allow non-admin users to modify the classes registry hive and gain automatic code execution when the admin account logs into a compromised system.”

That last clause is the whole game. This isn’t a straight-line escalation where the attacker’s process ends up running as SYSTEM the moment they run the exploit. It’s an ambush: the standard user rigs the hive, waits for an administrator to sign in on the same box, and then the admin’s own logon walks into code execution in the admin session’s context. On a workstation used only by one non-admin user that’s low value — but on a shared machine, an RDP jump box, a shared VDI image, or any endpoint where a helpdesk or endpoint-management account regularly logs on interactively, that pattern is exactly how a standard-user foothold becomes tenant admin overnight.

Nightmare Eclipse published the PoC with the mechanics deliberately clipped. Per their own note: “The PoC was stripped down as an attempt to prevent public exploitation, the original PoC did not require additional user credential.” Read straight, the public GitHub version needs standard-user creds on the target to fire; the internal version they held back did not. That’s a limited restraint — everyone with valid domain creds already meets the public-PoC bar, and someone with real motivation is going to reconstruct what was cut.

What’s not confirmed

• No CVE ID has been assigned. MSRC has not published an advisory, and NVD has nothing to point at.
• No confirmed exploitation in the wild. BleepingComputer’s writeup doesn’t cite any active-exploitation telemetry, and CISA has not added anything matching this pattern to KEV.
• Affected-version detail is thin. The disclosure describes “up-to-date Windows systems” without enumerating client vs. server SKUs or build numbers. Until Microsoft ships an advisory, treat every currently supported Windows build as in scope for planning purposes.

Anything past that in the next few days that isn’t traceable to MSRC, CISA, or the researcher’s own repo is speculation. Do not build detection or a comms narrative around it.

Priority order

There’s no patch to schedule. This one is a detection-and-blast-radius conversation, not a patch conversation.

1. Pull Kevin Beaumont’s Defender for Endpoint detection queries and get them running. Beaumont published queries specifically for this technique — hunt for standard-user processes writing to usrclass.dat in ways that don’t match normal COM/shell association changes, and for admin logons on hosts where the touched hive belongs to a non-admin user. If you don’t run Defender for Endpoint, port the intent to whatever EDR you do run: file writes to \Users\<non-admin>\AppData\Local\Microsoft\Windows\UsrClass.dat from processes that shouldn’t be touching it, followed by an admin-session logon on the same host, is the signature.
2. Cut interactive admin logons on shared endpoints. If a helpdesk account, a domain admin, or an endpoint-management account routinely logs in interactively on machines where standard users also sign in — RDP jump boxes, kiosks, VDI images, shared engineer workstations — that is the exact detonation surface this PoC needs. Rotate to remote-management tooling that doesn’t drop an interactive session on the endpoint, or restrict which endpoints those admin accounts are allowed to touch.
3. Assume Tier-0 hygiene is load-bearing until the patch lands. LAPS on local admin, no domain admin sessions on user endpoints, no shared service accounts running with more rights than they need. None of that is new advice — LegacyHive is the reminder that the boring version of privileged-access management is what actually catches this class of bug when the vendor timeline slips.
4. Track MSRC, not press coverage. The MSRC update guide is the source of record for when this gets a CVE and a build number. Everything else is downstream. When a CVE ID appears, come back and re-check whether your standing detection is looking at the right artifact — the fix may end up moving where the vulnerable code lives.

The honest timeline

• 2026-07-17 — Nightmare Eclipse publishes the PoC on GitHub and BleepingComputer reports it. Will Dormann and Kevin Beaumont provide analysis and detection guidance. Microsoft issues its “aware and investigating” statement.
• 2026-07-19 — No CVE assigned, no patch, no in-wild exploitation confirmed. Public PoC still requires standard-user credentials on the target.
• Whenever Microsoft decides — CVE, advisory, build number. Not this Patch Tuesday — the July drop already shipped last week.

An unpatched LPE with a public, credentialed PoC is not a five-alarm fire. It’s a working reminder that the shared-endpoint, interactive-admin-logon pattern is a standing tax on your privilege model, and every zero-day of this shape is going to keep charging it until you fix the pattern rather than the individual bug.