Is CVE-2017-0037 (Microsoft Edge and Internet Explorer Type Confusion) being exploited in the wild?

Yes. CISA added CVE-2017-0037 to its Known Exploited Vulnerabilities catalogue on 28 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Edge and Internet Explorer have a type confusion vulnerability in mshtml.dll, which allows remote code execution. Any organisation running the affected product should treat remediation as urgent.

What CISA’s KEV listing means for this CVE

CISA’s inclusion of a vulnerability in the Known Exploited Vulnerabilities catalogue is the clearest operational signal that defenders should treat it as actively weaponised, not theoretical. For CVE-2017-0037, that means the exposure is not just historical or vendor-lab based, it belongs in urgent remediation queues, patch exceptions, and executive reporting for any environment still running the affected browser components.

That also changes prioritisation logic. A KEV-listed browser flaw should be handled ahead of ordinary backlog items because exploitation can happen through routine user activity, especially where browsing is still allowed on systems with elevated business access or weak hardening.

Why browser type confusion is dangerous

Type confusion flaws are dangerous because they can let attacker-controlled content make the browser interpret one object as another, which can break memory safety and lead to remote code execution. In practical terms, that means a malicious page, ad, or embedded content path may be enough to trigger code execution without any unusual user decision beyond opening the content.

For internet-facing browsing stacks, this is especially concerning because browsers sit at the intersection of user interaction, script execution, plugins, rendering, and access to local system resources. When the flaw is in shared rendering components such as mshtml.dll, the blast radius can extend beyond a single page to multiple browser surfaces that rely on the same engine.

How to confirm exposure and reduce blast radius

Start by confirming whether any supported or unsupported systems still expose Microsoft Edge or Internet Explorer paths that can invoke the vulnerable rendering engine. Legacy browser compatibility modes, intranet dependencies, and long-tail desktop estates often hide exposure long after the browser is thought to be retired.

Then reduce blast radius while remediation is being prepared. Limit general web browsing from privileged workstations, review browser hardening settings, and remove unnecessary legacy browser use from high-value endpoints. If the vulnerable browser path cannot be eliminated immediately, contain it with tighter application control, isolation, and user privilege boundaries. The Enterprise Browser and Browser Security Guide is useful here because browser hardening only works when policy, extension control, and isolation are all treated as one control set.

Risk and Threat Considerations

Browsers are a high-value exploitation surface because they are both widely reachable and deeply trusted. A remotely exploitable browser flaw can become an initial access path, a drive-by compromise route, or a stepping stone into higher-value internal resources if the endpoint has cached credentials, active sessions, or broad network reach.

Failure mechanism: An attacker delivers content that triggers the type confusion condition in the rendering engine, causing memory corruption and enabling code execution in the browser context.

Impact: The result can be endpoint compromise, credential theft, session hijacking, malware installation, or follow-on movement into internal systems if the host has privileged access or trusted session state.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Browser hardening and legacy-path reduction are configuration controls.
	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation demands prioritised identification and remediation.
Recommendation — Harden browser settings and remove legacy browser paths from managed endpoints. Prioritise and remediate KEV-listed browser vulnerabilities first.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires urgent remediation of an actively exploited flaw.
	SI-3 — Malicious Code Protection	Web-delivered browser exploitation can lead to malicious code execution on endpoints.
	AC-6 — Least Privilege	Reducing browser blast radius depends on limiting the privilege of exposed endpoints.
Recommendation — Remediate the flaw quickly and track exception handling until closure. Use endpoint protections to block or detect malicious payload delivery. Restrict user and workstation privileges to limit exploit impact.

Practitioner Guidance

What to verify: Confirm that the vulnerable browser path is actually removed or remediated on all managed endpoints, including systems that are still used for intranet, finance, admin, or legacy application access. For browser exploits, “patched somewhere” is not enough if the affected path still exists on older desktops or unmanaged devices.

Decision rule: If patching is delayed, treat the device as temporarily high-risk and narrow what it can reach rather than assuming users will avoid the trigger condition. For systems with elevated access, prioritise isolation, session separation, and stricter browser policy before accepting any delay in remediation.

Practitioner takeaway: A KEV-listed browser vulnerability should be managed as active exposure, not as a routine software defect, because the real control objective is to stop a web-delivered exploit from turning a normal browsing session into endpoint compromise.