Windows Push Notifications EUVD-2026-35738

Attacker must already have an authenticated local session on the target Windows host with at least standard user privileges (PR:L) and the ability to execute code locally (AV:L); no user interaction from another account is required (UI:N). Exploitation is gated by AC:H, meaning the attacker must reliably win a timing window in the Push Notifications service - typically requiring multiple CPU cores, tight loops, and tolerance for repeated failed attempts - and the WpnService / WpnUserService must be running and reachable, which is the default on standard Windows installations. The Scope:Changed component indicates the attacker crosses from their own security context into the privileged service context. Remote-only attackers, fully unauthenticated attackers, and hosts where the Push Notifications service is disabled are not in scope.

Risk is moderate-to-high for endpoints where untrusted users have local sessions. CVSS 7.8 with AV:L/PR:L places this firmly in the local privilege escalation category - not an internet-exposed RCE, but a strong post-compromise primitive useful after phishing or initial foothold. AC:H reflects the inherent unreliability of race conditions, which typically require repeated attempts and specific scheduling conditions, lowering exploitability in practice. EPSS data was not provided in the input, and the vulnerability is not listed in CISA KEV, so there is no current evidence of active exploitation; no public exploit identified at time of analysis. Microsoft race-condition LPEs in notification and brokering services have historically been incorporated into commodity toolkits weeks-to-months after patch release, so prioritize for next Patch Tuesday cycle on multi-user, kiosk, and VDI hosts where local users are untrusted.

An attacker who has already obtained a low-privileged local shell on a Windows host - for example via a phishing payload or a compromised standard-user account - runs a small tool that repeatedly invokes the Push Notifications IPC interface while concurrently manipulating a shared resource the service operates on. After many timing-sensitive iterations, the attacker wins the race and causes the privileged service to act on attacker-controlled data, yielding code execution or token manipulation across a security boundary and effective SYSTEM-level control. No public exploit identified at time of analysis, but race-condition LPEs in similar Windows brokering services have historically been productized quickly once patches are reverse-engineered.