CVE-2013-1347: Microsoft Internet Explorer Remote Code Execution Vulnerability
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.
CVE-2013-1347: Microsoft Internet Explorer remote code execution
CVE-2013-1347 is a remote code execution vulnerability in Microsoft Internet Explorer. Public detail describes it as a flaw that may corrupt memory so an attacker can run arbitrary code in the context of the current user inside the browser.
It matters because successful abuse can give an attacker the same privileges as the logged-on user on a workstation or terminal that still runs the affected browser. Teams should treat it as a high-priority browser risk until systems are confirmed patched or otherwise controlled.
How it works
The weakness is classified as CWE-94 (improper control of code generation / code injection). In this case the CISA summary states the vulnerability may corrupt memory in a way that could allow arbitrary code execution within Internet Explorer under the current user’s context.
At a high level, an attacker who can cause the browser to process attacker-controlled content (for example via a malicious or compromised web page) may trigger the memory-corruption condition. If exploitation succeeds, code runs with the privileges of the user who opened the browser, not necessarily elevated system privileges. Exact trigger conditions, affected rendering paths, and exploit mechanics are not detailed in the provided facts; confirm those against the vendor advisory.
Am I affected? How to find it in your systems
Internet Explorer historically shipped with Windows client and server SKUs and was often the default or enterprise-mandated browser. It may still appear on legacy desktops, VDI images, kiosks, or applications that embed the IE engine (for example via WebBrowser controls or older ActiveX-dependent line-of-business apps).
Practical inventory steps:
- Enumerate installed browsers and IE feature versions across endpoints (software inventory, SCCM/Intune/MECM, or equivalent asset tools).
- Identify systems where IE is still enabled, set as default, or required by internal applications; note any Group Policy or AppLocker rules that still permit it.
- Check whether the Microsoft security update that addresses CVE-2013-1347 is present; exact build and patch identifiers must be confirmed against the vendor advisory.
- Review proxy, web gateway, and endpoint logs for unusual IE process crashes, unexpected child processes spawned from iexplore.exe, or repeated visits to untrusted sites that coincide with those crashes. These are generic signs of browser exploitation attempts, not proof of this CVE alone.
If public detail on exact versions is limited in your records, treat any unpatched IE installation as potentially in scope until the vendor advisory is checked.
How to remediate
Patch first. Apply the updates Microsoft released for this vulnerability, following the vendor’s instructions (CISA required action: apply updates per vendor instructions). Confirm installation via your patch-management console or by verifying the corresponding security bulletin/KB on representative systems.
After patching:
- Retire or disable Internet Explorer where business needs allow; move users to a currently supported browser.
- Remove or isolate legacy applications that embed the IE rendering engine; recompile or reconfigure them to use a supported webview if possible.
- Enforce least privilege so that even if browser code execution occurs, the user account cannot make lasting system changes.
- Keep OS and browser components on a regular update cadence and validate that automatic updates are not blocked on legacy images.
If you can't patch immediately
Use compensating controls to reduce exposure until the vendor update can be deployed:
- Network segmentation and egress filtering: limit workstations that still run IE from reaching untrusted internet content; force browsing through a secure web gateway.
- Virtual patching / WAF or proxy rules: block or tightly scrutinize content patterns associated with IE memory-corruption exploits if your security vendor provides signatures for this class of issue; tune to minimize false positives.
- Disable or restrict the affected feature: use software restriction, AppLocker, or Windows policies to prevent launch of iexplore.exe for users who do not require it; prefer enterprise mode or site lists only where absolutely necessary and only after risk acceptance.
- Enhanced monitoring: alert on IE process anomalies, unexpected network connections from the browser, and credential or lateral-movement activity originating from hosts that still run IE.
- User isolation: run remaining IE-dependent tasks in locked-down VDI or application virtualization with no persistent local admin rights and rapid image refresh.
These measures lower likelihood and impact but do not replace the vendor patch.
If your data may have been exposed
Actively exploited browser vulnerabilities can lead to endpoint compromise and subsequent data theft or further intrusion. The provided facts do not document ransomware use for this CVE. If you suspect exploitation, isolate affected hosts, preserve volatile evidence, credential-reset the involved user accounts, and follow your incident-response process. You can also run a free exposure scan of your email addresses against known breach datasets to see whether associated credentials or personal data have appeared in prior public breaches, then force password changes and enable multi-factor authentication where those identities are still in use.
AICompiled with AI assistance from public sources and published under our editorial standards.