How do you patch or mitigate CVE-2017-0059 (Microsoft Internet Explorer Information Disclosure)?

CISA’s required action for CVE-2017-0059 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-2017-0059 should look like in practice

The first step is inventory, because mitigation only works if you know where Microsoft Internet Explorer still exists in your environment. Treat the vendor update as the preferred fix, then verify that every affected system actually received it, including older endpoints, virtual desktops, and any host where IE is present but not actively used.

If you cannot patch immediately, reduce exposure instead of leaving the browser reachable from normal user workflows. That usually means removing internet access paths, disabling or restricting use where possible, or taking the product out of service until the vendor update or documented mitigation is applied.

For teams managing browser exposure more broadly, the same hardening mindset that applies to browser policy and extension control is useful here as well, because exposed browsers are often only one click away from credential theft and follow-on compromise. See the Enterprise Browser and Browser Security Guide for the wider control model around browser hardening and isolation.

How to confirm the environment is actually fixed

A patch is only meaningful if you can confirm deployment and observe the result. Check endpoint inventory, vulnerability scan results, and local version evidence rather than assuming a change-management ticket equals remediation. For legacy fleets, confirm that no unsupported or forgotten workstation still exposes Internet Explorer indirectly through compatibility settings or shared images.

Authoritative tracking matters here, so use the CISA Known Exploited Vulnerabilities Catalog to align remediation priority with active exploitation pressure, and use vendor instructions as the source of truth for the exact fix path. If you need a broader patch-management workflow for this class of issue, the Vulnerability Management Guide gives the operational sequence for scoping, prioritising, verifying, and tracking exceptions.

After remediation, review logs and telemetry for prior suspicious browser activity, because CISA tied this issue to real-world exploitation. The practical question is not only whether the patch landed, but whether the system was already used before the fix closed the path.

What to do if exploitation might already have happened

Because the flaw was exploited in the wild, post-fix validation should include a compromise review, not just a patch check. Look for unusual browser process behaviour, odd child processes, unexpected downloads, and signs that the browser was used as a staging point for deeper access or data access.

When the browser is part of a broader identity or session flow, review whether credentials, tokens, or saved browser state may have been exposed and need rotation or invalidation. That is especially important if the affected host was used for administrative access, remote management, or access to sensitive internal applications. In environments where browser-based credential theft is a realistic follow-on, the operational risk is not just the vulnerability itself but the access it can unlock.

Where exposure is recurrent or hard to remove, segment the affected systems and force a decision about retirement versus compensation. Legacy software that cannot be patched reliably should be treated as a control exception with a clear end date, not as a permanent exception because it still works.

Risk and Threat Considerations

Internet Explorer vulnerabilities matter because browsers sit at a high-trust boundary between users, content, and internal resources. A disclosed flaw that is already being used in the wild can turn a routine browsing action into an entry point for information disclosure, follow-on exploitation, or broader compromise if the host has access to sensitive systems.

Failure mechanism: Attackers exploit the browser flaw before patching is complete, then use the exposed host to collect data, pivot to other services, or stage additional activity while defenders still believe the endpoint is only at patch risk.

Impact: The immediate effect may be information disclosure, but the practical consequence can be wider exposure of credentials, session state, or internal access paths, especially on endpoints used for privileged or business-critical work.

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	GV.RM-01 — Risk Management Strategy	CVE response requires prioritising exploited vulnerability risk and exceptions.
Recommendation — Prioritise remediation of exploited browser CVEs within your risk management strategy.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This is a patching and mitigation question for a known vulnerability.
	AU-6 — Audit Record Review, Analysis, and Reporting	Post-patch log review is needed to spot earlier exploitation.
Recommendation — Apply flaw remediation procedures and verify affected hosts are updated. Review audit logs for signs of exploitation before and after remediation.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The answer depends on finding, prioritising, and verifying a known exploited vulnerability.
	CIS-18 — Penetration Testing	Verification and validation of exposure can be strengthened through controlled testing.
Recommendation — Continuously identify, prioritise, and remediate Internet Explorer exposure. Validate remediation with testing and confirm the exposure path is closed.

Practitioner Guidance

What to prioritise: Patch or remove exposure first, then validate with inventory and logs. For exploited browser CVEs, delay in verification is a control failure in itself because the window between vulnerability disclosure and confirmed remediation is where abuse happens.

What to verify: Confirm both technical remediation and operational containment. If a system cannot be patched, document the compensating control, who approved it, and the date by which the system will be removed, isolated, or upgraded.

Practitioner takeaway: For an in-the-wild browser CVE, the real decision is not patch versus wait, it is whether you can prove the exposure is gone and whether the endpoint has already been used as an attack foothold.