AI 1 - Humans 0

A few weeks ago the folks at calif.io started dropping a bunch of really cool writeups about vulnerabilities they found with the help of AI. Their latest one, Dark Elevator, is a beautiful Windows 11 LPE: a normal user gets an interactive NT AUTHORITY\SYSTEM shell, no admin, no UAC, no reboot, the full package. Microsoft fixed it on July 14th as CVE-2026-50343.

Now, huge respect, ’cause that’s a clean logic-flaw chain and a great read. But it also left me with that itchy feeling every offensive researcher knows… if the AI found one bug in that area, what else is lying around?

So I did what any reasonable person would do on a weekend, I opened a disassembler and went down the rabbit hole. Spoiler: I came back with my own ride to SYSTEM, on fully patched Windows 11 24H2 and 25H2. Same plantable DLL at the heart of it, completely different elevator.

This is the story.

Their bug, in 30 seconds

All credits to calif.io for the original find, but let me do a quick recap so we’re on the same page. Their exploit chained two logic flaws:

1. A writable plugin map. InstallService (the SYSTEM service behind app installs) picks a COM class to load by reading a registry key, StaticPluginMap, that any normal user can write. Write your own CLSID there and the SYSTEM service will CoCreateInstance whatever you point at.
2. A user-plantable COM server. Windows ships a CrossDevice streaming component, CLSID {E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}, whose InprocServer32 points to C:\ProgramData\CrossDevice\CrossDevice.Streaming.Source.dll. The registration lives in HKLM so you can’t touch it… but the DLL it points to doesn’t exist, and C:\ProgramData is a place where any standard user can create directories and files.

Plant the DLL, poke the service, and your code runs inside a SYSTEM svchost.exe. Elegant, deterministic, no memory corruption. Chef’s kiss 😀.

The real treasure was the DLL

Reading their post, the thing that kept my attention wasn’t InstallService, but that weird stale COM registration: a machine-wide HKLM registration, protected from modification, pointing to a file that doesn’t exist in a directory any user can create. If that’s not a bug, it’s at least a very generous gift.

Microsoft’s fix for CVE-2026-50343 took care of the InstallService side of the story. But that CrossDevice registration is still there, still pointing to a missing DLL in a path any user can create. Fully updated system, mind you.

So I asked myself, InstallService can’t be the only privileged process willing to load that class, right? Who else wants my DLL? I went hunting for another elevator.

Say cheese!

Turns out Windows has a whole infrastructure for virtual cameras (the thing apps use to expose fake webcams), and it comes with a public API, MFCreateVirtualCamera, that lets you create a camera backed by a COM class of your choice. Nice feature, eh? And guess which CLSID gets special treatment in there?

While reversing mfsensorgroup.dll something caught my attention 🥁 … a function called VerifyCOMServerByClsid, that compares the requested class against a small internal allowlist… and guess what, our beloved CrossDevice CLSID is on it. A matching class is accepted through a special-case path instead of getting the normal COM-server-path validation. The protected registration stays usable even though it resolves to an absent DLL in a user-creatable location. On the analyzed image (file version 10.0.26100.8737, SHA-256 F6C21838...5761671, for the nerds keeping score) the CrossDevice entry sits at 0x1800827F8.

At this point the plan writes itself:

MFCreateVirtualCamera(
    MFVirtualCameraType_SoftwareCameraSource,
    MFVirtualCameraLifetime_Session,
    MFVirtualCameraAccess_CurrentUser,
    L"CrossDevice",
    L"{E9F83CF2-E0C0-4CA7-AF01-E90C70BEF496}",
    nullptr,
    0,
    &camera);

Create the camera with the CrossDevice CLSID, call IMFVirtualCamera::Start, then GetMediaSource… and the Windows Frame Server - a service running as NT AUTHORITY\LOCAL SERVICE - happily loads your media source.

Now, LOCAL SERVICE is not SYSTEM, I know, but stay with me for a second.

The media source from hell

But of course there’s a catch, ’cause there’s always a catch. You can’t just drop a DLL with a class factory and call it a day: the Frame Server expects a functional Media Foundation source before it completes the activation path. Streams, descriptors, the whole ceremony.

So a good chunk of this project was writing a complete, valid IMFMediaSource implementation (SimpleMediaSource.cpp, SimpleMediaStream.cpp, friends…) just to convince the service to keep us around long enough to have fun. The final PoC embeds the whole DLL as an RCDATA resource inside a single exploit.exe, plants it with CREATE_NEW (it politely refuses to overwrite anything that isn’t its own), and activates the camera through a child process.

It’s potato time

And here’s why LOCAL SERVICE is more than enough: the Frame Server process token is unrestricted, not AppContainer, and has SeImpersonatePrivilege enabled. If you’ve been in the Windows trenches for a while, your mouth is already watering: that’s potato country.

The payload gates itself on the host identity (it only proceeds if the process token is S-1-5-19, LOCAL SERVICE), then runs the well-known EFSR coercion pattern - the same family as CoercedPotato:

1. Create a randomized named pipe, \\.\pipe\<UUID>\pipe\srvsvc.
2. Call EfsRpcOpenFileRaw over the local EFSR RPC endpoint (ncalrpc) with a path that resolves to our pipe.
3. The EFSR service connects to us. We call ImpersonateNamedPipeClient, open the thread token, and check it against WinLocalSystemSid.
4. Only if the captured token is verified as NT AUTHORITY\SYSTEM (S-1-5-18) do we continue - no blind trust, this is a civilized exploit.
5. DuplicateTokenEx to get a primary token, TokenSessionId to pin it to the active interactive session, winsta0\default, and CreateProcessAsUserW for good old cmd.exe.

And there it is, an interactive SYSTEM shell popping up in your own user session. No admin, no UAC, nothing.

The exposure

Standard user to SYSTEM, which means game over: bypass UAC and local ACLs, read other users’ data, install persistent privileged stuff, own the box. Suggested severity High, CVSS 3.1 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H).

Confirmed on fully serviced builds:

This is not a claim that every edition is affected: Windows 10, Home, Enterprise and 26H1 weren’t tested.

Worth noting: the CrossDevice/Media Foundation area already received security servicing (CVE-2025-24076, CVE-2026-21508), and calif.io’s path was fixed as CVE-2026-50343. This chain was reproduced on builds newer than all of those fixes. The primitive that refuses to die is the stale system-wide registration pointing to an absent file in a user-creatable C:\ProgramData subtree - plus a virtual-camera activation path that loads a valid attacker source into the privileged Frame Server.

Covering the lens

The root cause is really three trust decisions stacking up, and breaking any of them breaks the chain:

1. Remove the stale CrossDevice COM registration when the component isn’t installed.
2. Put required in-process servers in directories protected from standard-user creation and modification.
3. Reject virtual-camera media sources whose resolved COM server is missing, user-controlled, unsigned, or outside an approved protected location - no special-casing for the CrossDevice CLSID.
4. Stop loading untrusted media sources in processes that hold SeImpersonatePrivilege (a restricted host would have made the potato stage a lot harder).
5. When servicing, clean up vulnerable registrations on upgraded systems too, not just new installs.

Huge kudos to calif.io for the original Dark Elevator research and for sharing it, the best thing about this community is that one good writeup sparks the next one. The AI found its bug, I found mine with a mix of old-fashioned work and agentic research, staring at a disassembler until the bytes confessed (ok, mostly the old-fashioned way).

Have fun and happy hacking!