How do you patch or mitigate CVE-2015-2387 (Microsoft ATM Font Driver Privilege Escalation)?

CISA’s required action for CVE-2015-2387 is to apply updates per vendor instructions. In practice, find every instance of Microsoft ATM Font Driver 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 matters when patching an exploited Microsoft font driver flaw

The first task is exposure confirmation, not generic patch management. Identify every Windows system where the Microsoft ATM Font Driver is present, then verify whether the vendor update or mitigation can be applied cleanly. If the system cannot be patched immediately, the practical decision is to reduce exposure by removing internet reachability or taking the product out of service until it is remediated.

Zero-Day and Exploited Vulnerabilities Guide is the right home base for this response pattern because the issue is already known to have been exploited in the wild and needs urgent triage, not routine backlog handling.

That response should be asset-specific. A system with the vulnerable component exposed to hostile input or broad user access deserves faster containment than an isolated internal host. In practice, the patch decision and the temporary containment decision should be made together so teams do not wait for a perfect maintenance window while an exploitable system stays live.

How to verify remediation and look for signs of compromise

After applying updates or a documented mitigation, verify that the vulnerable component is no longer present in the affected configuration and that the system is returning expected behavior. For an exploited flaw, remediation is incomplete until you have checked whether earlier compromise occurred before the fix was applied.

For this kind of vulnerability, the post-fix check is not only “did the update install,” but also “did the attacker already use it.” Review logs, authentication events, process activity, and any unusual privilege changes around the exposure window. If the host was reachable from the internet or from untrusted segments, treat the probability of prior probing as higher and widen the review accordingly.

CISA Known Exploited Vulnerabilities Catalog matters here because a KEV-listed flaw should be handled as an active exploitation problem, not as a theoretical patching task.

NIST National Vulnerability Database helps teams confirm the exact CVE record and track the vulnerability’s technical description while they validate which assets are still exposed.

What to do when patching has to wait

If patching cannot happen immediately, mitigation should focus on shrinking attack surface and blast radius. Remove the affected system from internet exposure where possible, limit who can reach it, and avoid leaving the vulnerable service in a broadly accessible state while the fix is pending. If the product is no longer needed, retirement is safer than deferring remediation indefinitely.

Use the delay to gather evidence and prepare for rapid rollback if the update changes behavior unexpectedly. In high-pressure remediation, the main mistake is to treat “temporary” mitigation as a permanent answer. A mitigation that leaves the vulnerable component reachable is only acceptable as a short bridge to full remediation.

Vulnerability Management Guide is useful here because the decision is not just patching, it is also scoping, prioritisation, exception handling, and post-remediation verification.

FIRST EPSS is a useful prioritisation aid when you are deciding whether this flaw should jump ahead of less urgent backlog items while you wait for a maintenance window.

Risk and Threat Considerations

This flaw is risky because exploitation was observed in the wild, so a reachable unpatched host is already in the attacker’s target set. The operational danger is not just service disruption, but silent compromise before the organisation realises the asset was exposed.

Failure mechanism: A vulnerable font driver exposed to attacker-controlled input can be used to gain elevated execution on the target system, especially when the host remains reachable and unremediated.

Impact: Successful exploitation can lead to local privilege escalation, follow-on credential theft, persistence, and broader compromise of nearby systems if the host is used as a foothold.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 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	This is a live exploited vulnerability needing rapid identification and remediation.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Mitigation may require removing exposure or decommissioning the product configuration.
Recommendation — Prioritise and remediate the affected hosts through continuous vulnerability management. Harden or remove the exposed software configuration until the update is applied.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is explicitly about applying vendor updates or mitigations for a known flaw.
	RA-5 — Vulnerability Monitoring and Scanning	You must find every affected instance and verify exposure before and after remediation.
	AU-6 — Audit Review, Analysis, and Reporting	Post-patch log review is needed to check for earlier exploitation.
Recommendation — Apply the vendor update or approved mitigation and track remediation to completion. Scan for every instance and validate that exposed systems are no longer vulnerable. Review audit logs for signs of exploitation before the fix was installed.

Practitioner Guidance

What to prioritise: Patch or mitigate every exposed instance first, then handle internal-only systems that have lower exposure. If you have to stage remediation, start with hosts that are internet-facing or support privileged users, because those are the most consequential if exploitation has already begun.

What to verify: Confirm both remediation and absence of prior compromise. Look for suspicious logons, new processes, unexpected privilege changes, and signs that the vulnerable system was touched before patching. If those signals exist, treat the event as incident response rather than ordinary maintenance.

Practitioner takeaway: For actively exploited vulnerabilities, speed matters, but confirmation matters just as much, because a patched host can still be a compromised host.