CVE-2017-0059: Microsoft Internet Explorer Information Disclosure Vulnerability

CVE-2017-0059 is an information disclosure vulnerability in Microsoft Internet Explorer. A remote attacker can use a crafted website to obtain sensitive information from the browser’s process memory. For IT and security teams, this matters because memory contents can include credentials, tokens, or other data the browser is handling, and exposure can aid further compromise even when full code execution is not involved.

CISA summarizes the issue as allowing remote attackers to obtain sensitive information from process memory via a crafted web site. The required action is to apply updates per vendor instructions. Confirm exact product scope and fixed builds against the Microsoft advisory before treating any host as clear.

How it works

This flaw is classed as CWE-200: exposure of sensitive information to an unauthorized actor. In Internet Explorer, the weakness lets a malicious page cause the browser to reveal data that should stay inside the process address space. An attacker typically lures a user to open or render attacker-controlled content in IE; once the page runs in the browser context, the vulnerability can leak memory contents back to the attacker.

Public detail in the provided record does not describe low-level exploit mechanics, heap layout, or specific APIs. Treat the abuse path as “user visits crafted site → IE discloses process memory.” Do not assume privilege escalation or ransomware delivery from this CVE alone; known ransomware use is not documented for this identifier. Always validate technical depth 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 may still appear where legacy web apps, kiosks, or enterprise line-of-business sites require it. Inventory every Windows endpoint and server that still has IE enabled or set as a default/secondary browser, including VDI images, jump hosts, and older application servers.

• Enumerate installed IE/Trident components and Windows versions via your software inventory, SCCM/Intune/MECM, or equivalent asset CMDB; map results to the CVE’s affected list in the Microsoft advisory.
• Check group policy and browser defaults for continued IE use (including Enterprise Mode or IE mode hand-offs from other browsers if your environment still relies on them).
• Review web proxy, DNS, and endpoint logs for users hitting untrusted or unusual sites in IE processes; look for anomalous IE child processes or unexpected outbound connections after browsing, without treating any single log pattern as definitive proof of this CVE.
• Confirm whether legacy ActiveX or intranet zones are still enabled, as those configurations often keep IE in the attack surface longer than necessary.

If inventory cannot prove a host is outside the advisory’s affected set, assume it needs the vendor update until verified.

How to remediate

Patch first. Apply the Microsoft updates that address CVE-2017-0059 exactly as named in the vendor advisory, following your standard test-and-deploy ring process. CISA’s required action is to apply updates per vendor instructions; do not substitute third-party “unofficial” fixes.

• After patching, verify the update is present (hotfixes/KB level or file versions per Microsoft’s guidance) on a sample of systems.
• Reduce ongoing exposure: migrate remaining IE-only workflows to supported browsers, retire IE where business-justified exceptions no longer exist, and tighten zone/security settings for any residual use.
• Harden the class of issue by limiting who can run IE, removing local admin rights where feasible, and ensuring memory-protection and browser isolation features available on your Windows baseline are enabled—confirm applicability in Microsoft documentation rather than assuming coverage for this CVE.

If you can't patch immediately

Until the vendor update is installed everywhere, shrink the window an attacker has to reach vulnerable IE instances.

• Network segmentation: isolate legacy IE-dependent hosts from general internet egress; allow only required destinations through a controlled proxy.
• Application control: restrict which users and machines may launch iexplore.exe; block IE on systems that do not need it.
• Virtual patching / content filtering: use web gateway or WAF-style controls to block or sandbox known malicious categories and uncategorized sites that target browsers; this is compensating only and must not replace the patch.
• Disable or constrain the affected path: turn off unnecessary IE features, legacy document modes, and broad intranet/trusted-zone relaxations where business process allows.
• Monitoring: alert on IE launching from unusual parent processes, IE reaching rare external domains, or sudden spikes in IE crashes correlated with web browsing—tune to your environment and investigate rather than auto-assuming exploitation.

Revisit compensating controls as soon as the official update can be deployed.

If your data may have been exposed

Actively exploited browser information-disclosure flaws can feed credential theft and follow-on intrusion even when ransomware use is not documented for this CVE. If IE users may have visited untrusted sites before patching, treat possible memory disclosure as a reason to rotate credentials that could have been in browser memory, review access logs for anomalous use of those identities, and continue incident triage per your playbooks. You can run a free exposure scan of your email addresses against known breach data to see whether those identities already appear in public breach corpora and prioritize further monitoring accordingly.