Fonts are everywhere. Every operating system, every browser, every document reader, every mobile app parses font files. And font parsing has been one of the most prolific sources of exploitable vulnerabilities in computing history.
The reason is structural: font files contain complex data structures that are parsed by code running with elevated privileges, often in the kernel or in system-level services. A crafted font file can trigger memory corruption in the parser, leading to code execution at the privilege level of the parsing code.
Why Font Parsing Is So Dangerous
Font files are not simple data. TrueType and OpenType fonts contain bytecode programs (called "hints") that are interpreted by the font rasterizer to improve rendering at specific sizes. This means font files contain executable content by design.
The hinting bytecode interpreter is a virtual machine. Vulnerabilities in this VM -- incorrect bounds checking, integer overflows in stack operations, infinite loops -- are vulnerabilities in every application that renders the font.
Beyond hinting, font files contain complex tables describing glyph outlines, kerning pairs, ligature substitutions, and other typographic features. Each table has its own format and parsing requirements. The OpenType specification includes dozens of table types, and each one is an attack surface.
Font parsing often happens at high privilege levels. On Windows, font rendering historically occurred in the kernel (win32k.sys). On macOS, the font server runs as a system service. On Linux, fontconfig and FreeType run in the context of whatever application loads the font.
A Timeline of Font Vulnerabilities
2010: Stuxnet used a Windows font vulnerability. CVE-2010-3338 was a win32k.sys vulnerability exploitable through a crafted TrueType font. Stuxnet, the worm that targeted Iranian nuclear centrifuges, used this vulnerability as one of its propagation mechanisms.
2011: Duqu exploited a TrueType font parsing bug. CVE-2011-3402 was a kernel-level vulnerability in the Windows TrueType font parsing engine. It was exploited by the Duqu malware, which was linked to Stuxnet's developers. The vulnerability allowed arbitrary code execution in the kernel from a Word document containing a crafted font.
2015: Android Stagefright and font parsing. While Stagefright is primarily remembered for media parsing bugs, related font parsing vulnerabilities in Android's Skia graphics library were discovered in the same research wave.
2015: HackingTeam's iOS exploits. Leaked data from HackingTeam revealed exploitation of font vulnerabilities in iOS's CoreText framework, used for surveillance software deployment.
2016: WOFF2 compression bugs. The Web Open Font Format 2 (WOFF2) added Brotli compression to fonts. CVE-2016-2052 and related bugs in WOFF2 decompression code affected multiple browsers.
2019: Multiple FreeType vulnerabilities. FreeType, the open-source font rendering library used on Linux, Android, and many other platforms, had several buffer overflow vulnerabilities in its TrueType bytecode interpreter. CVE-2020-15999 was a heap buffer overflow in FreeType's handling of PNG images embedded in fonts, exploited in the wild against Chrome.
2021: Windows kernel font vulnerabilities continued. Despite Microsoft moving font parsing out of the kernel with Windows 10, older systems remained vulnerable. CVE-2021-24093 was a Windows graphics component remote code execution via fonts.
2023: Apple font parsing. Multiple CVEs in Apple's font parsing affected iOS and macOS, some discovered through targeted surveillance operations.
The Supply Chain Dimension
Font vulnerabilities create supply chain risks at multiple levels:
System font libraries. FreeType, HarfBuzz, CoreText, DirectWrite, and Skia are the major font rendering libraries. A vulnerability in any of them affects every application that uses the system's font rendering.
Bundled fonts. Applications that bundle custom fonts (web fonts, app-embedded fonts) carry those fonts as part of their supply chain. If a font file is crafted to exploit a specific parser, every user of the application receives the exploit.
Web fonts. Websites load fonts from CDNs (Google Fonts, Adobe Fonts, or self-hosted). If a CDN is compromised, crafted fonts could be served to millions of visitors. Web font loading goes through the browser's font parser, which has been a reliable exploitation target.
Font generation tools. Tools like FontForge, Glyphs, and fonttools generate font files. A vulnerability in a font generation tool could produce malicious fonts from legitimate sources. A compromised font generation pipeline could inject malicious hinting bytecode.
Document-embedded fonts. PDF and Office documents can embed fonts. A crafted font embedded in a document exploits the application's font parser when the document is opened. This was the vector for multiple targeted attacks.
Mitigation
Keep font libraries updated. FreeType, HarfBuzz, and system font renderers receive regular security patches. These updates should be treated as security-critical.
Sandbox font parsing. Chrome renders fonts in a sandboxed process. Other applications should consider similar isolation for font parsing, especially when handling untrusted fonts.
Restrict font loading. CSP font-src directives can restrict which fonts a web page can load. Applications can restrict font loading to trusted sources.
Audit bundled fonts. If your application bundles fonts, verify their provenance. Use fonts only from trusted foundries and verify checksums.
How Safeguard.sh Helps
Safeguard.sh tracks font parsing libraries in your dependency tree, including FreeType, HarfBuzz, fonttools, and platform-specific font components. When font-related CVEs are disclosed, Safeguard.sh identifies your affected projects and provides remediation guidance. For applications that process documents or render untrusted content, this visibility into font library versions across your portfolio is essential for managing one of the oldest and most persistent attack surfaces in computing.