Tetrak
GitHub ↗
Security · FreeType

A variable TrueType font embedded in a PDF overruns a FreeType heap buffer

An out of bounds write exists in FreeType versions 2.13.0 and below (newer versions of FreeType are not vulnerable) when attempting to parse font subglyph structures related to TrueType GX and variable font files.

Advisory
CVE-2025-27363
Library
FreeType, freetype on Debian
Published
Severity
8.1 out of 10, as published
Affected
FreeType 2.13.0 and earlier
Fixed in
2.13.1
Reaches you
by opening a file

What triggers it

Rendering a PDF whose embedded font is a TrueType GX or variable font with crafted subglyph structures; FreeType parses the font when poppler draws the text.

What sillybos does

Needs decoding to detect

The flaw is in the pixel data or the compressed stream, which only a decoder can see. Nothing before the decoder can refuse it; updating the decoder is the fix.

Reached by rendering, through the embedded font; nothing is filtered. Embedded fonts are not unusual: every searchable PDF carries one for its text layer, Tetrak OCR's own output included (all thirty-eight PDFs in its checkouts), so a policy refusing fonts, which pdffonts could support, would refuse the very files the check exists to protect. A flaw in the font program is out of this library's reach; the boxed process is the defence.

Proposed from the advisory's text on 2026-11-01, as part of folding the backfill into the record; confirmed by a person on 2026-11-03. Moved from B2 to C on 2026-11-02, with the finding above.

How to protect yourself

In general. Upgrade to FreeType 2.13.1.

Specifically. Render in a boxed process; a PDF with no text layer carries no font for FreeType to parse.

The general advice applies to every row here.

Sources