CVE-2026-66804: Fifteen Researchers Found What Microsoft’s Dark Elevator Patch Missed

The claim on the table is simple: Microsoft patched Dark Elevator (CVE-2026-50343), so that class of SYSTEM-escalation is dealt with. Project Zero’s new write-up on CVE-2026-66804 says otherwise — the fix was incomplete. Let’s pressure-test what “incomplete” actually means here, because “just patch again” is correct advice that teaches you nothing.

What does a “dangling COM object” even give an attacker?

Think of COM’s registry as the company phone directory. When a privileged Windows process needs a component, it doesn’t go find the binary itself. It looks up a CLSID — a GUID — in the directory and dials whatever extension is listed. The directory says call this DLL or launch this executable, and the process trusts the entry.

A dangling registration is a directory entry that still exists but points somewhere stale — or somewhere a low-privilege user can influence. If an unprivileged user can register or shadow a CLSID that a SYSTEM-level process later looks up, the user’s code answers the phone. The SYSTEM process runs it. That’s the whole trick: you don’t break the lock, you get the trusted caller to dial your number.

So why did the first fix fail?

Dark Elevator’s original patch closed a specific path — one way a stale registration could be resolved and trusted. What it didn’t do was stop Windows from trusting the pattern: user-writable registration locations shadowing machine-wide ones, and privileged lookups that don’t re-validate who owns the entry. Fix the doorway, leave the trust model. Project Zero found another lookup context that still honours the stale entry. Same root cause, different route to it.

That’s the detail IT leadership keeps missing when a CVE spawns a sequel. An incomplete fix usually means the patch addressed an instance rather than the class. And when 15 researchers independently reported this, that’s your signal: the window is sitting at eye level, not hidden in the attic.

Which versions, and how fast?

I’m not going to invent a build table. Affected versions and patch KBs live on the MSRC update guide for CVE-2026-66804 — treat that page as authoritative and map it against your actual estate, not your assumptions about it.

Urgency: immediate. Not because of confirmed in-the-wild exploitation — Project Zero disclosed this, and I’ve seen no credible ITW evidence as of this writing — but because the technique is now publicly documented, the primitive is a reliable local-privilege escalation, and 15 teams finding it independently means working code will not be scarce for long. This is the back half of a ransomware or post-phishing chain, not the front door. Patch it before it’s the quiet step nobody logged.

What can you check today?

Before patch windows line up, find your exposure. Per-user COM registrations shadowing machine-wide CLSIDs, pointing at user-writable paths, are the shape worth flagging. This is a starting pattern, not an exhaustive detector — it reports, it changes nothing.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

# DRY RUN - enumerates per-user COM registrations that shadow
# HKLM CLSIDs and resolve to user-writable paths. Reports only.
$userWritable = '\\AppData\\','\\Temp\\','\\Users\\','\\Downloads\\'
$hkcu = 'Registry::HKEY_CURRENT_USER\Software\Classes\CLSID'
​
Get-ChildItem $hkcu -ErrorAction SilentlyContinue | ForEach-Object {
    $clsid = $_.PSChildName
    foreach ($srv in 'InprocServer32','LocalServer32') {
        $path = (Get-ItemProperty "$($_.PSPath)\$srv" -ErrorAction SilentlyContinue).'(default)'
        if (-not $path) { continue }
​
        $shadowsMachine = Test-Path "Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\$clsid"
        $looksWritable  = $userWritable | Where-Object { $path -match [regex]::Escape($_) }
​
        if ($shadowsMachine -or $looksWritable) {
            [pscustomobject]@{
                CLSID          = $clsid
                Server         = $srv
                Path           = $path
                ShadowsMachine = [bool]$shadowsMachine
                UserWritable   = [bool]$looksWritable
            }
        }
    }
} | Format-Table -AutoSize

On the Defender side, hunt for SYSTEM-context processes spawning children from user profile paths — the moment the trusted caller dials the attacker’s extension.

1
2
3
4
5

DeviceProcessEvents
| where InitiatingProcessAccountName in~ ("system","local service","network service")
| where FolderPath has_any ("\\AppData\\","\\Temp\\","\\Users\\")
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, FolderPath
| order by Timestamp desc

The verdict

“Microsoft patched Dark Elevator” was true and useless. What they patched was one lookup path; what they left standing was a trust model that still believes user-writable COM registrations when a privileged process goes looking. The real remediation is layered: apply the CVE-2026-66804 update from MSRC this cycle, strip local-admin rights so the escalation has somewhere worse to climb from, and run WDAC or AppLocker so an unexpected binary answering a SYSTEM lookup gets denied regardless of what the directory says.

A sequel CVE isn’t Microsoft being lazy. It’s the difference between patching a bug and patching a pattern. Watch the next few months — I’d put money on a CVE-2026-66804 Part Two before I’d bet the class is closed.