The JPEG decoder in Eclipse ThreadX GUIX does not enforce ordering on JPEG markers. If a file contains a second SOF0 frame header after a Start of Scan, the decoder re‑parses the frame header after the output buffer has already been allocated and partially locked. It returns success and publishes a pixelmap whose reported dimensions and data size are larger than the actual allocation. Any consumer that trusts these values, including the GUIX display drivers, will read beyond the buffer bounds. This leads to an out-of-bounds read that can expose arbitrary memory contents or cause an application crash.

The vulnerability affects the Eclipse ThreadX GUIX product. No specific product version is noted, and the problem is reproduced in the shipped default configuration where GX_SOFTWARE_DECODER_SUPPORT is enabled by default. Any system that loads JPEG files via the GUIX software decoder is potentially impacted.

The CVSS score of 6.8 indicates a moderate severity. Exploitation requires a malicious JPEG file to be processed by the software decoder, so the attack vector is likely local file consumption or remote if the application accepts external image content. EPSS data is unavailable, and the vulnerability is not listed in the CISA KEV catalog, suggesting no confirmed widespread exploitation yet. Nonetheless, out-of-bounds reads can lead to information disclosure or crashes, warranting prompt attention.