CISA's required action for CVE-2020-0968 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 patching means for this CVE
The practical answer is straightforward: treat this as a vendor-update problem first, not a tuning problem. Microsoft Internet Explorer scripting engine memory corruption should be remediated by applying the vendor security update on every affected system where Internet Explorer still exists, then confirming that the update actually landed and that no alternate path is still exposing the vulnerable code.
This is also an asset-discovery problem. You cannot reliably mitigate a browser-engine flaw if you do not know where Internet Explorer binaries, shortcuts, compatibility modes, or legacy dependencies remain in the estate. For Internet Explorer issues, the highest-risk assumption is usually that one forgotten workstation, kiosk, or application compatibility image will keep the vulnerable component reachable.
If you cannot patch immediately, the fallback is to remove internet exposure or take the product out of service. That means reducing the chance that hostile content can reach the scripting engine at all, rather than relying on users to avoid malicious pages or documents.
How to reduce exposure while the fix is pending
When a patch window is delayed, the right mitigation is to narrow the attack surface as much as possible. That usually means removing direct web access, disabling or retiring Internet Explorer where business operations allow it, and making sure any remaining dependency is isolated from general browsing and untrusted content.
For a browser-engine memory corruption issue, partial mitigations are only valuable if they actually reduce code execution opportunities. Compatibility settings, alternate rendering modes, or policy changes that leave Internet Explorer usable for arbitrary web content do not change the core risk enough to be considered a substitute for the update.
For older enterprise estates, this is often where lifecycle decisions matter more than configuration tweaks. If a business process still depends on Internet Explorer, the longer-term mitigation is to move that dependency to a supported browser or a controlled access path, so the vulnerable component is no longer part of normal user workflow.
What to check after remediation
After patching, review logs for signs of earlier exploitation because this CVE was used in the wild. Look for unusual browser crashes, script-engine errors, unexplained child processes, suspicious downloads, or web activity that does not match normal user behaviour. The goal is not just to prove the update installed, but to decide whether the vulnerability was already used as an entry point.
If you find evidence of exploitation, expand the review beyond the browser itself. A scripting-engine exploit is often only the initial foothold, so follow-up triage should consider lateral movement, persistence, and any secrets or sessions that may have been exposed after initial compromise.
Risk and Threat Considerations
This vulnerability matters because browser scripting engines are exposed to untrusted content by design, which makes them a high-value route for code execution. If Internet Explorer remains reachable, an attacker only needs a successful delivery path and a victim interaction to turn a memory corruption bug into a foothold.
Failure mechanism: Malicious web content or another hostile input path triggers the scripting engine flaw, leading to arbitrary code execution or a crash that can be chained into follow-on compromise.
Impact: Exposure can extend beyond the browser session to malware installation, credential theft, persistence, and wider host compromise, especially where the vulnerable component still has network reach.
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, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Patch-and-mitigate guidance is driven by timely vulnerability remediation. |
| CIS-4 — Secure Configuration of Enterprise Assets and Software | Removing exposure and retiring IE are configuration and hardening actions. | |
| Recommendation — Prioritise and verify remediation of exposed Internet Explorer systems. Harden or disable Internet Explorer where business use persists. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability management is performed to manage vulnerabilities and mitigations | The question is about applying updates and compensating mitigations for a known exploited CVE. |
| DE.CM-08 — Vulnerabilities in software, hardware, firmware, and systems are monitored and detected | Post-patch review requires monitoring for compromise indicators tied to the flaw. | |
| Recommendation — Track this CVE through remediation and mitigation until exposure is eliminated. Monitor affected hosts for exploitation indicators after remediation. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Applying the vendor security update is direct flaw remediation for this CVE. |
| SI-4 — System Monitoring | Log review for exploitation indicators is a monitoring requirement after patching. | |
| Recommendation — Deploy the vendor fix and confirm it is installed on all exposed systems. Review security logs and alerts for signs of prior exploitation. | ||
| OWASP ASVS | V13 — Configuration | Mitigation depends on removing or hardening the exposed browser component. |
| V16 — Security Logging and Error Handling | The guidance includes checking logs for exploitation after remediation. | |
| Recommendation — Disable or constrain legacy browser exposure in affected environments. Retain and review logs that can confirm exploitation attempts or success. | ||
Practitioner Guidance
What to prioritise: Patch or retire every remaining Internet Explorer instance before spending time on compensating controls. If you must defer, use isolation and removal of internet exposure as the temporary risk reduction step, not as the final state.
What to verify: Confirm that the vulnerable component is actually gone from normal user reach, and not merely hidden behind an application shortcut, compatibility mode, or legacy dependency. Then verify that post-patch monitoring can distinguish routine browser noise from signs of exploitation.
Practitioner takeaway: For an actively exploited browser-engine flaw, the decision is usually between prompt remediation and meaningful exposure removal, because soft mitigations rarely provide enough protection once hostile content can still reach the code path.
Related resources from NHI Mgmt Group
- Guide: Enterprise Browser and Browser Security Guide
- How do you patch or mitigate CVE-2020-0674 (Microsoft Internet Explorer Scripting Engine Memory Corruption)?
- How do you patch or mitigate CVE-2020-1380 (Microsoft Internet Explorer Scripting Engine Memory Corruption)?
- How do you patch or mitigate CVE-2018-8653 (Microsoft Internet Explorer Scripting Engine Memory Corruption)?
- How do you patch or mitigate CVE-2019-1367 (Microsoft Internet Explorer Scripting Engine Memory Corruption)?
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.
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