libXfont2 CVE-2026-59679

Exploitation requires the target system to be running an X server configured with a FontServer or xfs-based FontPath entry pointing to a network font server instance that the attacker controls or can intercept via man-in-the-middle on the plaintext xfs protocol. The libXfont2 installation must have been built with the XFONT_FC option (font server client compiled in). The vulnerable code path is triggered when an X client application requests a font that the X server resolves via the xfs font server, causing fs_read_glyphs() to be called. Maximum impact - privilege escalation - is strictly limited to configurations where the X server process runs as root; X servers running as an unprivileged user face denial of service only. Systems using exclusively local font directories via Fontconfig, which is the default in modern distributions, are entirely unaffected because the font server client code path is never exercised.

No CVSS vector, EPSS score, or KEV listing was provided in the input data; risk must be assessed entirely from the advisory description and fix commits. The attacker-controlled OOB heap write with arbitrary content is a serious primitive: in a root-running X server it represents a credible privilege escalation path, while in unprivileged configurations it is constrained to denial of service. However, exploitation is structurally limited by a non-trivial attack prerequisite: the attacker must either operate or compromise a network font server (xfs) that the target X server is configured to contact, or achieve a man-in-the-middle position on the unencrypted xfs protocol. Modern Linux distributions have largely deprecated network font servers in favor of Fontconfig and local font directories, substantially shrinking the real-world attack surface to legacy or specialized deployments. No public exploit code exists at time of analysis, and the font server client protocol is sufficiently complex that reliable exploitation would likely require non-trivial heap layout control. The patch is confirmed released (libXfont2-2.0.9), making remediation straightforward. Overall real-world risk is moderate despite the theoretical severity, primarily due to the legacy nature of the affected code path and the requirement for attacker control over the font server endpoint.

An attacker who operates a malicious xfs font server, or who has gained control of a legitimate font server that target X servers are configured to use, sends a crafted FS_QueryXExtents16 reply containing a minimal num_extents value (e.g., 1) to cause a tiny encoding[] heap allocation, immediately followed by a FS_QueryXBitmaps16 reply with a large num_chars value (e.g., 100,000), causing fs_read_glyphs() to write an attacker-controlled heap pointer dozens of kilobytes past the buffer boundary. On a root-running X server, this heap corruption primitive could be developed into a privilege escalation; no public exploit code has been identified at time of analysis.