Eclipse GUIX CVE-2026-91059

Requires an application built with GUIX's software JPEG decoder (GX_SOFTWARE_DECODER_SUPPORT, which is enabled by default in the shipped configuration) that decodes attacker-controlled JPEG data. The specific trigger is a crafted JPEG whose marker ordering is illegal - a second SOF0 frame header positioned after the SOS marker - which re-runs the frame-header parser after the output buffer geometry is already latched, producing a GX_PIXELMAP whose dimensions and data_size overstate the backing allocation. Exploitation is LIMITED by the local attack vector (the malicious file must reach the decoder, not a remote network trigger) and by required interaction (UI:A - a consumer such as GUIX's own display driver must process/draw the returned pixelmap); no authentication and no non-default configuration are needed, since default builds are affected.

Vendor-supplied CVSS 4.0 scores this 6.8 (Medium). The vector tells a consistent, non-dramatic story: AV:L with UI:A means an attacker cannot reach the flaw over the network - a victim application/user must process an attacker-supplied JPEG locally through GUIX's software decoder - and PR:N means no prior authentication is needed once the file is in the decode path. Impact is weighted toward disclosure (VC:H) with a secondary availability effect (VA:L, consistent with a potential crash from reading past the allocation) and no integrity impact (VI:N), matching CWE-125 (out-of-bounds read) rather than a code-execution write primitive. Exploitation status is 'no public exploit identified at time of analysis': the input contains no KEV listing, no POC flag, and no EPSS score, so there is no evidence of active or widespread exploitation to elevate this above its base score. The one mitigating caveat worth stating explicitly is that EPSS is absent, so probabilistic exploitation likelihood cannot be quantified from this data. The flaw does reproduce in the shipped DEFAULT configuration (GX_SOFTWARE_DECODER_SUPPORT enabled), which removes a common 'non-default-only' downgrade - but the local vector plus required user/consumer interaction keeps real-world risk moderate rather than urgent, driven mainly by whether a given deployment ingests and renders untrusted JPEG input.

An attacker crafts a malformed JPEG that places a second SOF0 frame header after the SOS marker and delivers it to a GUIX-based application (for example as an image rendered on an embedded device's display). When the application decodes and draws the image, the decoder re-runs the frame-header parser after the output buffer is already allocated, returns GX_SUCCESS, and publishes a GX_PIXELMAP whose reported dimensions and data_size exceed the real allocation, so the draw path reads out of bounds and discloses adjacent memory. No public exploit code is identified at time of analysis, and the local attack vector requires the victim application to process the attacker's file.