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

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

The safest interpretation of CISA’s instruction is simple: treat this as an exposure-management task, not just a patch ticket. Inventory every Internet Explorer installation, confirm whether the vendor update or mitigation is already in place, and verify that systems still relying on IE are not left exposed in production. If you are tracking broader patch discipline, the Vulnerability Management Guide is the right companion reference for prioritisation, exceptions, and verification.

Because the flaw was exploited in the wild, the practical question is not only whether the fix was deployed, but whether the affected endpoint or user environment has been removed from the attack path. If the product cannot be updated cleanly, the mitigation path should focus on reducing reachability, reducing use, and removing the software from service wherever possible. For browser-specific hardening and isolation measures that reduce the blast radius of legacy browsing, see the Enterprise Browser and Browser Security Guide.

After remediation, validate the outcome operationally rather than assuming the change succeeded. That means checking the affected estate for residual IE usage, confirming the vulnerable component is no longer reachable in the normal user workflow, and reviewing security and application logs for signs of pre-patch exploitation or follow-on activity. If there is any evidence of suspicious browser activity, treat it as a compromise review, not a routine patch-verification exercise.

What to do when you cannot patch immediately

If patching must wait, the mitigation decision should be driven by exposure, not convenience. Reduce or remove internet-facing access first, then limit user pathways that can launch or invoke the product, and treat any remaining use as temporary exception handling with explicit owner approval. The objective is to make exploitation materially harder while you keep the path to full remediation short and accountable.

When the software still has a business dependency, the key control question is whether that dependency can be isolated enough that the vulnerable browser is not a general-purpose internet client. In practice, this usually means narrowing where it can run, what it can reach, and which users can trigger it. If those boundaries cannot be enforced, the exception is materially higher risk and should be escalated rather than accepted as a routine delay.

For public confirmation of the vulnerability record and CISA’s remediative guidance, use the CVE Program and the CISA Known Exploited Vulnerabilities Catalog rather than relying on memory or internal notes. Those sources are the authoritative anchors for validating the record and tracking remediation expectations.

How to confirm whether exploitation may have already happened

Once a flaw is known to be exploited, remediation and compromise review belong together. Look for unusual browser launches, suspicious child processes, strange outbound connections, and other signs that the browser was used as the initial access path. If the vulnerable system had access to sensitive internal resources, widen the review to include credentials, sessions, and any downstream systems that may have been reached from that endpoint.

Do not limit the review to the patched machine alone. In a real incident, the important question is whether the browser flaw created a path into a user context, a workstation, or a session that could then be abused for later movement or data access. Where the browser had access to saved secrets, authenticated sessions, or privileged internal applications, the compromise review should include those exposures as part of the investigation.

Risk and Threat Considerations

Legacy browser vulnerabilities are risky because they often sit at the boundary between user activity and direct code execution or information disclosure. When the software is still reachable, an attacker can turn a simple browsing action into a foothold, a data leak, or a launch point for broader compromise.

Failure mechanism: The flaw remains exploitable because the vulnerable browser is still installed, still invoked, or still allowed to reach untrusted web content, so the attacker can trigger the weakness before defenders have removed the exposure.

Impact: A successful exploit can expose information, enable follow-on access, and create a starting point for further intrusion, especially if the browser session or endpoint already has access to internal applications or stored secrets.

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	Patch and verify exploited software quickly.
Recommendation — Prioritise vulnerable browser instances for rapid remediation and exception tracking.
NIST CSF 2.0	PR.IP-12 — Vulnerability management plan is implemented	This is a classic remediation-and-verification vulnerability case.
	RS.MA-1 — Incidents are contained	Post-patch log review and exposure removal support containment of possible exploitation.
Recommendation — Use a managed remediation process to track exposure, fixes, and verification. Contain affected systems and investigate for signs of prior exploitation.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Confirm exposure and validate remediation of the browser CVE.
	SI-2 — Flaw Remediation	The core action is vendor-directed updating or mitigation.
Recommendation — Scan for remaining IE exposure and verify remediation status across the estate. Apply the vendor update or approved mitigation without delay.

Practitioner Guidance

What to prioritise: Patch the highest-exposure Internet Explorer instances first, especially any endpoint that can still reach the internet or business-critical internal systems. If the environment has both modern browsers and legacy IE dependencies, treat the legacy path as the exception to eliminate, not the normal path to maintain.

What to verify: Confirm both the vendor update status and the actual runtime condition, meaning the browser is not merely patched on paper but no longer present in user workflows that can be abused. After that, validate logging coverage so you can prove whether suspicious activity occurred before remediation.

Decision rule: If you cannot patch a system in a reasonable window, remove its internet exposure or take it out of service. If you cannot do either, treat the exception as a security risk requiring explicit escalation, not as an acceptable long-term mitigation.

Practitioner takeaway: For an exploited browser CVE, the real control is not patching alone, it is removing the reachable attack path and then checking whether that path was already used.