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

What matters first when patching Internet Explorer

Start with exposure, not the bulletin. Find every place Internet Explorer still exists in your environment, including legacy desktops, VDI images, kiosks, and any system that still launches IE through compatibility or embedded workflows. If the browser is installed but no longer needed, removing it or preventing internet access is often safer than carrying an exception while you wait for a patch window.

Patch management here is really asset management plus containment. A vulnerable browser on an isolated, tightly controlled host is a different problem from the same browser on a user workstation that reaches email, the web, and internal portals. For that reason, inventory and exposure reduction should happen before you assume the security update alone is enough.

How to apply the vendor fix without creating a gap

Follow the vendor security update or documented mitigation exactly as published for the affected Internet Explorer instance. If the product is still in service, treat the update as a priority change and confirm the system actually receives the fix rather than relying on the patching ticket alone. The operational risk is usually not the absence of a patch, but the false assumption that a shared image, old clone, or exception-covered endpoint was included.

When a fix is available but deployment is constrained, use the shortest possible exception path. That means limiting who can reach the host, reducing or removing internet exposure, and blocking any workflow that depends on the vulnerable browser for general web access. This is especially important on systems that are hard to rebuild or that support older enterprise applications, because those are the places where unpatched exposure tends to persist longest.

For readers who need a broader patching process behind this decision, the Vulnerability Management Guide is useful because it ties vulnerability discovery, prioritisation, verification, and exception handling into one operational loop.

How to verify compromise and close the loop after remediation

After patching or mitigation, review logs for signs that the flaw may already have been used. That review should focus on the affected host, the user context involved, and any suspicious browser-launched process activity around the exposure window. If the system handled sensitive sessions or reached privileged internal resources, assume the browser may have been a stepping stone rather than the final target.

Use the remediation event to check whether the host was also used for lateral movement, credential capture, or follow-on payload execution. If you find indicators of earlier exploitation, treat the incident as a compromise investigation, not just a patch verification exercise. In that case, the right question is not only whether the vulnerability is closed, but whether anything else was taken while it was open.

For a disciplined browser hardening baseline that helps reduce repeat exposure, the Enterprise Browser and Browser Security Guide is useful because browser policy, isolation, extension control, and credential-theft reduction are often the controls that make a delayed patch survivable.

Risk and Threat Considerations

An actively exploited remote code execution flaw in a browser is dangerous because it can turn ordinary web access into code execution with the privileges of the user who opened the page. That makes exposure especially consequential on endpoints that still browse the internet, handle email, or access internal business systems from a compromised desktop.

Failure mechanism: an attacker can deliver malicious content through normal browsing, trigger code execution in the browser process, and then use that foothold to run additional payloads, steal data, or pivot into the rest of the environment.

Impact: the practical outcome can range from endpoint compromise to credential theft, persistence, and broader network exposure, especially where the affected browser has access to sensitive applications or shared accounts.

Practitioner Guidance

What to verify: confirm that every surviving Internet Explorer instance is either updated per vendor instructions or isolated well enough that the browser no longer has uncontrolled internet access. Do not trust a patch record until you have checked the actual endpoint, image, or package source that users depend on.

Escalation / exception: if a business workflow still depends on Internet Explorer, treat that as a risk acceptance decision with compensating controls, not as a normal operating state. The longer the exception lives, the more likely the host becomes a soft target for drive-by compromise or follow-on abuse.

Practitioner takeaway: the safest remediation path is usually to remove the browser from routine internet use first, then verify the update, then look for signs of earlier abuse, because patching alone does not tell you whether the vulnerability was already used.

Related resources from NHI Mgmt Group

• How do you patch or mitigate CVE-2013-1347 (Microsoft Internet Explorer Remote Code Execution)?
• How do you patch or mitigate CVE-2017-8543 (Microsoft Windows Search Remote Code Execution)?
• How do you patch or mitigate CVE-2017-0148 (Microsoft SMBv1 Server Remote Code Execution)?
• How do you patch or mitigate CVE-2017-11826 (Microsoft Office Remote Code Execution)?