CVE-2024-26169 – Windows Error Reporting Service Privilege Escalation

What is CVE-2024-26169?

CVE-2024-26169 is a security flaw in the Microsoft Windows Error Reporting (WER) service. The service, which collects crash data and sends it to Microsoft, mishandles privilege checks. A user‑level account can trick the service into performing actions as the SYSTEM account – the most powerful account on a Windows host.

Related remediation guides

Other vulnerabilities in the same family or affecting the same products:

• CVE-2024-49039 – Windows Task Scheduler privilege escalation fix guide
• CVE-2021-43226 – Windows CLFS Driver Privilege Escalation – What You Need to Do
• CVE-2025-29824 – Windows CLFS driver privilege‑escalation – what you need to know

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

Who needs to care?

Anyone who runs a supported version of Windows – desktop, laptop, or server – should be aware. The vulnerability has a CVSS score of 7.8, placing it solidly in the high severity band. It has been confirmed in the wild and is already being used by ransomware operators. If you manage Windows machines, you are in the audience.

How does the flaw work?

The Windows Error Reporting service runs under SYSTEM privileges. When a crash occurs, the service spawns a helper process that reads information from the user’s session and then writes a report to a protected location. The vulnerability lies in the way the service validates the caller’s rights before performing the write. An attacker with a normal user account can craft a request that bypasses the check, causing the service to execute code with SYSTEM rights.

The exact exploitation technique is not fully disclosed in public advisories, but the classification is an “improper privilege management” bug. In practice, this means the attacker does not need any special kernel exploits – a simple local program is enough to gain full control of the machine.

Why is this serious?

Gaining SYSTEM privileges is the equivalent of handing a thief the master key to your house. With that level of access, malware can disable security tools, install persistence mechanisms, and encrypt data. The fact that ransomware groups are already using this flaw shows that it is a practical route to compromise. CISA has placed the vulnerability on its Known Exploited Vulnerabilities list and explicitly demands that organisations apply the vendor’s fix or stop using the affected product.

How to know if you’re exposed

First, identify the Windows edition you are running. Open winver or go to Settings → System → About and note the OS build number. You can also retrieve the build from PowerShell:

Get-ItemProperty "HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion" | Select-Object ReleaseId, CurrentBuild, BuildLabEx

Compare the build you see with the information in the table below. The table lists the latest vulnerable build for each Windows branch and the build where the fix was introduced. If your build is older than the fixed release for your branch, you are vulnerable.

Another quick check is to ask your patch management system (WSUS, SCCM, Intune, etc.) whether the specific security update for this CVE has been installed. The update is identified by the Microsoft Knowledge Base article that addresses the Windows Error Reporting service privilege issue. If the KB article is missing from your installed updates list, you need to apply it.

Immediate mitigations if you cannot patch right away

• Disable the Windows Error Reporting service. Open services.msc, locate “Windows Error Reporting Service”, set the startup type to “Disabled”, and stop the service. This removes the attack surface but also stops crash reporting, which may be undesirable in production environments.
• Restrict local logon rights. Ensure that only authorised accounts have interactive logon rights on high‑value systems. Reducing the number of accounts that can run code locally limits the pool of potential attackers.
• Enable application control. Use Windows Defender Application Control or AppLocker to block unsigned executables from running. While this does not fix the privilege flaw, it adds a hurdle for an attacker who gains a foothold.

These steps are stop‑gap measures. The only permanent defence is to install the patched release from Microsoft.

Applying the fix

The vendor’s guidance is straightforward: install the security update that addresses the Windows Error Reporting privilege issue. On a machine that uses Windows Update, the update will appear as a critical or important update. You can force the installation with PowerShell:

Install‑Module -Name PSWindowsUpdate -Force
Import‑Module PSWindowsUpdate
Get‑WindowsUpdate -KBArticleID KBxxxxxx -Install -AcceptAll -AutoReboot

Replace <em>KBxxxxxx</em> with the identifier shown in your update catalog – the exact number is provided by Microsoft and will be present in the update description. If you manage updates centrally, approve the update in WSUS or your Microsoft Endpoint Manager console and push it to all affected machines.

After the installation, verify that the new build is present using the same winver or PowerShell command described earlier. The build number should match the “fixed” entry in the table below.

What to do if the patch is unavailable

In rare cases an organisation may be running a specialised Windows image that cannot be updated immediately (for example, an embedded system with a locked configuration). In that scenario:

• Isolate the system from the network until a patch can be applied.
• Disable the Windows Error Reporting service as described above.
• Monitor the host closely for any signs of privilege escalation – unexpected scheduled tasks, new services, or suspicious processes running as SYSTEM.

Document the risk and schedule a remediation window as soon as possible. Delaying beyond a few days significantly raises the chance of infection, given the active exploitation in ransomware campaigns.

Verification after remediation

Once the update is installed, run a quick sanity check. Open a command prompt as a normal user and attempt to query the WER service status:

sc query WerSvc

If the service reports a normal state and no error messages appear, the fix is likely in place. You can also use the Microsoft Safety Scanner or a third‑party vulnerability scanner that checks for CVE-2024-26169 – it should now report the host as patched.

Summary of actions

• Determine your OS build with winver or PowerShell.
• Check the table below to see if you are on a vulnerable build.
• If vulnerable, install the Microsoft security update that fixes the Windows Error Reporting service.
• Verify the new build is applied.
• If you cannot patch immediately, disable the WER service and tighten local logon controls.
• Monitor for suspicious activity until the patch is applied.

Remember: the vulnerability is already being weaponised in ransomware attacks. The cost of a breach far outweighs the brief inconvenience of a reboot after patching. Apply the update now.

Affected versions

Straight from the NVD record for CVE-2024-26169. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
windows_10_1507	* up to 10.0.10240.20526	10.0.10240.20526
windows_10_1607	* up to 10.0.14393.6796	10.0.14393.6796
windows_10_1809	* up to 10.0.17763.5576	10.0.17763.5576
windows_10_21h2	* up to 10.0.19044.4170	10.0.19044.4170
windows_10_22h2	* up to 10.0.19045.4170	10.0.19045.4170
windows_11_21h2	* up to 10.0.22000.2836	10.0.22000.2836
windows_11_22h2	* up to 10.0.22621.3296	10.0.22621.3296
windows_11_23h2	* up to 10.0.22631.3296	10.0.22631.3296
windows_server_2019	* up to 10.0.17763.5576	10.0.17763.5576
windows_server_2022	* up to 10.0.20348.2333	10.0.20348.2333
windows_server_2022_23h2	* up to 10.0.25398.763	10.0.25398.763