LegacyHive: An Unpatched Windows Zero-Day With No CVE and a Public PoC

Share
LegacyHive: An Unpatched Windows Zero-Day With No CVE and a Public PoC
The Windows User Profile Service loading another user's registry hive into an attacker's session.

Hours after Microsoft's July 2026 Patch Tuesday shipped fixes for over 600 CVEs, the researcher known as Nightmare Eclipse (also Chaotic Eclipse) dropped another one that wasn't in it. LegacyHive is a local privilege escalation in the Windows User Profile Service (ProfSvc) that works on fully patched Windows 10, 11, and Server 2016/2019/2022. It has no CVE ID, no Microsoft advisory, and no patch.

It's also less devastating than the headlines suggest, and the reasons why are worth understanding, along with the part of this story that should actually bother you: Microsoft appears to have fixed this exact class of bug eleven years ago.

What It Actually Does

ProfSvc is the core service that loads a user's settings, environment, and registry hive at sign-in. LegacyHive abuses a timing/path-switching flaw to make it mount another user's registry hive under the attacker's own profile, potentially an administrator's.

In Nightmare Eclipse's own description of the published PoC: it requires credentials for a second standard user plus a third username (which can be an administrator account), and on success it mounts the target user's hive in the current user's classes root.

Will Dormann, principal vulnerability analyst at Tharros, tested it and demonstrated the practical impact: a non-admin user can modify the classes registry hive and get automatic code execution when the admin logs in. His demo associated .txt files with calc.exe as a novelty, while noting that anyone with real intent would find far more interesting things to do with the primitive, including things needing no user interaction at all. Kevin Beaumont confirmed the exploit works and published detection queries for Microsoft Defender for Endpoint.

The Severity Nuance Everyone's Skipping

⚠️ Read the actual scope before you panic. The published PoC mounts the target's UsrClass.dat hive with read access. As ThreatLocker's analysis points out, that hive contains application data, Explorer history, and forensic artifacts. It does not contain password hashes or anything directly abusable as credentials.

So the public exploit, as shipped, is an information-disclosure and persistence primitive, not an instant SYSTEM shell. The Register put it bluntly: it isn't the "bone-shattering" drop that was promised in June.

The catch is what's not published. Nightmare Eclipse states the original PoC required no additional credentials and wasn't limited to usrclass.dat, any hive could be loaded, in the researcher's words "you would need some brain cells to make the PoC do it." That's the researcher deliberately stripping the release to slow weaponization, which is a notable break from their earlier drops.

⚠️ Don't take comfort in that. The vulnerability underneath is the arbitrary-hive-load primitive; what's public is a hobbled demonstration of it. Precedent matters here: BleepingComputer and others note that earlier drops from this researcher, BlueHammer (CVE-2026-33825) and RedSun (CVE-2026-41091), went from PoC to widespread exploitation within days, and CISA added several to its Known Exploited Vulnerabilities catalog. The stripping buys time, not safety.

The Part That Should Bother You: 2015 Called

Here's the detail that makes this more than another drop in the pile. Microsoft patched a broad ProfSvc trust-boundary failure back in 2015 as CVE-2015-0004, a vulnerability that also loaded another user's hive.

Eleven years later, the same component, the same trust boundary, the same class of failure. Whether that's an incomplete original fix, a regression, or a genuinely distinct path to the same broken assumption, the pattern is the thing worth noting.

⚠️ And it's a pattern in this researcher's disclosures specifically. MiniPlasma was the same story with a 2020 patch that apparently never took. This is the Windows equivalent of the page-cache COW family on Linux, where one disclosure draws researchers to adjacent code and the "fixed" boundary turns out to have several more doors in it. A fix that addresses one path through a broken trust boundary, rather than the boundary itself, doesn't close the class. It just makes the next variant take a few years.

Detection: Absence of Evidence Isn't Evidence of Absence

⚠️ This is the most operationally important part, and it's from ThreatLocker's analysis rather than the news coverage. The PoC deliberately restores the original hive and deletes its temporary artifacts during cleanup. A clean-looking system after execution does not mean it never ran.

That kills the naive detection approach. What to watch instead:

  • A standard-user process writing to another user's hive. That's the anomaly, and it has no legitimate explanation.
  • Any process other than normal Windows profile components replacing ntuser.dat.
  • Suspicious activity on C:\Users\*\ntuser.dat and C:\Users\*\AppData\Local\Microsoft\Windows\UsrClass.dat.
  • Unexpected hive loads under user classes roots.

The signal is correlation across a short time window, several of these events together from the same process, rather than any single one in isolation. That's the same behavioral-detection principle that works on the Linux side: monitor what processes do, not what files they leave behind, because a competent exploit cleans up after itself and a file-integrity check comes back green.

If you run Defender for Endpoint, Beaumont's KQL hunting queries are the fastest path to coverage.

Mitigations Until There's a Patch

There's no fix, so this is interim control territory:

  1. Limit who can create local standard-user accounts. The published PoC needs a second set of standard-user credentials. That requirement is your friend, so don't erode it by letting arbitrary users provision accounts.
  2. Restrict local access to trusted users. This is an LPE, not a remote exploit. It requires code execution as a standard user first, which means it's a post-compromise escalation tool, useful to an attacker already inside, not a path in from the internet.
  3. Watch the hive paths listed above, with alerting on the standard-user-writes-to-another-user's-hive pattern.
  4. Validate the PoC only in isolated, authorized test environments. Obvious, but worth stating.
  5. Track Microsoft's response and apply the fix when it lands. Given the researcher's history, that may be next Patch Tuesday or it may not.

⚠️ Priority calibration: because this needs local code execution plus a second credential set, it's not a drop-everything item for most environments. It's a real concern for multi-user systems, shared workstations, terminal servers, and any environment where standard users are plentiful and not fully trusted. If your Windows estate is single-user laptops, the exposure is limited. If you run RDS or shared machines, this is the profile it was built for.

The Disclosure Fight in the Background

Worth understanding the context, because it explains why there's no CVE and no coordinated fix. Since April, Nightmare Eclipse has published Windows zero-days without coordinating with Microsoft, arguing prior reports were mishandled. The tally now runs to more than half a dozen: RoguePlanet, BlueHammer, RedSun, YellowKey, GreenPlasma, MiniPlasma, UnDefend (CVE-2026-45498), and GreatXML. Microsoft has patched several (GreenPlasma, MiniPlasma, and YellowKey in June; RoguePlanet in July), disabled the researcher's accounts, and issued warnings about legal action against "malicious activity causing real harm to our customers," which several security researchers read as a direct threat to the discloser.

I'm not going to adjudicate that dispute. The operational reality is what matters: uncoordinated disclosure means defenders get the exploit and the vendor fix on different timelines, and right now you have the former without the latter. Whatever you think of the ethics, plan for that gap, because this researcher has shown no sign of changing approach.

Bottom Line

LegacyHive is a real unpatched ProfSvc privilege escalation on fully patched Windows, with a deliberately weakened public PoC that reads another user's UsrClass.dat rather than handing over SYSTEM. That makes it a post-compromise tool for multi-user environments rather than an emergency for everyone. But the underlying primitive is arbitrary hive loading, the researcher says the unstripped version needs no extra credentials, and their previous drops went from PoC to in-the-wild exploitation in days. Restrict local account creation, watch for standard-user writes to other users' hives, remember that the exploit cleans up after itself so a clean system proves nothing, and don't read the eleven-year gap since CVE-2015-0004 as reassurance. Trust boundaries that get patched one path at a time keep coming back.


References