Windows Cross Device Service, dangling COM registration reaches SYSTEM privesc (Google Project Zero)

CVE-2026-66804, Windows Cross Device Service: a dangling COM registration reaches SYSTEM privilege escalation, and Google Project Zero publishes a general method to hunt for others

Google Project Zero researcher James Forshaw published a working local-privilege-escalation exploit on 2026-09-21 for CVE-2026-66804, "Windows Cross Device Service Elevation of Privilege Vulnerability" (CVSS 7.8, fixed in Microsoft's August 2026 Patch Tuesday on 2026-08-11; Microsoft rates it "Exploitation More Likely" with no observed in-the-wild exploitation) (Google Project Zero, 2026-09-21; Microsoft Security Response Center, 2026-08-11). The bug is an incomplete fix of an earlier flaw, CVE-2026-50343 ("Dark Elevator," disclosed by the security research team Calif and fixed 2026-07-14 (Microsoft Security Response Center, 2026-07-14; Calif)): a COM object registration for the "CrossDevice" class, CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}, is registered machine-wide under the classes root but points to a server DLL, %ProgramData%\CrossDevice\CrossDevice.Streaming.Source.dll, that does not exist, and %ProgramData% is writable by any local, unprivileged user, who can plant an arbitrary malicious DLL at that exact path ("this object was registered in the system wide classes key, meaning it was accessible to all users on the system, including system services. However the server executable was missing", Google Project Zero, 2026-09-21). Microsoft's July fix closed the original exploitation route (weak registry permissions letting the class be registered as an installer plugin loaded by InstallService) without removing the dangling registration itself, leaving it exploitable by a different route.

Forshaw supplies that route: COM's opt-in custom-marshaling mechanism lets an object specify an arbitrary class id for server-side unmarshaling, so sending a custom object reference naming the dangling class id to a SYSTEM-context COM server that has not enabled the corresponding unmarshaling-policy protections causes the runtime to load the attacker's planted DLL into that privileged process automatically, before any target method is even called (Google Project Zero, 2026-09-21). He identifies the "Shell Create Object Handler" COM service, hosted in a SYSTEM-context process, as one exploitable target: it is not directly instantiable through the normal COM activation API but is started by any authenticated local user via a scheduled task under the Windows Shell task path, and its sole custom interface accepts a parameter the attacker fills with the fake-marshaled dangling-class object, yielding SYSTEM code execution (Google Project Zero, 2026-09-21). Forshaw also publishes a general PowerShell method, built on his own OleViewDotNet and NtObjectManager tooling, that enumerates every in-process COM class registered in the machine hive whose server DLL path cannot actually be resolved, a reusable technique for finding other, still-undiscovered dangling COM registrations on any Windows estate, independent of this specific CVE.