How do you patch or mitigate CVE-2020-0674 (Microsoft Internet Explorer Scripting Engine Memory Corruption)?

CISA’s required action for CVE-2020-0674 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Internet Explorer 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 does patching CVE-2020-0674 actually require?

The practical answer is straightforward: treat this as an actively exploited browser-engine flaw and make sure every Windows system that still has Internet Explorer components present receives the vendor update path Microsoft documented for that release. The fix is not only “install a patch”, it is also “verify the vulnerable browser surface is gone or no longer reachable where patching is delayed.”

Because this issue was added to the CISA KEV catalog, the operational expectation is rapid remediation rather than routine backlog handling. Use the vendor advisory and the KEV entry to confirm the correct update channel for the exact Windows build in your estate, then close any exceptions that keep old browser components exposed.

How do you confirm exposure and reduce the blast radius?

Start by finding where Internet Explorer is still enabled, installed, or indirectly usable through legacy application dependencies. That matters because exposure is not limited to users launching the browser intentionally, older line-of-business workflows, embedded web controls, and compatibility modes can keep the scripting engine reachable even when the browser is not the primary user interface.

If the affected host cannot be patched immediately, the next-best mitigation is to remove Internet-facing access paths and reduce where the component can be invoked. In practice that means tightening browser policies, constraining who can reach the system, and isolating any machine that must temporarily retain the legacy component until the update can be applied.

For teams that manage many endpoints, pairing patch enforcement with asset inventory is the only reliable way to avoid missing dormant instances. The Vulnerability Management Guide is useful here because the core task is not just remediation, it is prioritisation, exception handling, and verification across the estate.

What should you check after remediation?

After patching, assume the important question is whether the flaw was already used before the update landed. Review endpoint, browser, and server logs for unusual process launches, script execution patterns, crashes, or browser-driven child processes that could indicate earlier exploitation. If you find signs of compromise, move from patching to incident response rather than treating the event as closed.

This is also the point to verify that the fix actually reduced exposure. Confirm the update is present on all intended hosts, confirm the legacy browser path is disabled where the business does not need it, and confirm any exceptions have an owner and expiry date. For legacy software, “patched somewhere” is not the same as “no longer exploitable anywhere.”

Risk and Threat Considerations

This vulnerability matters because browser-engine flaws are attractive to attackers precisely because they can be reached through normal user activity and can lead to code execution from a routine web interaction. When a weakness like this is already in the wild, delay creates a real exposure window, especially on endpoints that still trust legacy browsing behavior.

Failure mechanism: A malicious page or content path can trigger memory corruption in the scripting engine, turning ordinary browsing or embedded web content into an execution path on the victim system.

Impact: Successful exploitation can enable code execution, follow-on payload delivery, and broader compromise of the affected endpoint, which is why earlier compromise checks belong in the same workflow as patching.

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 technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	CVE patching and exposure verification are core vulnerability management duties.
Recommendation — Prioritise, remediate, and verify the affected Internet Explorer instances quickly.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The issue requires vendor updates and timely remediation of a known software flaw.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch log review is needed to detect earlier exploitation indicators.
Recommendation — Apply the vendor update and verify the flaw is removed across the fleet. Review logs for signs of exploitation before and during remediation.
ISO/IEC 27001:2022	A.8.8 — Management of technical vulnerabilities	This is a technical vulnerability requiring tracking, patching, and exception handling.
Recommendation — Track the vulnerability to closure and govern any temporary exceptions.
NIST CSF 2.0	PR.IP-12 — Vulnerability management	The question is about remediating a known exploited vulnerability in production systems.
Recommendation — Use a managed vulnerability process to identify, patch, and confirm remediation.

Practitioner Guidance

What to prioritise: Patch systems that can still reach untrusted web content first, then isolate any legacy host that cannot be updated immediately. In environments with business-critical legacy dependencies, the risk is less about the existence of Internet Explorer and more about whether that surface is still reachable from user traffic or remote content.

What to verify: Do not trust a generic “browser update complete” status. Verify the specific host population, the exact Microsoft update path for the platform, and the removal or restriction of the legacy browser surface where feasible. If you cannot verify all three, treat the remediation as incomplete.

Practitioner takeaway: For a KEV-listed browser exploit, the real control is rapid closure of exposed instances plus confirmation that no pre-patch compromise occurred, not patch deployment alone.