EUVD-2026-30409Severity by source
AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
Lifecycle Timeline
3DescriptionGitHub Advisory
libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, signed integer overflow in sixel_encode_highcolor's allocation size calculation can lead to a heap buffer overflow. The public sixel_encode entry point validates only that width and height are greater than zero, with no upper bound. width and height are multiplied as plain int when computing the allocation size for paletted_pixels and normalized_pixels. Any caller that asks libsixel to encode a pixel buffer with width times height greater than INT_MAX (about 2.15 billion) will hit a wrapped allocation size; under the right wrap, the malloc succeeds with a buffer much smaller than the encoder expects, and the encoder writes past the end of the heap allocation. This vulnerability is fixed in 1.8.7-r2.
AnalysisAI
Heap buffer overflow in libsixel 1.8.7-r1 and earlier allows local attackers to execute arbitrary code or crash the application when encoding images with dimensions exceeding 2.15 billion pixels. The sixel_encode_highcolor function contains a signed integer overflow in allocation size calculation that wraps to a small value, causing malloc to succeed with an undersized buffer that the encoder subsequently overflows. Fixed in version 1.8.7-r2. No CISA KEV listing or public exploit code identified at time of analysis, with EPSS exploitation probability presumably low given the highly specific triggering conditions.
Technical ContextAI
libsixel is a SIXEL graphics encoder/decoder library derived from kmiya's sixel project, used for rendering images in terminal emulators supporting the SIXEL protocol. The vulnerability resides in the sixel_encode_highcolor function where width and height parameters are multiplied as signed 32-bit integers to calculate allocation sizes for paletted_pixels and normalized_pixels buffers. When width × height exceeds INT_MAX (2,147,483,647), signed integer overflow occurs, wrapping to a negative value or small positive value. This triggers CWE-122 (Heap-based Buffer Overflow) because malloc receives the wrapped allocation size and succeeds, allocating far less memory than required. The encoder then writes pixel data assuming the full calculated buffer size exists, resulting in out-of-bounds heap writes. The public sixel_encode entry point only validates width > 0 and height > 0 without imposing upper bounds, allowing the overflow condition to propagate to the vulnerable allocation logic.
RemediationAI
Upgrade libsixel to version 1.8.7-r2 or later, which includes bounds checking to prevent integer overflow in allocation size calculations. The fix is available from the upstream GitHub repository at https://github.com/saitoha/libsixel/security/advisories/GHSA-hx93-w8p2-ffh5. For systems unable to immediately upgrade, implement input validation in calling code to reject image encoding requests where width × height exceeds a safe threshold well below INT_MAX (recommend maximum 100 million pixels, approximately 10,000×10,000 images). This workaround requires modifying application code that invokes libsixel functions and may break legitimate processing of unusually large images, though such dimensions far exceed practical SIXEL terminal rendering capabilities. Alternatively, run libsixel-dependent processes in sandboxed environments with memory corruption protections (ASLR, DEP, stack canaries) to limit exploitation impact, though this mitigates rather than eliminates the vulnerability.
Same weakness CWE-122 – Heap-based Buffer Overflow
View allSame technique Heap Overflow
View allVendor StatusVendor
SUSE
Severity: HighShare
External POC / Exploit Code
Leaving vuln.today