CVE-2020-0878 is a memory corruption vulnerability in Microsoft Edge and Internet Explorer. CISA added it to the Known Exploited Vulnerabilities catalogue on 3 November 2021, which means attackers have used it in real attacks. Microsoft Edge and Internet Explorer contain a memory corruption vulnerability that allows attackers to execute code in the context of the current user.
What this vulnerability means in practice
Memory corruption in a browser is dangerous because it can let crafted content alter execution flow inside a widely trusted application. For users of Microsoft Edge and Internet Explorer, that can turn a normal web visit into code execution under the current user’s privileges, which is enough to steal data, install malware, or stage a deeper compromise.
Because the affected software is a browser, the attack surface is broad: malicious web pages, injected content, or compromised third-party content delivery can all become delivery paths. The practical lesson is that browser flaws are not just client-side defects, they are a direct route from web content to endpoint compromise.
How organisations assess exposure
Exposure assessment starts with knowing where the browser is still present, which endpoints still allow it to run, and which users can reach untrusted content with it. Asset inventory matters here, as does internet exposure, because any externally reachable workflow that depends on the affected browser increases the chance of exploitation.
Organisations should also check vendor advisories and authoritative vulnerability records so they can confirm whether they are exposed to this exact issue and whether compensating changes are already available. For the canonical record, use the CVE Program and NIST National Vulnerability Database rather than relying on secondary summaries.
Remediation and compensating controls
The primary response is to remove the vulnerable software state as quickly as the environment allows. Where immediate patching is not possible, the next best control is to reduce exposure by limiting access to the browser, constraining browsing behaviour, and tightening endpoint control so that a successful exploit has less room to operate.
In practice, organisations should prefer a vulnerability-management workflow that combines prioritisation, exception handling, and verification. NHIMG’s Vulnerability Management Guide is useful because it frames KEV-listed issues as remediation work, not just inventory data. For a broader control baseline, NIST SP 800-53 Rev 5 Security and Privacy Controls supports the control disciplines that underpin patching, monitoring, and endpoint hardening.
Detection and post-patch review
Detection is important both before and after remediation. Before patching, organisations should look for browser crashes, unusual child processes, suspicious downloads, and endpoint behaviour that suggests exploitation. After patching, they should still review the endpoint for signs that code execution already occurred, because a fixed vulnerability does not remove persistence that may have been established during the compromise.
That review should include browser sessions, recent user activity, and any files or processes created around the time of suspected exploitation. The key question is whether the exploit was used only to run code, or whether it also enabled follow-on actions such as credential theft, payload staging, or lateral movement.
Risk and Threat Considerations
This vulnerability matters because browser exploitation often starts with a single visit and ends with user-level code execution on a real workstation. That creates a practical bridge from remote content to endpoint compromise, which can then support theft, malware deployment, or further intrusion.
Failure mechanism: Memory corruption can let attacker-controlled input alter control flow inside the browser process, producing arbitrary code execution in the context of the current user.
Impact: Successful exploitation can expose local data, enable malware installation, and provide a foothold for later privilege escalation or movement to adjacent systems.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Patch and verify remediation of exploitable software flaws. |
| SI-3 — Malicious Code Protection | Browser exploitation often delivers or enables malicious payloads. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploit review depends on log and event analysis. | |
| Recommendation — Track and remediate the browser flaw, then verify affected endpoints are fully updated. Harden endpoint malware controls to detect payloads delivered after browser exploitation. Review browser and endpoint logs for indicators of exploitation and follow-on activity. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This issue is a prioritised vulnerability-management case. |
| Recommendation — Prioritise, remediate, and verify the browser vulnerability across all exposed assets. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a priority endpoint exposure, not a low-level browser bug. If the affected browser is still in use, the practical risk is that a routine web interaction can become an initial compromise path.
What to watch for: Focus on endpoints that browse untrusted content, legacy systems that still depend on Internet Explorer compatibility, and any signs that the browser process spawned unexpected activity. Where exploitation is suspected, preserve evidence before cleanup so you can determine whether the browser flaw was only the entry point or part of a larger incident.