Is CVE-2023-36424 (Microsoft Windows Out-of-Bounds Read) being exploited in the wild?

Yes. CISA added CVE-2023-36424 to its Known Exploited Vulnerabilities catalogue on 13 April 2026, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Common Log File System Driver contains an out-of-bounds read vulnerability that could allow a threat actor for privileges escalation

How to confirm the exploitation signal behind CVE-2023-36424

For an “is it being exploited in the wild?” question, the key signal is not the vulnerability label itself, but whether a trusted authority has put it on an active exploitation list. For this CVE, the practical confirmation path is to treat CISA KEV as the primary public indicator, then cross-check the vendor advisory and your own exposure inventory before assuming the issue is urgent everywhere.

When a Windows flaw is in KEV, the next question is whether any of your Windows hosts actually use the affected component path in a way that can be reached remotely or by a local attacker. That means validating product presence, privileged execution paths, and whether the vulnerable driver is present on endpoints, servers, or management systems that matter operationally.

For a concise response, use CISA Known Exploited Vulnerabilities Catalog as the authoritative exploitation signal, and pair it with the CVE Program record plus Microsoft’s advisory details to confirm the exact Windows component and remediation path.

What this vulnerability means operationally

An out-of-bounds read in a Windows driver is not just a theoretical memory-safety issue. In practice, it can support privilege escalation, information disclosure, or both, depending on how the weakness is reached and what adjacent conditions an attacker can satisfy. The operational concern is that even a local foothold can become a stronger position inside the host if the flaw is reachable on a system that already carries sensitive access or broad trust.

Because the flaw sits in a core Windows component, the business impact depends on where Windows endpoints sit in the estate and what they can reach after compromise. Systems that handle admin activity, security tooling, domain-adjacent administration, or privileged workflows deserve faster verification than low-value desktops, because exploitation on those hosts can widen the blast radius quickly.

For background on why this type of issue is treated as high-priority vulnerability work, the Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide both map the practical triage logic used when exploitation evidence appears before a normal patch cycle can absorb it.

What to do when patching or mitigation must wait

If patching cannot happen immediately, reduce exposure rather than waiting for a perfect maintenance window. The immediate goal is to shrink the number of systems that can be reached, the accounts that can be leveraged, and the opportunities for post-exploitation movement if the flaw is already in use.

That usually means narrowing administrative access, isolating high-value Windows systems, and watching for unusual local privilege use, driver loading, or follow-on authentication anomalies. If the host is business critical and cannot be patched at once, treat the delay as a compensating-control problem, not as a reason to defer the risk assessment.

FIRST EPSS is useful for prioritisation, but it should sit behind confirmed exploitation signals when KEV already indicates active use. For the same reason, the CWE Top 25 Guide is most useful here as root-cause context, not as a substitute for operational response.

Risk and Threat Considerations

Once a Windows memory-safety flaw is confirmed in KEV, the main risk is not just that one host may be affected. The bigger concern is that exploitation can turn a local weakness into a privilege boundary break, which then gives an attacker a stronger launching point for credential access, lateral movement, or defence evasion on systems that were assumed to be trusted.

Failure mechanism: An attacker reaches the vulnerable Windows driver path and uses the out-of-bounds read to escalate privileges or extract information that improves the next stage of compromise.

Impact: A successful exploit can convert a single endpoint into a more capable foothold, increasing the chance of follow-on compromise across the Windows estate and raising the value of that host as a staging point.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Active exploitation requires prioritized vulnerability tracking and remediation.
Recommendation — Prioritise and remediate KEV-listed hosts first.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	KEV triage depends on identifying vulnerable Windows assets quickly.
	PR.PS-01 — Configurations are managed and maintained to meet security requirements	Mitigation depends on hardening or patching affected Windows systems.
Recommendation — Identify exposed Windows assets and record the vulnerable footprint. Apply the vendor fix or mitigation to affected systems.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	A confirmed exploited vulnerability demands disciplined flaw remediation.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and ongoing tracking both rely on vulnerability monitoring.
Recommendation — Patch or mitigate the exploited flaw on the shortest safe timeline. Scan for vulnerable Windows systems and track remediation progress.

Practitioner Guidance

What to verify: Confirm whether the vulnerable Windows component is present on systems that matter for administration, identity, or security operations, then check whether those hosts are already showing any sign of abnormal privilege activity, unexpected reboots, or suspicious driver-related telemetry.

Decision rule: If the system is internet-facing, privileged, or mission-critical, treat the KEV listing as a response trigger and prioritise remediation or isolation before general backlog work. If patching is delayed, preserve logs and be ready to validate whether compromise pre-dated the fix.

Practitioner takeaway: For KEV-listed Windows issues, the operational question is no longer whether exploitation is possible, but whether your highest-value hosts have already been exposed long enough for an attacker to benefit from it.