CVE-2026-32158

What it actually does

This is a local elevation-of-privilege vulnerability in the Windows Push Notifications component caused by improper synchronization around a shared resource. A low-privileged, authenticated local attacker who can run code on an affected Windows client or server may be able to trigger a race condition and cause privileged Windows Push Notifications logic to operate on attacker-influenced state. Successful exploitation can cross a privilege boundary and provide high-impact confidentiality, integrity, and availability consequences on the local system.

Why it matters to the business

If exploited after an attacker has already obtained low-privileged access to a Windows system, this flaw could allow them to gain broader control of that device, disable security controls, access sensitive local data, install persistence, or move further into the environment. The CVSS score is high, but current public exploitation signals are low: EPSS is 0.002 and flat over 30 days, it is not listed in CISA KEV, and no mature public exploit is indicated. Because the affected products include widely deployed Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 versions, organizations should still remediate through normal Windows security patch cycles, prioritizing shared servers, administrator workstations, jump hosts, and internet-exposed systems where local compromise could have outsized impact.

How an attack unfolds

An attacker must first have authenticated local access to an affected Windows system, typically through stolen credentials, malware execution, phishing-enabled code execution, abuse of remote management access, or compromise of a low-privileged account. The attacker then runs a local program that repeatedly interacts with the Windows Push Notifications component to create a timing window around a shared resource. By winning the race, the attacker attempts to make privileged notification-related code use inconsistent or attacker-controlled state. If successful, the attacker elevates from a low-privileged context to a more privileged local security context, after which they can perform post-exploitation actions such as credential access, defense evasion, persistence, tampering with system configuration, or lateral movement. Exploitation is local and high-complexity, so it is most relevant as a second-stage privilege escalation after initial access rather than as an initial remote compromise vector.

How to fix it

Apply the applicable Microsoft security update or cumulative update for all affected Windows versions, including Windows 10 1809, 21H2, and 22H2; Windows 11 23H2, 24H2, 25H2, and 26H1; Windows Server 2019; Windows Server 2022 including 23H2; and Windows Server 2025. No exact fixed build or KB was provided in the input, so use Microsoft’s official CVE guidance, Windows Update, WSUS, Microsoft Update Catalog, or enterprise patch tooling to identify the corresponding fixed cumulative update for each OS release. Where immediate patching is not possible, reduce exposure by limiting local logon rights, restricting interactive access to servers, enforcing least privilege, preventing untrusted code execution through application control, keeping EDR active, and monitoring for suspicious local privilege escalation behavior. Because this is a local authenticated flaw, compensating controls should focus on preventing initial code execution and limiting what low-privileged users can run locally.

How to confirm the fix worked

Confirm each affected system has received the Microsoft security update that supersedes or fixes this vulnerability for its Windows release. Use enterprise patch management reporting, Windows Update compliance data, Microsoft Defender Vulnerability Management, WSUS/SCCM/Intune compliance status, or host-level checks such as installed cumulative update history and OS build comparison against Microsoft’s fixed-build guidance. Validate that vulnerable Windows 10, Windows 11, Windows Server 2019, Windows Server 2022, and Windows Server 2025 assets are no longer reporting as exposed. For mitigation validation, confirm that non-administrative users cannot interactively log on to servers unless required, application control policies block unapproved binaries, and endpoint security telemetry remains enabled. Because race-condition privilege escalation may leave limited direct evidence, absence of a crash or alert should not be treated as proof of non-exploitation.

Typical attack path

1. Obtain low-privileged authenticated access to an affected Windows workstation or server.
2. Confirm the target is running a vulnerable Windows version and that the Windows Push Notifications component is present.
3. Execute a local exploit program designed to trigger repeated concurrent operations against the vulnerable shared resource.
4. Win the race condition so privileged Windows Push Notifications code acts on inconsistent or attacker-influenced state.
5. Gain elevated local privileges or execute actions in a higher-privileged context.
6. Use elevated access to disable protections, dump credentials, install persistence, alter system settings, or support lateral movement.

How to detect it

There are no reliable public, vulnerability-specific indicators of compromise for this race-condition privilege escalation, and successful exploitation may not produce a unique log entry. Detection should focus on evidence of local privilege escalation and follow-on activity. Review Windows Security logs for unusual privilege use, new logons with elevated tokens, unexpected local administrator group changes, new services, scheduled tasks, process creation anomalies, and security control tampering. Useful sources include Windows Security Event Log, Sysmon or EDR process telemetry, Microsoft Defender alerts, Windows Push Notifications operational logs if enabled, service control manager events, PowerShell logs, and endpoint file/process artifacts. Look for low-privileged users spawning administrative shells, credential access tools, unsigned binaries executing from user-writable directories, abrupt crashes or restarts of notification-related components followed by elevated activity, and new persistence mechanisms created shortly after suspicious local execution. Since this CVE is not in CISA KEV, has no reported ransomware use, and has low flat EPSS at the time of input, prioritize retrospective hunts on high-value systems and any hosts that also show initial access indicators rather than broad emergency compromise assumptions.

What your security team should do

• Inventory affected Windows client and server versions and map them to the appropriate Microsoft cumulative updates.
• Prioritize patching administrator workstations, jump hosts, domain administration endpoints, shared servers, VDI/golden images, and systems that process sensitive data.
• Deploy the relevant Windows security updates through standard patch channels and verify compliance with build-level or KB-level reporting.
• Harden local access by reducing interactive logon rights, removing unnecessary local administrator privileges, and enforcing least privilege.
• Use application control or allowlisting to prevent untrusted local exploit binaries from running on endpoints and servers.
• Monitor for suspicious post-exploitation activity following possible local privilege escalation, including new services, scheduled tasks, credential dumping tools, security control tampering, and unusual child processes from system services.
• Treat this primarily as a post-compromise privilege escalation risk: pair remediation with controls that reduce phishing, malware execution, stolen credential use, and unmanaged remote access.
• Track Microsoft advisory updates for fixed build numbers, supersedence information, and any change in exploit maturity or known exploitation status.