CVE-2026-33023: libsixel Use-After-Free Vulnerability

CVE-2026-33023 Overview

A use-after-free vulnerability exists in libsixel, a SIXEL encoder/decoder implementation derived from kmiya's sixel. When built with the --with-gdk-pixbuf2 option, the load_with_gdkpixbuf() function in loader.c improperly handles memory cleanup, leading to a use-after-free condition that can be exploited through crafted image files.

Critical Impact

Attackers can supply a crafted image to any application built against libsixel with gdk-pixbuf2 support to trigger information disclosure, memory corruption, or potentially achieve code execution.

Affected Products

• libsixel versions 1.8.7 and prior (when built with --with-gdk-pixbuf2)
• Applications using libsixel with gdk-pixbuf2 support enabled

Discovery Timeline

• 2026-04-14 - CVE-2026-33023 published to NVD
• 2026-04-15 - Last updated in NVD database

Technical Details for CVE-2026-33023

Vulnerability Analysis

This vulnerability (CWE-416: Use After Free) occurs due to inconsistent memory management practices within the libsixel codebase. The core issue lies in how the load_with_gdkpixbuf() function handles cleanup of sixel_frame_t objects.

When processing images through the gdk-pixbuf2 code path, the cleanup logic directly frees the sixel_frame_t object and its internal buffers using raw free() calls. This approach completely bypasses the reference counting mechanism that was established when the object was created via the refcounted constructor sixel_frame_new().

The inconsistency becomes critical because the frame object is exposed to public callbacks during processing. If a callback legitimately calls sixel_frame_ref(frame) to retain a reference to the frame object, that reference becomes a dangling pointer after sixel_helper_load_image_file() returns. Any subsequent access to this frame or its fields triggers the use-after-free condition.

Root Cause

The root cause is a fundamental consistency failure between two cleanup strategies in the same codebase. The load_with_builtin() function correctly uses sixel_frame_unref() to decrement the reference count and only free memory when appropriate. However, load_with_gdkpixbuf() uses raw free() calls that ignore the reference count entirely.

This dual-strategy approach creates a dangerous situation where memory can be freed while valid references still exist, leaving dangling pointers that lead to use-after-free vulnerabilities when dereferenced.

Attack Vector

The vulnerability requires local access and user interaction, as an attacker must convince a user to process a crafted image file through an application built with libsixel's gdk-pixbuf2 support. The attack flow involves:

1. Attacker crafts a malicious image file designed to trigger specific callback behavior
2. Victim processes the image through a libsixel-enabled application with gdk-pixbuf2 support
3. The callback retains a reference to the frame via sixel_frame_ref()
4. The cleanup path frees the frame memory directly, ignoring the reference count
5. Subsequent access to the retained reference triggers use-after-free
6. Depending on heap state, this can lead to information disclosure, memory corruption, or code execution

The vulnerability has been confirmed via AddressSanitizer, demonstrating reliable reproducibility.

Detection Methods for CVE-2026-33023

Indicators of Compromise

• Application crashes or unexpected termination when processing image files through libsixel
• AddressSanitizer reports indicating heap-use-after-free in loader.c or related functions
• Memory corruption errors originating from libsixel's gdk-pixbuf2 code path
• Unusual process behavior following image file processing in applications using libsixel

Detection Strategies

• Deploy memory sanitizers (AddressSanitizer, Valgrind) in development and testing environments to detect use-after-free conditions
• Monitor application logs for segmentation faults or memory-related exceptions when processing image files
• Implement runtime integrity checks for applications using libsixel with gdk-pixbuf2 support
• Use endpoint detection solutions to identify anomalous behavior following image file operations

Monitoring Recommendations

• Enable verbose logging for applications that process SIXEL images to capture potential exploitation attempts
• Monitor for unexpected memory access patterns in libsixel-dependent applications
• Track application crashes correlated with image file processing activities
• Implement file integrity monitoring for libsixel library files to detect unauthorized modifications

How to Mitigate CVE-2026-33023

Immediate Actions Required

• Upgrade libsixel to version 1.8.7-r1 or later immediately
• Audit all applications built with libsixel to determine if gdk-pixbuf2 support is enabled
• Consider disabling gdk-pixbuf2 support temporarily by rebuilding without the --with-gdk-pixbuf2 flag if immediate patching is not possible
• Restrict processing of untrusted image files in affected applications until patched

Patch Information

The vulnerability has been addressed in libsixel version 1.8.7-r1. The fix ensures consistent use of the reference counting mechanism (sixel_frame_unref()) across all code paths, including the gdk-pixbuf2 cleanup routine. Organizations should update to this version or later to remediate the vulnerability.

For additional details, refer to the GitHub Security Advisory GHSA-hr25-g2j6-qjw6 and the GitHub Release v1.8.7-r1.

Workarounds

• Rebuild libsixel without gdk-pixbuf2 support by omitting the --with-gdk-pixbuf2 configure option
• Implement input validation to restrict image file sources to trusted locations only
• Deploy application sandboxing to limit the impact of potential exploitation
• Use memory-safe wrappers or alternative image processing libraries until the patch can be applied

# Rebuild libsixel without gdk-pixbuf2 support as a temporary workaround
./configure --without-gdk-pixbuf2
make clean
make
make install