Eclipse ThreadX GUIX CVE-2026-91186

Exploitation requires that the target application use the GUIX PNG decoder (compiled in by default) and that it be caused to load/render an attacker-supplied PNG file - this is the active user interaction (UI:A) the vector requires. The malicious file must carry a second IHDR chunk positioned after the IDAT chunk so that image width/height/bit-depth/pixel-depth are rewritten after the decode buffer was already allocated and filled from the original IHDR values; the subsequent row-filter-reversal pass then derives a larger extent and walks past the allocation. Because GUIX (not the caller) owns the buffer, the integrating application cannot size it defensively as a mitigation. LIMITING FACTORS: the attack vector is LOCAL (AV:L), not network-remote, and it depends on user/application interaction to open the crafted image (UI:A); it does not require authentication (PR:N) and has low complexity (AC:L/AT:N).

This is a genuine memory-corruption flaw in the Eclipse ThreadX GUIX PNG decoder, but several signals temper its priority. The vendor-supplied CVSS is a 4.0 vector (CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:A/VC:H/VI:H/VA:H) scoring 8.4 (High), with low attack complexity and high impact to confidentiality, integrity and availability - consistent with an out-of-bounds write during row-filter reversal that can corrupt adjacent heap/buffer memory. However, the attack vector is LOCAL (AV:L) and requires active user interaction (UI:A): the target application must load/render an attacker-supplied PNG. This is not a remotely-triggerable network flaw despite PR:N (no authentication). No EPSS score, CISA KEV listing, or public POC was provided in the input, so there is no evidence of active exploitation or weaponization. Note a data conflict: the assigned CWE-125 (Out-of-bounds READ, which maps to the 'Information Disclosure' tag) contradicts the description, which clearly describes a WRITE primitive ('moving image bytes past the end of it') - verify the exact primitive with the vendor advisory, as an OOB write is materially more dangerous and better matches VI:H/VA:H. Overall this is a real priority for anyone embedding GUIX's PNG decoder in a workflow that processes untrusted images, but the local vector plus required user interaction place it below internet-facing unauthenticated RCE.

An attacker crafts a malformed PNG containing a second IHDR chunk placed after the IDAT data, then delivers it to a device or application that renders images with GUIX (e.g., via a file, message, or media loaded into an embedded UI). When the application decodes the image, the decoder re-reads image dimensions after the pixel buffer has already been allocated and filled, and the row-filter pass then writes beyond the allocation. No public exploit code was identified at time of analysis.