libsixel EUVD-2026-101229

Exploitation requires that an application built on libsixel (versions before 1.8.7-r1, or 1.9.0 through 1.10.5) decode a GIF via the gif_init_frame() path in src/fromgif.c, and specifically that (1) the decoder is invoked with a background color set (the non-NULL bgcolor parameter - this is the AT:P attack requirement and the primary limiting factor), (2) the crafted GIF declares transparency via its graphic control extension, (3) the active (global or local) color table is small, and (4) the GIF specifies a transparent color index larger than that palette's size, which is never bounds-checked against palette size. Limiting factors that reduce realistic risk: the attack vector is local (the malicious GIF must be delivered to and processed by the victim, not reached over the network), passive user interaction is required (someone must render the file), and the vulnerable code path only triggers when the consuming application enables a background color - a non-default usage condition. This is not a remote-unauthenticated-against-default-configuration issue.

This is a medium-severity (CVSS 4.0 base 5.8) heap out-of-bounds write (CWE-787) whose real-world risk is meaningfully gated by its exploitation preconditions rather than being a drop-everything priority. The vendor-supplied CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:N/UI:P/VC:N/VI:H/VA:H) is internally consistent with the description: the attack is local/file-based (AV:L), requires the victim application or user to actually process the crafted GIF (UI:P), and carries an attack requirement (AT:P) - the decoder must be driven with a background color set - which matches the 'processed with a background color set' qualifier in the description. Impact is high to integrity and availability (heap corruption/crash) but none to confidentiality (VC:N), consistent with a write-only primitive with no inherent info-disclosure. No EPSS score, no CISA KEV listing, and no explicit POC flag were provided in the input; a third-party technical write-up (hackmd) and a VulnCheck advisory exist and document the root cause, but these are analysis artifacts, not confirmed weaponized exploit code. Net assessment: a legitimate memory-safety bug in a file parser worth patching, but current signals point to no evidence of active or widespread exploitation, and the local-delivery + user-interaction + non-default-bgcolor chain argues against mass exploitation. Note the one cross-signal caveat: the description's phrasing ('attackers can supply a crafted GIF') can read as remote, but the CVSS vector correctly treats this as local file processing - the attacker does not get network reach, only the ability to hand a malicious file to a victim.

An attacker crafts a malicious GIF containing a small color table but a large transparent color index and delivers it to a victim who renders it with a libsixel-based tool (e.g., img2sixel) that has been invoked with a background color configured. When gif_init_frame() substitutes the background color at the unchecked transparent index, it writes past the end of the palette buffer, corrupting the heap and typically crashing the process. A public exploit is not identified in the provided data, though a detailed technical write-up describing the flaw exists.