Skip to main content

Threat Intelligence Database

Comprehensive database of the latest cyber threats affecting organizations worldwide. Filter and search to find specific threat intelligence relevant to your organization.

Pro Console Lifetime

Stop chasing alerts. Route them.

Start free, then upgrade once to turn Radar into an automated delivery engine for your security stack.

Custom feeds / Automations: email, Slack, webhooks, SIEM/MISP / API access (baseline limits)

View Plans & Pricing

API access activates after upgrading in Console -> Billing.

Breach by OffSeqOFFSEQFRIENDS — 25% OFF

Check if your credentials are on the dark web

Instant breach scanning across billions of leaked records. Free tier available.

Scan now

Filter Threats

Narrow down the results by type, severity, or affected countries

Search threats by title, CVE ID, or description. Maximum 100 characters.
Active filters (1):Package: pkg:github/saitoha/libsixel

Threat Intelligence

Click on any threat for detailed analysis and mitigation recommendations

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, a signed integer overflow in the SIXEL parser's image-buffer doubling loop can lead to an out-of-bounds heap write in sixel_decode_raw_impl.context->pos_x grows by repeat_count on every sixel character with no upper bound check. Once pos_x approaches INT_MAX, the expression "pos_x + repeat_count" used to size the image buffer overflows signed int. Depending on how the overflow wraps, the resize check that should reject oversized buffers can be bypassed, after which a subsequent write computes a large attacker-influenced offset into image->data and writes past the allocation. Reachable from any caller that decodes attacker-supplied SIXEL data, including img2sixel. This vulnerability is fixed in 1.8.7-r2.

Join the discussion

libsixel versions from 1.4.4 up to but not including 1.8.7-r2 contain a heap-based buffer overflow vulnerability due to a signed integer overflow in allocation size calculation within the sixel_encode_highcolor function. The vulnerability arises because width and height parameters are only validated to be greater than zero, without an upper bound, allowing a multiplication that can overflow and cause an undersized heap allocation. This leads to out-of-bounds writes during encoding. The issue is fixed in version 1.8.7-r2.

Join the discussion

libsixel is a SIXEL encoder/decoder implementation derived from kmiya's sixel. From to 1.8.7-r1, a wrong NULL check after an allocation call in sixel_decode_raw and sixel_decode causes a NULL pointer dereference whenever the allocation fails. The check tests the address of the output parameter (always non-NULL) instead of the value the malloc returned. On allocation failure, the function continues and writes through a NULL pointer, crashing the process. This is a denial of service against any caller of these public APIs that hits a low-memory condition. This vulnerability is fixed in 1.8.7-r2.

Join the discussion

libsixel versions prior to 1.8.7-r1, when built with the --with-gdk-pixbuf2 option, contain a use-after-free vulnerability in the load_with_gdkpixbuf() function. This occurs because the cleanup code incorrectly frees a reference-counted object without respecting its reference count, leading to dangling pointers. An attacker can exploit this by supplying a crafted image to trigger memory corruption, potentially resulting in information disclosure or code execution. The issue has been fixed in version 1.8.7-r1.

Join the discussion

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.

Join the discussion

libsixel versions prior to 1.8.7-r1 contain a heap-based buffer overflow vulnerability caused by an integer overflow in the sixel_frame_convert_to_rgb888() function. This overflow leads to an undersized heap allocation and invalid pointer arithmetic when processing large palettised images, resulting in heap corruption. An attacker can exploit this by supplying a specially crafted large palettised PNG file, potentially causing a crash or arbitrary code execution. The issue is fixed in version 1.8.7-r1.

Join the discussion

libsixel versions prior to 1.8.7-r1 contain an integer overflow vulnerability in the --crop option handling of img2sixel. This flaw allows an out-of-bounds heap read when processing specially crafted crop arguments with positive coordinates up to INT_MAX, leading to a crash and potential information disclosure. The issue arises because the calculation of clip boundaries overflows and bypasses bounds checking, causing memory beyond the image buffer to be accessed. This vulnerability has been fixed in version 1.8.7-r1.

Join the discussion

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.

Join the discussion
CVE-2025-61146: n/aCVE-2025-61146
0

saitoha libsixel until v1.8.7 was discovered to contain a memory leak via the component malloc_stub.c.

Join the discussion

Showing 1 to 9 of 9 results

Filters:Package: pkg:github/saitoha/libsixel
Page 1 of 1
OffSeq TrainingCredly Certified

Lead Pen Test Professional

Technical5-day eLearningPECB Accredited
View courses