Is CVE-2016-0189 (Microsoft Internet Explorer Memory Corruption) being exploited in the wild?

Yes. CISA added CVE-2016-0189 to its Known Exploited Vulnerabilities catalogue on 28 March 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. The Microsoft JScript nd VBScript engines, as used in Internet Explorer and other products, allow attackers to execute remote code or cause a denial of service (memory corruption) via a crafted web site.

What active exploitation means for CVE-2016-0189

This finding means the issue is not just theoretical. For this CVE, the operational question is whether any Internet Explorer or legacy Microsoft scripting surface remains reachable in your environment, whether users can still render untrusted web content with those engines, and whether compensating controls are strong enough to reduce exposure while you remove the vulnerable path.

The most important point is that exploitation can occur through ordinary web browsing, so the practical risk sits at the edge where browser trust meets user interaction. If the vulnerable component is still enabled anywhere, treat it as internet-facing attack surface until proven otherwise.

For the broader response pattern, Zero-Day and Exploited Vulnerabilities Guide is useful because it frames how to triage exploited issues, validate exposure, and move quickly when active abuse is already established.

How to confirm exposure and reduce the attack surface

Start by identifying where the affected browser components or scripting engines can still execute, including embedded browser controls, legacy compatibility modes, and older application workflows that depend on Internet Explorer behavior. The key question is not whether modern users prefer another browser, but whether any business process still allows the vulnerable execution path.

Next, reduce the chance that a malicious site can reach that path at all. That usually means removing or disabling legacy browser use where possible, restricting access to untrusted sites, and making sure browser policy, extension control, and isolation settings are aligned with the actual risk profile of the estate. If the vulnerable surface is used for internal applications, verify whether those applications can be migrated or isolated before assuming they are safe.

For browser hardening and containment decisions, the Enterprise Browser and Browser Security Guide is the most directly relevant internal reference because it covers browser policy, isolation, and credential-theft exposure in the same operating area.

Authoritative product and vulnerability details should come from the CVE Program and the NIST National Vulnerability Database, while exposure status and remediation urgency should be checked against the CISA Known Exploited Vulnerabilities Catalog.

What to do if patching or removal must wait

If immediate remediation is not possible, treat the issue as a temporary risk reduction problem, not a reason to defer action. The goal is to make exploitation harder, less likely to succeed, and easier to detect. That usually means constraining who can browse, where they can browse, and what browser surfaces remain enabled until the vulnerable component is removed or remediated.

Be especially careful with shared workstations, privileged users, and environments that still need legacy browser compatibility. Those contexts increase blast radius because a single successful exploit can affect a user with broader access or reach a higher-value internal target. If you cannot eliminate the component quickly, segment the affected population and increase monitoring around web-triggered execution paths.

The practical triage question is whether a compensating control actually changes the exploit path. If it only adds friction but leaves the vulnerable engine reachable from untrusted content, it should be treated as partial risk reduction, not a substitute for remediation.

Risk and Threat Considerations

This CVE is materially risky because it combines remote code execution potential with a web-delivery path, which makes opportunistic exploitation scalable. Once a user visits a crafted site, the attacker may be able to execute code without needing prior foothold, so the issue is attractive both for targeted intrusions and broader exploitation campaigns.

Failure mechanism: A crafted webpage triggers memory corruption in the scripting engine, allowing malicious code execution or denial of service on the client system.

Impact: Successful exploitation can lead to browser compromise, follow-on credential theft, payload delivery, and lateral movement if the affected endpoint has access to internal resources or reused sessions.

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	Actively exploited CVEs require prioritised exposure tracking and remediation.
Recommendation — Prioritise remediation of KEV-listed exposure and verify affected assets are removed or mitigated.
NIST CSF 2.0	DE.CM-09 — Vulnerability Scans Are Performed	Known exploited vulnerabilities depend on finding exposed systems quickly and continuously.
Recommendation — Scan for affected endpoints and validate the vulnerable browser path is no longer present.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Active exploitation makes flaw remediation the central defensive control.
	RA-5 — Vulnerability Monitoring and Scanning	This CVE needs continuous monitoring for exposure and exploitability across assets.
Recommendation — Remediate the flaw or disable the vulnerable component as soon as exposure is confirmed. Continuously monitor for vulnerable versions and confirm compensating controls remain effective.
OWASP ASVS	V15 — Secure Coding and Architecture	Memory-corruption exploitation is reduced when insecure legacy execution paths are removed from architecture.
Recommendation — Remove legacy browser-dependent execution paths from application architecture where possible.

Practitioner Guidance

What to verify: Confirm whether any endpoint still relies on the vulnerable browser path for business-critical work, including embedded web views and legacy compatibility modes. If you cannot answer that confidently, assume the exposure still exists until you have inventoried it.

Decision rule: If the vulnerable component is reachable from untrusted web content, prioritise removal or disablement first; if removal is delayed, treat the issue as a containment and exposure-minimisation problem, not a monitoring-only issue.

What practitioners underestimate: The main danger is often not the browser crash itself but the downstream access that follows a successful client compromise, especially on users who already hold privileged sessions or access sensitive internal systems.

Practitioner takeaway: For exploited browser CVEs, the real control question is whether you have removed the execution path, not whether you have read the advisory.