On March 23, 2020, Microsoft dropped an urgent security advisory that shattered the routine Patch Tuesday rhythm. Attackers were already exploiting two previously unknown vulnerabilities in the Adobe Type Manager Library, a font-parsing component buried deep inside every supported version of Windows. The flaws—later cataloged as CVE-2020-0938 and CVE-2020-1020—allowed remote code execution (RCE) simply by tricking a user into previewing a weaponized font file, no double-click required. In an era of relentless phishing and drive-by attacks, a zero-day that sidesteps even cautious clicks is a nightmare for defenders.

The advisory, ADV200006, arrived without a patch. Instead, Microsoft outlined temporary workarounds and promised a fix by the next security update. For security teams, the message was blunt: until that fix lands, disable the Windows Preview Pane, or risk having a malicious font take over your machine.

The Lingering Ghost of Adobe Type Manager

Adobe Type Manager, or ATM, is a venerable piece of code that Microsoft licensed decades ago to render PostScript Type 1 fonts on screen and in print. Despite the font industry’s shift to OpenType and ClearType, the ATM library (atmfd.dll) persisted in Windows to ensure backward compatibility with older documents. By 2020, its presence was an anachronism—a trusted component that few users knew existed, yet one that handled untrusted input from everyday file operations.

ATM processes fonts when the operating system needs to display them. This includes the thumbnails and previews shown in File Explorer’s Preview Pane, the details pane, and even the icons on the desktop. A specially crafted font file—embedded inside a document or disguised as a harmless attachment—can trigger memory corruption in the parsing engine, hijacking the flow of execution before any warning appears.

Two Vulnerabilities, One Dangerous Pattern

The two CVEs shared a common attack surface but differed in technical execution. CVE-2020-0938 was a vulnerability in the Adobe Type Manager Library itself, where an improper handling of objects in memory could lead to arbitrary code execution. CVE-2020-1020 was a related flaw in how the Windows Adobe Type Manager Library processed Multi-master fonts—a subset of Type 1 fonts—opening a different path to the same catastrophic outcome.

Both were classified as “Important” on the severity scale, with CVSS scores above 7.8. But the active exploitation pushed their real-world urgency into “critical” territory. Microsoft’s advisory noted “limited targeted attacks” against some Windows 10 and Windows 7 systems. The attackers were careful, choosing victims and environments that maximized their chances while staying under the radar.

The Preview Pane: A Silent Attack Vector

What made these vulnerabilities particularly insidious was the exploitation method. The Preview Pane in File Explorer, enabled by default in most Windows installations, automatically renders content when a file is selected. If that file contains a malicious font, the ATM library jumps into action—parsing the font to generate a preview—and hands the attacker control. The victim need only navigate to a folder containing the malicious file. No attachment opening, no macro warning.

Microsoft specifically warned that the Preview Pane and Details Pane were attack vectors. Even WebDAV shares could be abused: a remote attacker could host a crafted font file on a web server and trick a user into browsing to it via File Explorer. This web-based attack scenario broadened the threat beyond email attachments to drive-by scenarios.

Immediate Workarounds: A Stopgap Defense

Because no patch was available, Microsoft published a set of workarounds in ADV200006 that required administrative action:

  • Disable the Preview and Details panes in File Explorer. This prevented automatic rendering of font data when files were selected. The process involved changing Explorer settings via the View tab or Group Policy.
  • Disable the WebClient service. This blocked the WebDAV attack vector, stopping remote font parsing from internet sources.
  • Rename atmfd.dll. By renaming the vulnerable library (typically located in C:\Windows\System32 or C:\Windows\SysWOW64), the OS could no longer parse Type 1 fonts. This drastic measure broke legacy font-dependent applications but effectively closed the hole.

These mitigations were far from ideal. Disabling preview panes reduced user productivity, and renaming system DLLs risked application instability. For enterprises with thousands of endpoints, deploying such changes quickly was a logistical headache. Many administrators grumbled that a core OS component licensed from a third party had remained unhardened for years.

The Fix Arrives: April 2020 Patch Tuesday

On April 14, 2020, Microsoft released a comprehensive security update that patched both CVE-2020-0938 and CVE-2020-1020. The fixes were bundled in the monthly cumulative updates for all supported Windows editions:

  • Windows 10 1909/1903: KB4550945 (build 18363.720/18362.720) or the earlier KB4550929
  • Windows 10 1809: KB4549949
  • Windows 10 1803: KB4550922 (for Enterprise/Education)
  • Windows 8.1 / Server 2012 R2: KB4550961 (Monthly Rollup)
  • Windows 7 SP1 (ESU): KB4550964 (Monthly Rollup)

For older systems enrolled in Extended Security Updates (ESU), critical patches like these were a lifeline. Those without ESU were left exposed—a stark reminder that end-of-life software, even with known zero-days, gets no help.

The updates also fixed a third font-related RCE, CVE-2020-0935, in the Windows Font Driver Host, along with dozens of other bugs. But the ATM zero-days were the headline act.

A Familiar Pattern: Font Flaws Through the Years

The 2020 zero-days were not isolated incidents. Font parsing has long been a weak spot in Windows security architecture. In 2015, a critical OpenType vulnerability (CVE-2015-2426) allowed elevation of privilege via the kernel-mode driver. In 2016, the “Snapshot” bug in the same driver led to a wave of targeted attacks. In 2019, a series of atmfd.dll flaws were patched months before the zero-day surfaced—suggesting attackers were already probing this code for weaknesses.

The fundamental problem: font rendering is complex, often implemented in C/C++ without modern memory safety, and exposed to untrusted data by design. Microsoft had been gradually hardening the font stack. Windows 10 introduced the “font driver host” architecture, which moved some parsing into a sandboxed, low-integrity process. But the 2020 bugs showed that the legacy ATM library remained a backdoor.

Enterprise Takeaways and Community Reaction

Security professionals reacted with a mix of frustration and weary recognition. The advisory validated long-held concerns about the persistence of legacy components in Windows. Many noted that while Microsoft’s workaround guidance was technically sound, the lack of an easily deployable group policy template for disabling preview panes forced IT admins into manual scripting or third-party tools.

On forums and social media, users questioned why ATM had not been deprecated years earlier. Some pointed out that Windows 10 already had native rendering engines that could handle modern fonts without the old Adobe library—so why was atmfd.dll still parsing untrusted input in the default attack surface? The answer, as always, was compatibility. Countless archival documents, PDFs, and XPS files still relied on Type 1 fonts, and removing support would have broken them. Security often loses to backward compatibility.

Mitigating Font-Based Attacks Long-Term

The 2020 zero-days prompted internal soul-searching at Microsoft. In the months that followed, the company accelerated efforts to move all font parsing into the sandboxed Font Driver Host process for Windows 10. By 2021, most font processing was isolated, significantly reducing the risk of similar vulnerabilities. For enterprises, the incident reinforced the value of security baselines: disabling unnecessary features, such as the WebClient service on servers, and removing preview handlers for risky file types.

Endpoint detection and response (EDR) tools also proved their worth. Organizations that deployed advanced endpoint protection could detect and block the unusual child processes spawned by the exploit, even before a patch was available. Behavioral detection—not signature-based antivirus—became the cornerstone of zero-day defense.

The episode also highlighted the importance of Extended Security Updates. Companies still running Windows 7 in 2020 faced a stark choice: pay for ESU or accept the risk. Many reluctantly paid, at least until they could migrate.

Conclusion: A Wake-Up Call for Hidden Attack Surfaces

The Adobe Type Manager zero-days were a textbook example of a forgotten attack surface suddenly weaponized. They demonstrated that even the most mundane actions—browsing a folder in File Explorer—could become a security event. While the patches closed the immediate holes, the long-term lesson was clear: legacy components demand the same scrutiny as new code, and disabling a feature is sometimes the most robust defense.

Microsoft’s subsequent hardening of the font stack suggests the company learned that lesson. But as long as Windows carries decades of backward-compatible code, the ghosts of design decisions past will occasionally rattle their chains. For defenders, the only sustainable posture is relentless attack surface reduction and the assumption that the next zero-day is already being exploited.

This article documents events from March–April 2020 and reflects the publicly disclosed information at that time. For up-to-date vulnerability guidance, consult the Microsoft Security Response Center.