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

Yes. CISA added CVE-2020-1380 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Internet Explorer contains a memory corruption vulnerability which can allow for remote code execution in the context of the current user.

What CISA’s KEV listing means for this CVE

CISA’s inclusion of CVE-2020-1380 in the Known Exploited Vulnerabilities catalogue is the strongest public signal that the issue is not just theoretical. For defenders, that changes the priority from “patch eventually” to “treat as actively exploited until proven otherwise,” even when the immediate symptom is only browser execution in a user context.

The practical point is that exploitation status should drive urgency. If a vulnerability is in KEV, exposure is no longer about whether someone could build an exploit in the abstract, but whether affected systems remain reachable, unmanaged, or still capable of being used as a foothold.

What exposure looks like on real systems

For this CVE, the first question is whether Internet Explorer components are still present anywhere in the environment, including legacy desktops, virtual desktops, kiosks, embedded endpoints, or application compatibility setups that still invoke the browser engine. Even if users do not “use IE” day to day, the scripting engine can still be exposed through old links, internal apps, or legacy document workflows.

Because the vulnerability is a memory corruption issue that can lead to remote code execution in the context of the current user, the real security question is not just browser presence. It is whether that user context has access to anything valuable, such as files, network shares, intranet applications, or saved credentials that could widen the blast radius after initial code execution. See the CISA Known Exploited Vulnerabilities Catalog for the authoritative exploitation-tracking source, and use the NIST National Vulnerability Database to corroborate the record and product details.

What to do when patching is delayed

The right response is to remove or disable the exposure path first, then verify that the fix is actually effective. For legacy browser-engine issues, that can mean reducing or disabling Internet Explorer usage, restricting the vulnerable component where possible, and limiting where the affected application can still run. The Zero-Day and Exploited Vulnerabilities Guide is useful here because the same response pattern applies to actively exploited flaws: triage fast, mitigate first, then confirm remediation.

If full remediation must wait, isolate the affected user population and watch for exploit attempts that target the browser engine or unusual child-process behavior from the browser. That is especially important where old line-of-business systems still depend on older Microsoft web components and cannot be upgraded immediately.

What to check after exposure or compromise

If any system may have been reachable before remediation, assume the browser session could have been used as an initial execution point. Validate whether the user account involved performed unexpected actions, whether new persistence appeared, and whether the endpoint touched sensitive internal resources after the time of suspected exploitation. The question is not only whether code ran, but whether the attacker was able to do anything useful after that first execution.

Where the compromised user had access to sensitive data or browser-stored material, review whether session state, cached credentials, or related secrets may have been exposed. The Enterprise Browser and Browser Security Guide is relevant because browser hardening and credential protection are often the difference between a contained event and a broader account or data exposure. For prioritisation, the FIRST EPSS model can help rank related vulnerabilities, but KEV should already put this one at the front of the queue.

Risk and Threat Considerations

Actively exploited browser vulnerabilities are attractive because they sit on a common trust boundary: user web activity. Even when execution begins only in the current user’s context, that is often enough to pivot into browser-stored data, internal applications, or other reachable resources on the endpoint.

Failure mechanism: Memory corruption in the scripting engine can be triggered through crafted content, leading to code execution under the logged-in user and creating a foothold for follow-on activity.

Impact: Successful exploitation can expose local data, browser state, and any internal access that the user session can reach, which makes remediation urgent even when the initial compromise appears limited.

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 SP 800-53 Rev 5 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitably requires prioritised vulnerability handling and remediation.
Recommendation — Prioritise and remediate this actively exploited CVE using continuous vulnerability management.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	The question is about an exploited vulnerability and verifying exposure/remediation.
	SI-2 — Flaw Remediation	Active exploitation makes timely flaw remediation the core control response.
	AC-6 — Least Privilege	Browser exploit impact depends on the privileges and reach of the logged-in user.
Recommendation — Track this CVE through vulnerability monitoring and verify affected assets are remediated. Apply flaw remediation promptly and confirm the vulnerable software is fixed or removed. Limit user privileges to reduce the blast radius of successful browser exploitation.
NIST CSF 2.0	PR.AA-05 — Authenticate Identities Before Granting Access	Browser compromise often becomes material through authenticated user access and session abuse.
Recommendation — Verify access decisions and session protections so compromise cannot easily escalate through the user context.

Practitioner Guidance

What to prioritise: Inventory where Internet Explorer components still exist, then rank those systems by user privilege and network reach. A low-privilege kiosk and a privileged workstation do not carry the same post-exploitation risk.

What to verify: Confirm that the vulnerable component is actually removed, disabled, or patched across all legacy endpoints, not just on standard desktops. Exception handling is where actively exploited browser issues often linger.

Practitioner takeaway: For a KEV-listed browser-engine flaw, urgency should be driven by live exposure and reachable privilege, not by whether the system seems to be “just a browser problem.”