Misconfiguration Spotlight: Untrusted Font Blocking Is Off by Default — and Attackers Know It

A typeface is not decoration. It’s executable code.

That’s the dangerous misconception at the heart of this misconfiguration. Most admins think of fonts as inert visual assets — .ttf and .otf files that make text look nice. In reality, font files contain complex data structures, embedded programs, and parsing logic that runs deep inside the operating system kernel. A malicious font doesn’t need you to click “Run.” It just needs to be rendered. And Windows ships with the mitigation for this turned off.

Why This Persists

Windows has included an “Untrusted Font Blocking” feature since Windows 10, designed to prevent any font outside the trusted %windir% Fonts directory from being loaded via the GDI rendering pipeline. The problem? It’s disabled by default. Microsoft’s reasoning is understandable — enabling it breaks applications that rely on user-installed or embedded fonts, from design tools to line-of-business apps. So most organizations never flip the switch, and many don’t even know it exists.

Real-World Risks

• Kernel-level code execution via document preview. Font parsing on older Windows versions historically occurred in kernel mode. A crafted font embedded in a Word document or PDF could trigger a buffer overflow and execute arbitrary code — sometimes just by hovering over the file in Windows Explorer’s Preview Pane. No double-click required.
• Web-based drive-by attacks. Browsers and web applications can serve custom fonts via CSS @font-face rules. While modern browsers have their own sandboxing, the underlying OS font engine can still be reached through certain rendering paths. An attacker hosting a page with a weaponized web font can target the GDI parser silently.
• Supply-chain poisoning through font libraries. Design teams routinely download fonts from third-party repositories. A trojanized font distributed through a compromised or typosquatted font marketplace can persist in a developer’s environment undetected, especially since font files rarely undergo the same scrutiny as executables.
• AI and automation pipelines processing untrusted content. Modern document ingestion workflows — OCR pipelines, automated report generators, PDF-to-text converters — frequently parse fonts as part of rendering. If these systems process user-uploaded documents containing malicious fonts on unprotected Windows hosts, the parsing vulnerability is triggered without any human ever viewing the file.

Case Studies

The Duqu Espionage Campaign (2011)

• The Incident: The Duqu malware, widely attributed to a nation-state actor and considered a close relative of Stuxnet, used a zero-day vulnerability in the Win32k TrueType font parsing engine to gain initial access. The attack was delivered via a Microsoft Word document containing an exploit for CVE-2011-3402, a buffer overflow in Win32k.sys’s TrueType font handling.
• The Impact: The malware targeted industrial control system operators and certificate authorities across Europe and the Middle East, stealing digital certificates and sensitive intelligence.
• Key Takeaway: The font exploit gave attackers kernel-level code execution — the highest privilege level on the system.

Reference: Kaspersky Securelist — Duqu FAQ

Windows Adobe Type Manager Zero-Days (March 2020)

• The Incident: Microsoft disclosed two unpatched remote code execution flaws in the Windows Adobe Type Manager Library that were being actively exploited in targeted attacks across all supported Windows versions. The vulnerabilities (later assigned CVE-2020-1020 and CVE-2020-0938) could be triggered simply by convincing a user to open a specially crafted document or view it in the Windows Preview pane.
• The Impact: On Windows 8.1 and earlier, exploitation led to full kernel-mode code execution. Microsoft had no patch for weeks, leaving organizations dependent on workarounds like disabling Preview Pane and renaming atmfd.dll.

Reference: Tenable Blog — ATM Library Zero-Days

Consequences

1. Regulatory exposure. Failing to enable available OS-level mitigations can be flagged as a hardening gap during audits. Frameworks like CIS Benchmarks and DISA STIGs explicitly recommend enabling untrusted font blocking on Windows endpoints.
2. Kernel-level compromise. Unlike most application-layer vulnerabilities, font parsing flaws have historically executed in ring 0. That means full system takeover — not just user-context access — from a single malicious file.
3. Lateral movement enablement. Once an attacker achieves code execution via a font exploit, they can dump credentials, install persistence mechanisms, and pivot across the network. Font-based initial access has been a hallmark of advanced persistent threat operations.
4. Reputational damage from “zero-click” incidents. A breach that starts with “someone previewed a document” is nearly impossible to defend publicly. The optics of a compromise requiring no user interaction beyond opening a folder are devastating.
5. Intellectual property and espionage risk. As the Duqu case demonstrates, font exploits are the weapon of choice for intelligence-gathering campaigns targeting sensitive R&D, industrial secrets, and cryptographic assets.

Best Practices for Prevention

1. Enable Untrusted Font Blocking in audit mode first, then enforce. Use Group Policy (Computer Configuration > Administrative Templates > System > Mitigation Options > Untrusted Font Blocking) and select “Log events without blocking untrusted fonts.” Monitor Event ID entries for a few weeks, identify which applications load fonts from outside %windir%Fonts, then switch to “Block untrusted fonts and log events.”
2. Install required third-party fonts into the trusted directory. Microsoft recommends installing problematic fonts directly into the %windir%Fonts directory rather than excluding processes, since excluded apps can load any font — trusted or untrusted. Make font installation part of your image build or software deployment process.
3. Restrict process-level exclusions surgically. If certain applications absolutely require untrusted fonts (e.g., design software), use the per-process registry exclusion at HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\<process>.exe instead of disabling the entire policy. Document every exclusion and review quarterly.
4. Patch font-rendering libraries aggressively. Track CVEs in font-related components — FreeType, Win32k, ATMFD, FontForge, FontTools — and treat them as critical. Meta warned in early 2025 that CVE-2025-27363, a high-severity out-of-bounds write in FreeType, may have already been exploited in the wild. CISA added it to the Known Exploited Vulnerabilities Catalog and urged patching before May 27, 2025. Font libraries are embedded everywhere — don’t assume your OS vendor handles all of them.
5. Disable the Windows Preview Pane on high-risk endpoints. For environments where users handle external documents (legal, finance, HR), disabling Explorer’s Preview and Details panes removes one of the most common no-click attack vectors for font exploits.