How do you patch or mitigate CVE-2023-36424 (Microsoft Windows Out-of-Bounds Read)?

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

CVE-2023-36424 should be handled as a full estate action, not a single host fix. Inventory every Microsoft Windows instance first, then apply the vendor security update or the documented mitigation wherever the product is in use. If the affected product cannot be corrected, reduce or remove exposure rather than leaving it reachable and hoping the weakness is not reachable in practice.

For an active exploitation workflow, treat the problem as a vulnerability management and emergency remediation issue. The operational question is whether every instance has a path to a supported fix, a temporary mitigation, or an approved retirement plan. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it frames the triage pattern for exploited weaknesses, while the Patch Management Guide gives the deployment discipline needed to push fixes safely across rings and exceptions.

When Windows is widely deployed, the hard part is usually not the patch itself but proving coverage. Unmanaged endpoints, legacy servers, and systems owned by separate teams are the most common reasons remediation drifts. That is why the Vulnerability Management Guide matters: it reinforces asset scope, verification, and remediation tracking so you can confirm the vulnerable product is actually gone from production where required.

When mitigation is the only immediate option

If vendor instructions call for mitigation instead of a full fix, treat that mitigation as a compensating control, not a permanent solution. The practical goal is to block the exploit path long enough to buy time for patching, retirement, or architecture change. If the product sits on an internet-facing boundary, the first mitigation is often to remove that exposure rather than rely on a control that only works when every assumption holds.

Where a fix is unavailable, the decision is usually between constrained exposure and discontinuation. That means disabling the vulnerable service, isolating the host segment, restricting who can reach it, or taking the product out of service if the business cannot tolerate the residual risk. The Patch Management Guide and the CISA Known Exploited Vulnerabilities Catalog together support that decision path because they tie remediation to exploitation urgency, not just to routine maintenance windows.

For cloud-hosted or externally delivered services, follow the required guidance for the service layer as well as the host layer. If the weakness lives inside a managed service path, a local patch alone may not be enough, and the exposure may remain until the service owner applies its own mitigation. In that situation, the safest operational move is to stop treating the issue as only an endpoint patch problem.

What to check before you declare it fixed

After remediation, verify more than patch installation. Confirm the vulnerable Windows product is absent or corrected on every reachable instance, confirm no internet-facing path remains to the unmitigated version, and look for signs that the flaw was already exercised before the fix landed. For exploited vulnerabilities, post-patch validation should include compromise review, not just version checking.

Where a host or service was exposed before remediation, review telemetry, authentication activity, and adjacent systems that could have been used after initial access. If the vulnerability created a path into a system that stores credentials, tokens, or administrative access, rotate those materials only when the exposure path or evidence of compromise makes it materially necessary. The key judgment is whether the flaw could have been used to reach higher-value trust material, not whether a rotation checklist exists in the abstract.

Risk and Threat Considerations

Out-of-bounds read flaws can expose memory contents, so the risk is not limited to crashes or denial of service. On a Windows estate, the practical concern is that an attacker may use the flaw to recover sensitive process data, then chain that access into deeper compromise if the exposed system is trusted by other services or users.

Failure mechanism: The weakness is exploitable when the vulnerable Windows component remains reachable and the affected code path can be triggered before a patch or documented mitigation is in place.

Impact: Successful exploitation can expose memory-resident data, expand the blast radius of an initial foothold, and leave the organisation with both an urgent remediation task and a compromise-assessment problem.

Practitioner Guidance

What to prioritise: Start with any Windows instance that is internet-facing, supports a business-critical service, or sits in a high-trust segment. Those systems create the fastest route from a vulnerability to operational impact, so they deserve first-pass remediation and validation.

What to verify: Do not trust a patch report alone. Verify installation, confirm the vulnerable product is not still exposed through a different path, and make sure the host owner can show when the mitigation or retirement action was completed.

Decision rule: If the system can be patched, patch it; if it cannot be patched immediately, remove exposure or isolate it; if neither action is feasible, treat continued operation as an exception that needs explicit risk acceptance and a short expiry.

Practitioner takeaway: The right response is not “apply a patch when convenient”, it is “close the exploit path now, then prove the estate is clean enough to trust again.”

Related resources from NHI Mgmt Group

• Is CVE-2023-36424 (Microsoft Windows Out-of-Bounds Read) being exploited in the wild?
• How do you patch or mitigate CVE-2023-28204 (Apple Multiple Products WebKit Out-of-Bounds Read)?
• How do you patch or mitigate CVE-2018-8174 (Microsoft Windows VBScript Engine Out-of-Bounds Write)?
• CVE-2023-36424 (Microsoft Windows Out-of-Bounds Read)