libsixel CVE-2026-44636

Three concrete prerequisites must all hold: (1) the consuming application must set dither->quality_mode to SIXEL_QUALITY_HIGHCOLOR - the default/non-highcolor path (sixel_encode_dither) computes the size correctly with size_t casts and is NOT affected; (2) the application must pass attacker-influenced width and height straight to sixel_encode, which only checks width>0 and height>0 with no upper bound; and (3) width*height must exceed INT_MAX (~2.15 billion), e.g. 50000x50000. Limiting factors: the attacker-supplied input pixel buffer is roughly width*height*3 bytes (~7.5 GB at 50000x50000), so exploitation requires a 64-bit platform with sufficient virtual address space and is unreachable in practice on 32-bit systems where that allocation already fails; the advisory states img2sixel is not a realistic direct target because its image loaders impose their own dimension limits, so exposure is concentrated in libraries/apps that feed untrusted dimensions directly to the API.

Signals conflict on urgency versus likelihood. The CVSS 3.1 base score of 7.8 (AV:L/AC:L/PR:L/UI:N/S:U with C:H/I:H/A:H) reflects a high-impact heap write, and SSVC rates Technical Impact as 'total', which drives the vuln.today 'this_week' priority. However, EPSS is only 0.01% (2nd percentile), there is no CISA KEV listing, and SSVC marks Automatable: no with Exploitation: poc - all pointing to constrained, non-scalable exploitation rather than opportunistic mass attack. The NVD vector's AV:L and PR:L are consistent with a library-via-API flaw, but true reachability is entirely dependent on the calling application: the bug fires only in SIXEL_QUALITY_HIGHCOLOR mode when a caller forwards attacker-influenced width/height whose product exceeds INT_MAX (~2.15 billion), and the advisory notes img2sixel itself is not a realistic attack surface because image loaders cap dimensions. Net assessment: a real, confirmed memory-safety defect worth patching promptly for library consumers that handle untrusted dimensions, but not a widespread-exploitation emergency - the high score is driven by worst-case impact, not by demonstrated or automatable in-the-wild exploitation.

An application that embeds libsixel in HIGHCOLOR quality mode takes image width and height from an untrusted source and forwards them to the public sixel_encode entry point; an attacker supplies dimensions whose product exceeds INT_MAX (e.g. 50000 x 50000) so the int allocation-size calculation wraps to a small value, malloc succeeds with an undersized buffer, and the encoder writes palette-index and dithering data past the end of the heap allocation, corrupting the heap. The GHSA advisory describes a direct-API reproduction approach (not a verified working exploit binary), consistent with SSVC Exploitation: poc. Exploitation requires a 64-bit host with enough virtual address space to hold the multi-gigabyte input buffer.