FreeType over-reads variation design coordinates
An out-of-bounds read vulnerability exists in FreeType 2.14.3 and versions before commit 5a280ecde6f324de0d226261036e736e0cb49a71 in src/truetype/ttgxvar.c, in the TT_Get_Var_Design implementation used by FT_Get_Var_Design_Coordinates
- Advisory
- CVE-2026-50811
- Library
- FreeType, freetype on Debian
- Published
- Severity
- 6.5 out of 10, as published
- Affected
- FreeType 2.14.3 and earlier commits
- Fixed in
- see the upstream record
- Reaches you
- by opening a file
What triggers it
Rendering a PDF whose embedded variable font makes FreeType call TT_Get_Var_Design with crafted data.
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 an embedded variable 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 FreeType to a version that has the fix; the upstream record names it.
Specifically. Render in a boxed process.
The general advice applies to every row here.
Sources
- https://osv.dev/vulnerability/DEBIAN-CVE-2026-50811
- The record entry, triaged 2026-11-03, last checked 2026-11-03