Kaspersky researcher Haidar Kabibo walked onto the Black Hat Asia 2026 stage on April 24 and detailed an architectural defect in Windows Remote Procedure Call that has been sitting in rpcrt4.dll for the better part of two decades. He calls it PhantomRPC. It is not a memory corruption bug, nor a logic error in a single service — it is a property of how the Windows Endpoint Mapper has always resolved RPC server endpoints, and it gives an unprivileged local attacker a reliable path to SYSTEM on every supported build of Windows, from Windows 10 through Windows 11 24H2 and the current Windows Server line. Kaspersky reported it to MSRC on September 19, 2025; Microsoft answered twenty days later, classified it as moderate severity, declined to assign a CVE, and closed the ticket. Seven months later it is still unpatched, and proof-of-concept tooling is now public.

What the bug actually is

When a privileged process — a service running as SYSTEM, say, or a user-mode component running under NT AUTHORITY\NETWORK SERVICE — needs to talk to another RPC server, it asks the Endpoint Mapper (EPM, the RpcEpResolveBinding family) for a binding handle to a given interface UUID. The EPM looks up endpoints registered against that UUID and hands one back; the RPC runtime then opens a transport, performs the call, and trusts whatever the server on the other end returns.

Two facts make that trust dangerous. First, the EPM returns the most recently registered endpoint for a given UUID, with no notion of which process is allowed to claim that interface. Second, rpcrt4.dll exposes no mechanism for a client to verify that the server it is talking to is the legitimate owner of the interface — there is no SDDL on the binding, no SID check on the peer, no signed-endpoint negotiation. If an attacker-controlled process registers a rogue server with the same interface UUID as, for example, the Terminal Services service, and the real TermService is stopped or disabled, the EPM will route the next caller to the rogue endpoint. The rogue server then calls RpcImpersonateClient, picks up the caller’s token, and the privileged client has handed its identity to an attacker.

The five paths

Kabibo’s paper details five distinct chains, each ending at SYSTEM or Administrator:

  1. gpupdate /force → Group Policy Client (SYSTEM) → TermService. Trigger a policy refresh, intercept the Group Policy Client’s RPC call to a stopped TermService, impersonate. SYSTEM in one hop.
  2. Microsoft Edge startup → TermService. Edge launches an RPC call to TermService at high impersonation level; a low-priv attacker waiting on a spoofed endpoint goes from NETWORK SERVICE to Administrator.
  3. WinRM client → privileged remote management interfaces. The WinRM stack does not validate the local RPC peer during certain bootstrap paths.
  4. Background Intelligent Transfer Service (BITS). A SYSTEM caller that hits a disabled subordinate service is hijackable in the same pattern.
  5. A scheduled-task race involving the Schedule service that lands in a SYSTEM context on every build Kaspersky tested.

The common ingredient is a disabled or not-yet-started target service. Default Windows installations have plenty: TermService is disabled on hardened workstation images and Server Core; many BITS-adjacent services start manually.

Impact

Anywhere you have local code execution at any privilege — a compromised service account, a phished user, a browser sandbox escape, a foothold from a different bug — PhantomRPC promotes it to SYSTEM. That includes domain-joined workstations, jump hosts, build agents, RDS session hosts, and Server Core nodes used as bastion or AD infrastructure. The architectural nature of the flaw means it is not patchable by upgrading a single component; the EPM contract itself would have to change.

What you can do right now

Microsoft has shipped no fix and Kaspersky does not expect one soon, so detection is the lever. Kabibo’s recommendation is ETW-based monitoring of RPC client exceptions — the exception path that fires when an RPC client connects to an endpoint whose UUID resolves but whose owning service is not actually the registered service binary. The PhantomRPC research repository on GitHub ships an audit harness defensive teams can run across a representative sample of hosts to enumerate which privileged callers are reachable on their fleet.

Beyond detection, harden by stopping the bleed: avoid leaving sensitive RPC services in Disabled state on internet-facing or multi-tenant boxes (paradoxical but real — a disabled service is the hijackable one), restrict who can register RPC endpoints via Restrict-RPC-Clients group policies where applicable, and audit any SYSTEM-impersonating service you operate for whether it is hardcoded to talk to a service that ships disabled.

Reading

Securelist, Disclosing PhantomRPC – a privilege escalation vulnerability in RPC, https://securelist.com/phantomrpc-rpc-vulnerability/119428/. Kaspersky press release on the Black Hat Asia 2026 disclosure. Cyber Security News, New Windows RPC Vulnerability Lets Attackers Escalate Privileges Across All Windows Versions, https://cybersecuritynews.com/new-windows-rpc-vulnerability/.