CVE-2017-0222 is a remote code execution vulnerability in Microsoft Internet Explorer. CISA added it to the Known Exploited Vulnerabilities catalogue on 25 February 2022, which means attackers have used it in real attacks. A remote code execution vulnerability exists when Internet Explorer improperly accesses objects in memory.
What This Vulnerability Means in Internet Explorer
CVE-2017-0222 is a remote code execution flaw in Microsoft Internet Explorer, which means maliciously crafted content can trigger code execution in the browser process. The dangerous part is not just a crash, but the possibility that attacker-controlled input can influence memory handling and turn a browsing action into system compromise.
That matters because browser exploitation often begins with something ordinary, such as a user visiting a site or opening content that renders in the browser. When memory corruption is the underlying weakness, attackers may be able to move from initial delivery to code execution without needing a second, visible step from the victim.
Why This Class of Flaw Is Dangerous
Remote code execution in a widely deployed browser is valuable to attackers because browsers sit at the edge of user trust and often have access to authenticated sessions, internal web apps, and locally available data. A successful exploit can become a launch point for follow-on activity such as credential theft, malware installation, or lateral movement.
The exact impact depends on the attacker’s post-exploitation choices and the protections around the endpoint, but browser RCE is rarely a standalone event. It is usually an entry mechanism, not the end state, and the broader compromise can extend far beyond the browser itself.
How Organisations Check Exposure
Exposure review starts with knowing where Internet Explorer still exists in the environment, including managed desktops, legacy application hosts, virtualised user environments, and systems that still rely on IE compatibility modes or embedded web components. Asset inventory and software inventory are the first line of defence.
Organisations should then confirm whether the vulnerable browser is still internet-facing or reachable through common user workflows, and whether vendor guidance or enterprise update channels indicate that the affected configuration is still present. For authoritative version and patch details, use the vendor advisory and the NIST National Vulnerability Database, alongside the CVE Program record and the CISA KEV catalogue referenced in the primary definition.
Remediation, Detection, and Recovery
When patching is delayed, compensating controls matter: restrict browser use to only the systems and workflows that still require it, reduce exposure to untrusted web content, and harden endpoint protections so a single browser exploit is less likely to become full compromise. Legacy browser dependencies should be treated as an exception path, not an accepted default.
Detection should look for unusual browser-child process behaviour, suspicious script activity, payload delivery shortly after web access, and signs that a browser session was used to initiate secondary execution. After patching, teams should review the endpoint for persistence, unusual new processes, dropped files, and any indicators that the exploit chain continued beyond the browser session.
Risk and Threat Considerations
This vulnerability is especially concerning because browser exploitation can look like normal web usage until execution occurs. If an attacker can trigger code in Internet Explorer, the browser becomes a trusted foothold for stealing data, launching payloads, or pivoting into other internal resources.
Failure mechanism: The memory handling flaw lets attacker-controlled content corrupt execution flow, so a browser interaction can become arbitrary code execution.
Impact: A successful exploit can expose credentials, sessions, internal applications, and the endpoint itself to follow-on compromise.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while 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 SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Browser RCE exposure depends on timely vulnerability remediation. |
| SI-3 — Malicious Code Protection | Exploit delivery and payload execution are best reduced by malware protections. | |
| AU-6 — Audit Record Review, Analysis, and Reporting | Post-exploitation review relies on logs that reveal suspicious browser and process activity. | |
| Recommendation — Patch the affected browser and track remediation until the flaw is fully removed. Enforce malicious code protections on endpoints that can load untrusted web content. Review endpoint and browser logs for execution chains that follow web access. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Known exploited browser flaws require inventory and prioritised remediation. |
| Recommendation — Continuously inventory browsers and prioritise remediation for exposed IE systems. | ||
| MITRE ATT&CK | T1203 — Exploitation for Client Execution | Browser RCE is a client-side exploitation path that leads to code execution. |
| Recommendation — Map browser exploit telemetry to client-execution techniques and hunt for post-exploit activity. | ||
Practitioner Guidance
Why practitioners should care: Treat any remaining Internet Explorer dependency as a security exception with an expiry date, not as a harmless legacy convenience. If the browser must remain available, limit its use to the smallest possible set of users and workflows, then monitor those systems more closely than standard endpoints.
What to watch for: Repeated browser-based exploitation attempts, unusual process creation immediately after web activity, and endpoints that still depend on IE for business functions are all signals that exposure may be broader than expected. Where possible, move users to supported browsers and retire IE-specific dependencies rather than preserving them indefinitely.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org