Is CVE-2013-1347 (Microsoft Internet Explorer Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2013-1347 to its Known Exploited Vulnerabilities catalogue on 3 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. This vulnerability may corrupt memory in a way that could allow an attacker to execute arbitrary code in the context of the current user within Internet Explorer.

What it means when Microsoft Internet Explorer is on the KEV catalogue

For this question, the key point is not the browser name alone, but what CISA’s Known Exploited Vulnerabilities catalogue signals: there is reliable evidence that the flaw has been used in real attacks. That makes this an exploitation-status question, not a theoretical vulnerability question. The practical response is to treat affected systems as exposed until proven otherwise.

Because the issue is a remote code execution condition in a browser component, exposure is driven by whether Internet Explorer is still reachable in your environment, whether legacy compatibility paths remain enabled, and whether users or systems can still invoke the vulnerable code path. In practice, that means inventory and usage validation matter as much as patch status.

How to confirm exposure and shorten the window of risk

First confirm whether Internet Explorer is still present, callable, or indirectly available through enterprise compatibility settings, old workflows, or embedded web rendering dependencies. Then verify whether the vulnerable build is still installed anywhere that matters operationally, including long-lived desktops, kiosk systems, shared machines, and legacy application endpoints.

If exposure exists, use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog for authoritative patch and remediation guidance rather than relying on secondary summaries. For vulnerability lifecycle handling, the NIST National Vulnerability Database and the CVE Program help anchor the record, while exploitability triage is often strengthened by the FIRST EPSS prioritisation model.

What to do if patching or removal must wait

When immediate remediation is not possible, reduce exposure by removing browser use from sensitive workflows, disabling the vulnerable path where your environment permits it, and isolating users or systems that still need legacy access. For a browser RCE, compensating controls should focus on reducing code execution opportunities, not just on alerting after the fact.

That often means treating browser hardening, application isolation, and tight endpoint policy as temporary risk controls. The Enterprise Browser and Browser Security Guide is useful here because it frames browser policy, isolation, and extension control as a practical containment layer when legacy browsing cannot be eliminated immediately.

Where the environment still depends on Internet Explorer for business functionality, compartmentalise that dependency so a compromise in one session cannot easily become broad workstation or credential compromise. In other words, reduce the blast radius while you complete remediation.

What to check after possible exploitation

If the vulnerable browser was reachable during the exposure window, assume an attacker may have attempted code execution before you confirmed the KEV listing. Validate endpoint telemetry, browser and process logs, suspicious child processes, unusual outbound connections, dropped payloads, and unexpected privilege changes on the affected systems.

For any device that handled privileged access, sensitive portals, or administrative sessions, review whether browser-based compromise could have exposed credentials, tokens, or active sessions. The most important question is not only whether the vulnerability ran, but what trust material or authenticated access it may have put at risk.

Risk and Threat Considerations

A browser remote code execution flaw is especially dangerous because the attacker’s entry point is ordinary user activity, which can make exploitation blend into normal browsing. Once arbitrary code runs in the user context, the next step is often credential theft, lateral movement, or installation of additional payloads if the endpoint is not well contained.

Failure mechanism: The vulnerable component processes malicious content in a way that corrupts memory and permits execution of attacker-controlled code in the browser process or the current user context. If the user has access to internal systems, that access can become the attacker’s foothold.

Impact: Successful exploitation can lead to endpoint compromise, data theft, follow-on malware delivery, and compromise of accounts or sessions used from that workstation. On unmanaged or legacy systems, the real impact is often broader than the browser itself because it becomes a bridge into the rest of the environment.

Standards & Framework Alignment

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

NIST CSF 2.0, 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 CSF 2.0	DE.CM-01 — Security Continuous Monitoring	Detect active exploitation and suspicious browser behavior on exposed endpoints.
	PR.PS-01 — Configuration Management	Reduce exposure by disabling or isolating legacy browser functionality and risky compatibility paths.
Recommendation — Monitor endpoint and browser activity for signs of exploitation and post-exploitation execution. Harden or remove legacy browser paths that keep the vulnerable code reachable.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This is an actively exploited software flaw requiring remediation tracking and rapid correction.
	SI-4 — System Monitoring	Post-exploitation review depends on monitoring suspicious activity after browser compromise.
Recommendation — Patch or mitigate the vulnerability as soon as operationally possible. Inspect endpoint telemetry for exploit traces and suspicious child processes.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The question is about an exploited vulnerability and how to prioritise remediation.
Recommendation — Prioritise and remediate the KEV-listed weakness across all exposed assets.

Practitioner Guidance

What to verify: Confirm whether Internet Explorer is still executable anywhere in scope, whether the vulnerable code path is reachable, and whether the affected hosts are still used for internal or privileged access. If any of those are true, treat the system as materially exposed even before exploitation evidence is found.

Decision rule: If a system can no longer be patched immediately, prioritise isolation and removal of browser-dependent trust paths before spending time on deeper tuning. If the device also holds privileged access or handles sensitive sessions, escalate the remediation priority because the compromise impact is much larger than a simple endpoint incident.

Practitioner takeaway: For KEV-listed browser flaws, exploitability status is only the starting point, the real operational question is how much access the vulnerable browser can still reach before containment or removal closes the door.