How do you patch or mitigate CVE-2013-1347 (Microsoft Internet Explorer Remote Code Execution)?

CISA’s required action for CVE-2013-1347 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 CVE-2013-1347 should look like in a real estate

The practical fix is straightforward but operationally broad: inventory every Internet Explorer installation, apply the vendor update or documented mitigation, and then verify that the affected systems no longer remain exposed to the internet. For a browser RCE, patching is only complete when the vulnerable product is either corrected or removed from reachable use.

In a large environment, the main challenge is not the update itself, but proving you found every instance. Browser binaries can remain on legacy endpoints, embedded in older operating system builds, or preserved for compatibility, so the remediation plan should assume hidden exposure until inventory says otherwise.

Why exposure reduction matters when patching is delayed

If you cannot patch immediately, the safest temporary position is to shrink exposure rather than hope the vulnerable browser is never reached. That can mean removing internet access, disabling the product where business use allows it, or pushing users toward a non-vulnerable browsing path until the vendor fix is in place.

For a remote code execution flaw, the question is not only whether the vulnerability exists, but whether an attacker can still trigger it. Any control that blocks reachable attack paths buys time, but it should be treated as a stopgap, not a substitute for remediation.

Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog as your authoritative references for remediation priority and required action, then map those instructions onto your own asset inventory and change process.

What to check after remediation

Once patching or mitigation is complete, validate two things: first, that the vulnerable browser is no longer present or reachable in the intended scope; second, that there are no signs it was used before the fix landed. For a flaw that was exploited in the wild, post-fix review is part of remediation, not an optional follow-up.

Log review should focus on suspicious browser activity, unexpected child processes, unusual script execution, abnormal downloads, and evidence of compromise around the time the vulnerable systems were exposed. If you find indicators of compromise, treat the event as a potential endpoint or user-compromise investigation, not just a patching task.

Risk and Threat Considerations

Browser RCE is high-risk because the attack surface is broad and user-driven. If Internet Explorer remains reachable on any system, an attacker may need only a convincing delivery path, then code execution can follow without additional user-privilege barriers.

Failure mechanism: The exploit path persists wherever the vulnerable browser remains installed and reachable, especially on systems that still allow web content from untrusted sources or legacy internal applications that invoke the browser.

Impact: Successful exploitation can lead to arbitrary code execution on the endpoint, followed by malware installation, credential theft, lateral movement, or further compromise of the host and its connected accounts.

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 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-7 — Continuous Vulnerability Management	CVE patching and exposure review are core vulnerability management tasks.
Recommendation — Prioritise remediation, verify exposure, and track closure for the vulnerable browser fleet.
NIST CSF 2.0	PR.PS-03 — Least Functionality	Removing or disabling Internet Explorer where patching lags reduces attack surface.
	DE.CM-08 — Vulnerabilities are monitored and validated	Post-fix validation and compromise review depend on active vulnerability monitoring.
Recommendation — Restrict legacy browser availability to the minimum required systems. Validate remediation and investigate exposed systems for signs of exploitation.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about applying vendor updates or mitigations for a known exploited flaw.
	AU-6 — Audit Record Review, Analysis, and Reporting	Log review is needed to detect earlier exploitation after patching.
Recommendation — Apply the vendor fix or documented mitigation and confirm it across all affected assets. Review security logs for indicators of compromise after remediation.

Practitioner Guidance

What to prioritise: Start with the endpoints that are both internet-reachable and still capable of launching Internet Explorer, because those systems preserve the shortest attack path. Legacy compatibility exceptions deserve the highest scrutiny, since they are often the places where exposure survives longest.

What to verify: Confirm that your fix is not just deployed, but effective in the field. You should be able to demonstrate asset coverage, change completion, and a check for pre-existing compromise on the same population that was exposed.

Practitioner takeaway: For an exploited browser RCE, the real remediation decision is whether the vulnerable software is still reachable anywhere, because patching without exposure verification leaves the original attack path intact.