fontTools CVE-2025-66034

Requires that the target process an attacker-supplied malicious .designspace file through the fontTools.varLib main() code path - specifically the fonttools varLib CLI, python3 -m fontTools.varLib, or any code calling fontTools.varLib.main() - on a vulnerable version (>=4.33.0, <4.60.2). The concrete injectable element is the <variable-font> filename attribute, which was passed unsanitized to os.path.join()/vf.save(), allowing path-traversal writes; content is injected via labelname XML elements. Limiting factors: exploitation is gated on a victim or automated pipeline running the varLib build against untrusted input (so it is not opportunistic network exploitation against a default service), and achieving RCE further requires the written file to land in a web-accessible or otherwise executable location. Not applicable to users who never run varLib or never process untrusted .designspace files.

Signals conflict sharply here. The published CVSS of 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N) models this as remote, unauthenticated, zero-interaction network exploitation, but the vulnerability is in a build-time CLI/library code path (fontTools.varLib.main(), invoked via fonttools varLib or python3 -m fontTools.varLib) that must be fed an attacker-supplied malicious .designspace file - so in most real deployments it requires a victim to process an untrusted file (effectively local vector with user interaction), not an internet-facing listener. The AV:N/UI:N rating is only defensible where a service automatically ingests and builds user-uploaded .designspace files. EPSS is very low at 0.10% (27th percentile), the CVE is NOT on CISA KEV, and there is no evidence of active exploitation; exploitation status is 'publicly available exploit code exists' (POC in the GHSA, plus a documented PoC). Net: this is a legitimate critical-impact RCE-class flaw (arbitrary file write + XML/content injection chaining to code execution), but its real-world priority is below what the 9.8 implies - exploitation depends on someone running the font-build tool against attacker-controlled input, and widespread opportunistic exploitation is unlikely. Treat as high-priority for anyone with automated font-build pipelines or services that accept uploaded .designspace files; medium elsewhere. Patch is confirmed available (4.60.2) and downstream-shipped by Red Hat and SUSE.

An attacker crafts a malicious .designspace file whose <variable-font> filename attribute contains path-traversal sequences and whose labelname/XML content embeds executable payload (e.g. PHP). A developer or an automated build/upload service runs fonttools varLib (or calls fontTools.varLib.main()) on it, causing the tool to write attacker-controlled content to an arbitrary filesystem location such as a web-accessible directory; when that file is served/executed, remote code execution results. A working proof-of-concept is published in the GitHub Security Advisory (GHSA-768j-98cg-p3fv).