CVE-2026-20817 is a local elevation-of-privilege vulnerability (CWE-280, Improper Handling of Insufficient Permissions or Privileges) in the Windows Error Reporting service (wersvc.dll / WerSvc), rated CVSS 3.1 7.8 HIGH (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). WerSvc runs as NT AUTHORITY\SYSTEM and exposes an ALPC server at \WindowsErrorReportingServicePort. An ALPC thread dispatches client requests through a generic _ProcessRequest handler into DispatchPortRequestWorkItem, which can route to the SvcElevatedLaunch method. SvcElevatedLaunch opens the calling client's process and invokes an internal ElevatedProcessStart routine, passing a reference to a File Mapping object supplied by the (unprivileged) caller. The vulnerable ALPC message format requires MessageFlags (offset 0x28) equal to 0x50000000, an unknown field (offset 0x30) set to 1, a FileMapping handle (offset 0x38), an optional SourceHandles array of up to 16 client handles (offset 0x40), a CopySourceHandles flag (offset 0xc0), and a NewProcessHandle output field (offset 0xc8), for a total structure size of 0x578 bytes. Because the service never verifies that the caller is authorized to request an elevated launch, and reads the command line to pass to WerFault.exe directly out of the attacker-controlled shared-memory File Mapping, a standard user can dictate the command-line arguments WerFault.exe (C:\Windows\System32\WerFault.exe) receives when it is created under a SYSTEM-derived token via CreateProcessAsUserW. The resulting token retains powerful privileges (per secondary reporting: SeDebugPrivilege, SeImpersonatePrivilege, SeBackupPrivilege) while lacking SeTcbPrivilege. WerSvc also sets the calling process's PID as the parent of the newly created WerFault.exe instance (parent-PID spoofing), which Microsoft Defender flags as suspicious behavior when observed. The public PoC (github.com/itm4n/CVEs/tree/master/CVE-2026-20817, authored by itm4n/Clément Labro, published 2026-03-22 and updated 2026-03-28) demonstrates controlled WerFault.exe argument injection as SYSTEM but explicitly states that converting this into arbitrary code execution requires additional work; the WER service must be running and the exploit assumes the default ALPC port name. An earlier, independently authored PoC by GitHub user oxfemale (@bytecodevm) was covered by cyberpress.org on 2026-03-02, roughly three weeks before itm4n's detailed write-up, and was validated against Windows 11 23H2. The vulnerability was originally discovered and reported to Microsoft by Denis Faiustov and Ruslan Sayfiev of GMO Cybersecurity, and fixed in Microsoft's January 2026 Patch Tuesday release (NVD published 2026-01-13) across Windows 10 21H2/22H2, Windows 11 23H2/24H2/25H2, and Windows Server 2022/2022 23H2/2025. Microsoft's remediation does not add a permission/ACL check to the ALPC handler; instead it introduces a __private_IsEnabled() feature-flag test at the top of SvcElevatedLaunch that unconditionally fails the call with 0x80004005, effectively dead-coding the elevated-launch feature rather than repairing it. CVE-2026-20817 is not listed in the CISA Known Exploited Vulnerabilities catalog and carries a low EPSS score (0.055, 92.3rd percentile) as of research time, indicating no confirmed in-the-wild exploitation despite the public PoC code. itm4n's function-level reverse engineering traces the call chain as _ProcessRequest -> DispatchPortRequestWorkItem -> SvcElevatedLaunch -> OpenSenderProcessThread -> ElevatedProcessStart -> CreateElevatedProcessAsUser -> CreateProcessAsUserW, with the low-privilege client connecting via the undocumented native APIs NtAlpcConnectPort and NtAlpcSendWaitReceivePort and the service using DuplicateHandle and MapViewOfFile to pull the attacker's arguments out of the caller-supplied File Mapping (shared-memory, never written to disk) before minting the SYSTEM token. The default port name can be overridden via the ErrorPort value under HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting, which the PoC assumes is unset. Within WerSvc's ALPC dispatch table, SvcElevatedLaunch is invoked as method index 0x0D; the shared-memory command-line buffer supplied via the File Mapping object is capped at roughly 520 bytes. WerFault.exe's own executable path is hardened against tampering (resolved via GetSystemDirectoryW rather than taken from attacker input), so only its command-line arguments are attacker-controlled, not the binary invoked. Per secondary technical reporting, the SYSTEM token minted for the child process is produced by an internal UserTokenUtility::GetProcessToken routine and passed through CreateRestrictedToken, which strips only SeTcbPrivilege while leaving SeDebugPrivilege and SeImpersonatePrivilege intact - consistent with itm4n's own observation that the resulting token lacks SeTcbPrivilege but retains powerful impersonation/debug rights. itm4n's write-up points to related Windows internals research - James Forshaw's work on GetProcessHandleFromHwnd, used to obtain a process handle from a window handle to bypass Protected Process Light restrictions on WerFaultSecure.exe - as a plausible avenue for turning the controlled WerFault.exe launch into full code execution, though no such follow-on exploit chain has been publicly demonstrated for CVE-2026-20817 specifically. Following disclosure, gbhackers.com reported that fake and potentially malicious PoC repositories mimicking itm4n's legitimate exploit began circulating on GitHub, and cautioned administrators to verify PoC provenance before downloading or executing any CVE-2026-20817 exploit code.