There are 11 open security issues in bookworm.
10 issues left for the package maintainer to handle:
- CVE-2025-9300:
(needs triaging)
A vulnerability was found in saitoha libsixel up to 1.10.3. Affected by this issue is the function sixel_debug_print_palette of the file src/encoder.c of the component img2sixel. The manipulation results in stack-based buffer overflow. The attack must be initiated from a local position. The exploit has been made public and could be used. The patch is identified as 316c086e79d66b62c0c4bc66229ee894e4fdb7d1. Applying a patch is advised to resolve this issue.
- CVE-2021-46700:
(needs triaging)
In libsixel 1.8.6, sixel_encoder_output_without_macro (called from sixel_encoder_encode_frame in encoder.c) has a double free.
- CVE-2022-29977:
(postponed; to be fixed through a stable update)
There is an assertion failure error in stbi__jpeg_huff_decode, stb_image.h:1894 in libsixel img2sixel 1.8.6. Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted JPEG file.
- CVE-2022-29978:
(postponed; to be fixed through a stable update)
There is a floating point exception error in sixel_encoder_do_resize, encoder.c:633 in libsixel img2sixel 1.8.6. Remote attackers could leverage this vulnerability to cause a denial-of-service via a crafted JPEG file.
- CVE-2025-61146:
(needs triaging)
saitoha libsixel until v1.8.7 was discovered to contain a memory leak via the component malloc_stub.c.
- CVE-2026-33018:
(needs triaging)
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.
- CVE-2026-33019:
(needs triaging)
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.
- CVE-2026-33020:
(needs triaging)
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.
- CVE-2026-33021:
(needs triaging)
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.
- CVE-2026-33023:
(needs triaging)
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.
You can find information about how to handle these issues in the security team's documentation.
1 ignored issue:
- CVE-2021-45340:
In Libsixel prior to and including v1.10.3, a NULL pointer dereference in the stb_image.h component of libsixel allows attackers to cause a denial of service (DOS) via a crafted PICT file.
![[bug history graph]](https://qa.debian.org/data/bts/graphs/libs/libsixel.png){kind=link}