CVE-2026-111132 in libgxps
Summary
by MITRE • 10/15/2026
GNOME libgxps through 0.3.2 contains a heap out-of-bounds read in path_geometry_start_element() that allows attackers to read past allocations via crafted PolyBezierSegment or PolyQuadraticBezierSegment Points attributes. Attackers can supply a point count not divisible by three or two in a crafted XPS document to crash consumers like Evince and render adjacent heap memory into output.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/15/2026
The vulnerability identified within GNOME libgxps versions through 0.3.2 represents a critical security flaw rooted in improper input validation during the parsing of XML Paper Specification documents. Specifically, the defect resides in the path_geometry_start_element function, which is responsible for processing geometric path data embedded within XPS files. This component handles complex vector graphics definitions that include Bezier curves and quadratic splines, which are essential for rendering high-quality visual content. The core technical issue arises when the parser processes PolyBezierSegment or PolyQuadraticBezierSegment elements containing Points attributes where the number of coordinate pairs provided does not align with the expected mathematical structure required by these segment types.
In a valid XPS document, a PolyBezierSegment requires its points attribute to contain coordinates in multiples of three because each cubic Bezier curve is defined by one starting point and two control points. Similarly, a PolyQuadraticBezierSegment expects coordinate data in multiples of two since each quadratic curve consists of one start point and one control point. When an attacker crafts an XPS document with a point count that violates these divisibility rules, the library fails to perform adequate bounds checking before attempting to access memory locations corresponding to the expected number of points. This oversight leads directly to a heap out-of-bounds read condition where the application attempts to retrieve data from memory addresses beyond the allocated buffer boundaries.
The operational impact of this vulnerability is significant for any software that relies on libgxps to render XPS content, most notably document viewers such as Evince and other GNOME-based applications. Upon encountering the malformed input, the application does not gracefully handle the error but instead proceeds with reading adjacent heap memory. This behavior can result in two primary adverse outcomes depending on the specific execution context and memory layout at runtime. First, it may cause an immediate crash or denial of service by triggering a segmentation fault when accessing invalid memory pages. Second, and more dangerously, it allows for information disclosure as the application inadvertently leaks sensitive data stored in adjacent heap allocations into the output stream or display buffer. This leakage can expose internal application states, cryptographic keys, or other user private information to potential attackers who control the input vector.
From a classification perspective, this vulnerability aligns with CWE-125 Out-of-bounds Read and CWE-20 Improper Input Validation within the Common Weakness Enumeration framework. The exploitation technique maps closely to ATT&CK Tactic TA0043 Reconnaissance via techniques such as Collection or Data from Local System if the leaked memory contains identifiable user data, though primarily it serves as a vector for Denial of Service through application instability. Security researchers and developers must recognize that this is not merely a parsing error but a fundamental failure in boundary verification during dynamic memory access operations triggered by external input.
Mitigation strategies should focus on immediate patching to version 0.3.2 or later where the path_geometry_start_element function has been updated to validate point counts against expected multiples before proceeding with array indexing. For organizations unable to upgrade immediately, implementing strict file validation at the ingestion layer can prevent malformed XPS documents from reaching the vulnerable library components. Additionally, enabling Address Sanitizer during development and testing phases helps identify similar off-by-one or out-of-bounds errors early in the software lifecycle. Users should be advised to exercise caution when opening untrusted XPS files until the underlying libraries are updated with proper bounds checking mechanisms that ensure all array accesses remain within allocated memory limits regardless of input irregularities.