How do you patch or mitigate CVE-2023-36874 (Microsoft Windows Error Reporting Service Privilege Escalation)?

CISA’s required action for CVE-2023-36874 is to apply updates per vendor instructions or discontinue use of the product if updates are unavailable. In practice, find every instance of Microsoft Windows in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What patching CVE-2023-36874 should look like in a Windows estate

Start with complete asset visibility, not just the server or workstation where the alert appeared. You need to identify every supported Microsoft Windows instance, confirm whether vendor guidance has been applied, and treat any unpatched or partially mitigated system as exposed until proven otherwise. Because this is a privilege escalation issue, exposure is about local trust boundaries as much as internet reachability.

For active vulnerability response, the most useful workflow is to reconcile inventory, validate update status, and then verify that the applied fix actually landed on the intended hosts. That is where Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide are most helpful, because the operational problem is not just patching once, but proving that remediation happened everywhere it needed to happen.

If a system cannot be updated promptly, reduce the blast radius before you defer the fix. For a Windows service flaw that can raise privileges, the practical alternatives are to remove unnecessary network exposure, isolate the host, or take the product out of service if there is no supported mitigation path. In other words, the fallback is containment, not continued normal operation.

Why this issue is more than a simple patch ticket

A privilege escalation flaw changes the security posture of a Windows host even when the initial foothold is low privilege. Once a local attacker can cross into elevated execution, the issue becomes a stepping stone for credential access, persistence, lateral movement, and defensive evasion. That is why “patch it later” is risky when the vulnerable host remains reachable and trusted inside the environment.

This is also why exploited vulnerability handling should be treated as an incident-adjacent activity. The CISA KEV catalogue exists specifically to flag vulnerabilities with confirmed active exploitation, so the fact pattern itself should push teams toward urgent action rather than routine change windows. For authoritative tracking, use the CISA Known Exploited Vulnerabilities Catalog together with the NIST National Vulnerability Database and the CVE Program record for naming, status, and reference details.

If patching is delayed, the relevant control question is whether an attacker who gains basic execution on the host can turn that into something more powerful before remediation. On a Windows privilege escalation path, that answer is often yes unless the environment has unusually strong hardening, containment, and monitoring.

What to check after mitigation and before you close the case

After applying the vendor update or documented mitigation, assume the host may have been probed already. Review endpoint, host, and security logs for earlier exploitation signals, especially privilege changes, unusual service behavior, suspicious child processes, and follow-on authentication activity. Where available, compare the time of patching with the time window in which the vulnerability was publicly abused so you do not miss pre-remediation compromise.

That post-fix review is most effective when it is paired with attack-path awareness. MITRE ATT&CK Enterprise Matrix is useful here because it helps teams map local privilege escalation into the broader sequence of credential access and lateral movement that often follows an initial exploit. For prioritisation, FIRST EPSS can help separate widely exploitable issues from less urgent ones when you are building the remediation queue.

If you find signs of compromise, the response should expand beyond the single CVE. Rotate any credentials, sessions, or service accounts that may have been exposed on the affected host, then verify whether the attacker used the elevated position to reach other systems. The goal is to prove that exploitation did not become persistence.

Risk and Threat Considerations

This vulnerability matters because privilege escalation turns an ordinary Windows compromise into an administrative one. If the flaw is reachable on a system that handles sensitive work or stores reusable credentials, the attacker can use the elevated context to deepen access, tamper with logs, and move laterally before defenders notice.

Failure mechanism: A local or initial foothold is converted into higher privilege through the vulnerable service path, which can then be used to alter security posture, harvest secrets, or stage follow-on access.

Impact: The result can be full host compromise, broader domain exposure, and delayed detection if the adversary acts before the patch is deployed or before logs are reviewed.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

MITRE ATT&CK addresses the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.AM-01 — Physical devices and systems within the organization are inventoried	Asset inventory is required to find all vulnerable Windows instances.
	PR.PS-02 — Software, firmware, and information integrity is maintained	Patching and validated mitigation preserve system integrity against exploitation.
	DE.CM-01 — Networks and network services are monitored to find potential cybersecurity events	Post-patch review depends on monitoring for exploitation and follow-on activity.
Recommendation — Inventory all Windows hosts before and after remediation to confirm exposure is closed. Apply the vendor update or mitigation and verify the integrity state changed as expected. Monitor host and network telemetry for signs of prior exploitation.
MITRE ATT&CK	T1068 — Exploitation for Privilege Escalation	The CVE is a privilege escalation flaw and maps directly to this ATT&CK technique.
Recommendation — Map the exploit path to privilege escalation and hunt for follow-on activity.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Urgent patching, mitigation, and verification are core vulnerability-management actions.
Recommendation — Prioritise, remediate, and verify this KEV entry within continuous vulnerability management.

Practitioner Guidance

What to prioritise: Patch or mitigate every reachable Windows instance that matches the affected exposure pattern, then immediately separate those systems from normal trust assumptions until remediation is verified. If there is any doubt about coverage, treat the asset as still vulnerable.

What to verify: Confirm that the vendor update or workaround is actually present on the target host, not just approved in a ticket. Then check whether the system showed unusual privilege, service, or log activity before remediation, because the presence of a fix does not erase earlier compromise.

Decision rule: If no supported fix can be applied in time, reduce exposure first, then document the exception and put the host on a short leash. For an exploited Windows privilege escalation, continued internet exposure or broad internal trust is the wrong default.

Practitioner takeaway: With an exploited privilege escalation bug, the right question is not only “is it patched?”, but “could this host already have been used to gain more access before we closed the hole?”