2026-08-12 · view entry permalink →
UPDATE — the LegacyHive profile-hijack technique reported here as having no Microsoft fix now has one: CVE-2026-62832, patched 11 August, publicly disclosed and rated 'Exploitation More Likely'
UPDATE · originally covered LegacyHive: a public Windows technique that redirects a profile's Local AppData into the NT Object Manager namespace via offline hive edits, reproduced on fully patched systems (2026-07-29)
the entry on LegacyHive — the Nightmare Eclipse Windows proof-of-concept that LevelBlue reproduced on a fully patched July-2026 build — recorded that the vendor offered no mitigation for that class of abuse. Microsoft's August Patch Tuesday appears to have closed it. CVE-2026-62832 is described in Microsoft's own record as "Improper link resolution before file access ('link following') in Windows User Profile Service allows an authorized attacker to elevate privileges locally", scored CVSS 3.1 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H), rated Important, recorded as publicly disclosed before the fix, not exploited, and assessed as "Exploitation More Likely" (MSRC, 2026-08-11).
Microsoft does not name LegacyHive, and the identification is worth attributing precisely rather than assuming. Rapid7 states that between the public disclosure and the advisory FAQ — which describes an authenticated attacker who has credentials for another account and loads another user's registry hive — "the advisory is a solid match for Nightmare Eclipse's description of LegacyHive" (Rapid7, 2026-08-11). That is an assessment by a third party, not a vendor mapping, which is why this entry carries it as such.
The independent detail that makes the match credible comes from the unofficial patch that preceded the official one. 0patch analysed the flaw in July and describes it in the same terms: the vulnerability lies in the Windows User Profile Service, where a time-of-check-to-time-of-use condition lets a local attacker use a symbolic link to confuse the service into loading any user's registry hive instead of the requesting user's, ending up mounted in the attacker's own registry space with read/write permissions. Its root cause, per 0patch, is an access-check fallback: when the service can open the hive file with full access it mounts it under the requesting user's identity using NtLoadKey3, which supports impersonation, but when it cannot, it falls back to the older NtLoadKeyEx without impersonation — so the hive loads with full access as Local System. The consequence 0patch names is the same one the original entry described from the attacker's side: read the target user's stored secrets, or replace paths to trusted executables and DLLs so they run the next time that user logs in (0patch, 2026-07-20).
For anyone who acted on the July coverage, the practical delta is short. The prerequisite is unchanged and still limits the blast radius — the attacker needs a local session plus credentials for a separate account, so this is a post-compromise escalation step rather than an entry point. The August cumulative update supersedes the 0patch micropatch as the remediation, and estates that deployed the community patch were covered in the interval. No action item ships with this entry: the fix arrives inside the ordinary Patch Tuesday cycle, and the entry exists to correct the record on the earlier "no fix available" framing rather than to open new work.
Improper link resolution before file access ('link following') in Windows User Profile Service allows an authorized attacker to elevate privileges locally.
the advisory is a solid match for Nightmare Eclipse’s description of LegacyHive