Is CVE-2020-0968 (Microsoft Internet Explorer Scripting Engine Memory Corruption) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2020-0968 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft Internet Explorer contains a memory corruption vulnerability due to how the Scripting Engine handles objects in memory, leading to remote code execution.

What it means that CVE-2020-0968 was exploited in the wild

CISA’s KEV inclusion is the key signal here: it means this is not a theoretical browser flaw, but a vulnerability with confirmed active abuse. For defenders, the practical question is not whether exploitation is possible, but whether Internet Explorer still exists anywhere in your environment, because residual browser presence can keep an old attack path alive.

Internet Explorer vulnerabilities often matter most where legacy applications, compatibility modes, or unmanaged endpoints still depend on the browser engine. In this case, the issue sits in the scripting engine’s in-memory object handling, so exposure is tied to systems that can still invoke that engine, not just to users who intentionally launch Internet Explorer.

A useful way to think about this class of issue is that browser memory corruption can become a remote code execution path quickly once an attacker can steer the victim into loading hostile content. That is why exploitability is often highest in environments with weak browser controls, stale endpoints, or broad web access to users who are not expecting a browser-based attack.

How to confirm exposure and reduce attack surface

Start by identifying whether Internet Explorer, IE mode, or legacy components that rely on the IE scripting engine are still enabled anywhere. If the browser or engine is present only for compatibility, treat that as a deliberate exception and scope it tightly rather than assuming it is harmless because it is not the default browser.

Then validate the simplest containment steps first: remove or disable Internet Explorer where possible, restrict legacy use to approved systems, and confirm that modern browser policy is actually enforced. The Enterprise Browser and Browser Security Guide is useful here because the browser-security problem is usually about policy, isolation, extension control, and credential exposure as much as it is about patching.

If you need a broader prioritisation model for exposed flaws, use the Zero-Day and Exploited Vulnerabilities Guide alongside the Vulnerability Management Guide to separate confirmed exploitation from ordinary backlog items and to decide which assets need the fastest action.

What to do if patching or removal is delayed

If you cannot remediate immediately, focus on shrinking the conditions that make browser exploitation useful to an attacker. That means tightening web filtering, limiting access to untrusted content, reducing the number of users who can reach legacy browser paths, and applying stronger endpoint controls around the systems that still depend on the IE engine.

Use compensating controls to buy time, not to justify indefinite deferral. The right standard is whether the control measurably lowers the chance that a malicious page, document, or injected web object can reach the vulnerable scripting path, not whether the environment still “works” after the exception.

For external confirmation of exposure status, check the vendor advisory for version and mitigation details, then cross-reference the CISA Known Exploited Vulnerabilities Catalog. For product-level identification and record context, the CVE Program and NIST National Vulnerability Database provide the canonical references you should use rather than rebuilding details from memory.

Risk and Threat Considerations

When a browser memory corruption issue is actively exploited, the main risk is not just compromise of the browser process, but the possibility that a simple user interaction becomes a foothold for code execution. That makes legacy browser exposure especially dangerous in environments where users still browse internal or external content from high-trust workstations.

Failure mechanism: The attacker delivers content that triggers the vulnerable scripting engine’s object-handling flaw, corrupts memory, and converts a browsing session into remote code execution on the endpoint.

Impact: Successful exploitation can lead to endpoint compromise, follow-on credential theft, lateral movement, and broader intrusion if the affected system has access to internal resources or privileged sessions.

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 CIS Controls v8 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	Actively exploited browser flaws require fast identification and prioritisation.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities across exposed endpoints.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Actively exploited vulnerabilities require controlled remediation and verification.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure must be found and tracked across endpoints that still run legacy browser components.
Recommendation — Apply flaw remediation processes to confirm exposure and complete fixes. Continuously scan for systems still exposing the vulnerable browser engine.
MITRE ATT&CK	T1203 — Exploitation for Client Execution	Browser memory corruption often becomes code execution through client-side exploitation.
Recommendation — Hunt for client-side exploit delivery and follow-on execution on endpoints.

Practitioner Guidance

What to verify: Confirm whether Internet Explorer, IE mode, or any application path that depends on the IE scripting engine still exists on production endpoints. If it does, verify whether those systems are segregated, monitored, and restricted to the smallest possible user set.

Decision rule: If the affected browser path is still reachable from a standard user workstation, treat this as an exposure problem as well as a patch problem, and prioritise removal or isolation before deeper hardening work.

What to measure: Track how many endpoints still expose the legacy engine, how many users can invoke it, and how quickly those exceptions are eliminated after KEV listing. A shrinking exception set is the practical sign that the attack surface is actually being reduced.

Practitioner takeaway: For KEV-listed browser flaws, the right question is not only “is it patched?”, but “does any reachable legacy browser path still exist that an attacker can turn into execution?”

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org