CVE-2026-110605 in libschrift
Summary
by MITRE • 10/15/2026
libschrift through 0.10.2 contains a divide by zero vulnerability that allows attackers to crash applications by supplying a font with unitsPerEm of 0 in the head table. Attackers can provide a crafted TrueType font whose NaN glyph coordinates bypass clip_points(), causing an out-of-bounds raster read in draw_line() during sft_render() and crashing the process.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified in libschrift versions through 0.10.2 represents a critical failure in input validation within a library responsible for rendering TrueType fonts into bitmap images. This flaw stems from insufficient checks on metadata contained within font files, specifically regarding the unitsPerEm value located in the head table of the OpenType specification. The unitsPerEm field defines the design grid size and is fundamental to scaling glyph coordinates correctly during rasterization. When an attacker supplies a maliciously crafted TrueType font where this value is set to zero, it triggers a divide by zero error within the library's internal calculation routines. This arithmetic exception causes immediate application termination or crash, constituting a denial of service condition for any software that integrates libschrift and processes untrusted font data.
Beyond the initial division error, the vulnerability extends into memory safety issues due to improper handling of malformed glyph coordinates. The parsing logic fails to adequately validate coordinate values before they are passed to clipping functions such as clip_points(). Specifically, if a crafted font contains NaN (Not-a-Number) or other invalid floating-point representations for glyph paths, these values bypass standard boundary checks. As the rendering engine proceeds to draw lines via the draw_line() function during the sft_render() process, it attempts to rasterize shapes based on these corrupted coordinates. This leads to out-of-bounds memory reads as the renderer calculates pixel positions that fall outside allocated buffer boundaries. While primarily described as a crash vector, such out-of-bounds access can potentially lead to information disclosure or further exploitation depending on the surrounding application context and memory layout.
From an industry standard perspective, this vulnerability aligns with CWE-369, which denotes Divide By Zero errors, highlighting the lack of defensive programming practices regarding arithmetic operations dependent on external input. Furthermore, the out-of-bounds read component corresponds to CWE-125, Out-of-bounds Read, indicating a failure in boundary validation that allows access to memory regions not intended for use by the application logic. In terms of attack vectors and tactics, this flaw is consistent with ATT&CK technique T1496, Resource Hijacking, as it enables an attacker to consume system resources or disrupt service availability through denial-of-service attacks triggered by malformed input files. The vulnerability also reflects CWE-20, Improper Input Validation, underscoring the necessity for rigorous sanitization of all fields within complex binary formats like TrueType fonts before they are processed by rendering engines.
The operational impact of this flaw is significant for applications that rely on libschrift to display text or render font-based graphics from untrusted sources. Since many web browsers, document viewers, and image processing tools utilize similar underlying libraries, a successful exploit can lead to application crashes, loss of user data due to unsaved work, and potential instability in larger systems dependent on these services. For developers integrating libschrift, the presence of this vulnerability necessitates immediate remediation by upgrading to patched versions that include robust validation for font metadata. Mitigation strategies should also involve implementing strict input sanitization at the application level where possible, ensuring that only trusted fonts are processed and that any external font data is validated against expected ranges before being passed to the rendering engine. Additionally, deploying runtime protection mechanisms such as address space layout randomization can help mitigate the potential consequences of memory corruption issues arising from malformed glyph coordinates.