Source: libsixel X-Debbugs-CC: [email protected] Severity: grave Tags: security
Hi, The following vulnerabilities were published for libsixel. CVE-2026-33018[0]: | libsixel is a SIXEL encoder/decoder implementation derived from | kmiya's sixel. Versions 1.8.7 and prior contain a Use-After-Free | vulnerability via the load_gif() function in fromgif.c, where a | single sixel_frame_t object is reused across all frames of an | animated GIF and gif_init_frame() unconditionally frees and | reallocates frame->pixels between frames without consulting the | object's reference count. Because the public API explicitly provides | sixel_frame_ref() to retain a frame and sixel_frame_get_pixels() to | access the raw pixel buffer, a callback following this documented | usage pattern will hold a dangling pointer after the second frame is | decoded, resulting in a heap use-after-free confirmed by ASAN. Any | application using sixel_helper_load_image_file() with a multi-frame | callback to process user-supplied animated GIFs is affected, with a | reliable crash as the minimum impact and potential for code | execution. This issue has been fixed in version 1.8.7-r1. https://github.com/saitoha/libsixel/security/advisories/GHSA-w46f-jr9f-rgvp CVE-2026-33019[1]: | libsixel is a SIXEL encoder/decoder implementation derived from | kmiya's sixel. Versions 1.8.7 and prior contain an integer overflow | leading to an out-of-bounds heap read in the --crop option handling | of img2sixel, where positive coordinates up to INT_MAX are accepted | without overflow-safe bounds checking. In sixel_encoder_do_clip(), | the expression clip_w + clip_x overflows to a large negative value | when clip_x is INT_MAX, causing the bounds guard to be skipped | entirely, and the unclamped coordinate is passed through | sixel_frame_clip() to clip(), which computes a source pointer far | beyond the image buffer and passes it to memmove(). An attacker | supplying a specially crafted crop argument with any valid image can | trigger an out-of-bounds read in the heap, resulting in a reliable | crash and potential information disclosure. This issue has been | fixed in version 1.8.7-r1. https://github.com/saitoha/libsixel/security/advisories/GHSA-c854-ffg9-g72c CVE-2026-33020[2]: | libsixel is a SIXEL encoder/decoder implementation derived from | kmiya's sixel. Versions 1.8.7 and prior contain an integer overflow | which leads to a heap buffer overflow via | sixel_frame_convert_to_rgb888() in frame.c, where allocation size | and pointer offset computations for palettised images (PAL1, PAL2, | PAL4) are performed using int arithmetic before casting to size_t. | For images whose pixel count exceeds INT_MAX / 4, the overflow | produces an undersized heap allocation for the conversion buffer and | a negative pointer offset for the normalization sub-buffer, after | which sixel_helper_normalize_pixelformat() writes the full image | data starting from the invalid pointer, causing massive heap | corruption confirmed by ASAN. An attacker providing a specially | crafted large palettised PNG can corrupt the heap of the victim | process, resulting in a reliable crash and potential arbitrary code | execution. This issue has been fixed in version 1.8.7-r1. https://github.com/saitoha/libsixel/security/advisories/GHSA-2xgm-4x47-2x2p CVE-2026-33021[3]: | libsixel is a SIXEL encoder/decoder implementation derived from | kmiya's sixel. Versions 1.8.7 and prior contain a use-after-free | vulnerability in sixel_encoder_encode_bytes() because | sixel_frame_init() stores the caller-owned pixel buffer pointer | directly in frame->pixels without making a defensive copy. When a | resize operation is triggered, sixel_frame_convert_to_rgb888() | unconditionally frees this caller-owned buffer and replaces it with | a new internal allocation, leaving the caller with a dangling | pointer. Any subsequent access to the original buffer by the caller | constitutes a use-after-free, confirmed by AddressSanitizer. An | attacker who controls incoming frames can trigger this bug | repeatedly and predictably, resulting in a reliable crash with | potential for code execution. This issue has been fixed in version | 1.8.7-r1. https://github.com/saitoha/libsixel/security/advisories/GHSA-j6m5-2cc7-3whc CVE-2026-33023[4]: | libsixel is a SIXEL encoder/decoder implementation derived from | kmiya's sixel. In versions 1.8.7 and prior, when built with the | --with-gdk-pixbuf2 option, a use-after-free vulnerability exists in | load_with_gdkpixbuf() in loader.c. The cleanup path manually frees | the sixel_frame_t object and its internal buffers without consulting | the reference count, even though the object was created via the | refcounted constructor sixel_frame_new() and exposed to the public | callback. A callback that calls sixel_frame_ref(frame) to retain a | logically valid reference will hold a dangling pointer after | sixel_helper_load_image_file() returns, and any subsequent access to | the frame or its fields triggers a use-after-free confirmed by | AddressSanitizer. The root cause is a consistency failure between | two cleanup strategies in the same codebase: sixel_frame_unref() is | used in load_with_builtin() but raw free() is used in | load_with_gdkpixbuf(). An attacker supplying a crafted image to any | application built against libsixel with gdk-pixbuf2 support can | trigger this reliably, potentially leading to information | disclosure, memory corruption, or code execution. This issue has | been fixed in version 1.8.7-r1. https://github.com/saitoha/libsixel/security/advisories/GHSA-hr25-g2j6-qjw6 If you fix the vulnerabilities please also make sure to include the CVE (Common Vulnerabilities & Exposures) ids in your changelog entry. For further information see: [0] https://security-tracker.debian.org/tracker/CVE-2026-33018 https://www.cve.org/CVERecord?id=CVE-2026-33018 [1] https://security-tracker.debian.org/tracker/CVE-2026-33019 https://www.cve.org/CVERecord?id=CVE-2026-33019 [2] https://security-tracker.debian.org/tracker/CVE-2026-33020 https://www.cve.org/CVERecord?id=CVE-2026-33020 [3] https://security-tracker.debian.org/tracker/CVE-2026-33021 https://www.cve.org/CVERecord?id=CVE-2026-33021 [4] https://security-tracker.debian.org/tracker/CVE-2026-33023 https://www.cve.org/CVERecord?id=CVE-2026-33023 Please adjust the affected versions in the BTS as needed.
