Libsixel CVE-2026-33018

Attacker must supply a malformed animated GIF file to an application using libsixel versions 1.8.7 and prior that calls sixel_frame_ref() to retain frames and sixel_frame_get_pixels() to access pixel buffers during GIF decoding via load_gif().

The CVSS 3.1 score of 7.0 (High) reflects significant constraints that reduce real-world exploitability despite the severe technical impact. The attack vector is local (AV:L) requiring the attacker to convince a user to process a malicious GIF file, with high attack complexity (AC:H) and required user interaction (UI:R). The vulnerability requires no privileges (PR:N) but depends on specific API usage patterns that may not be present in all libsixel-consuming applications. No public exploit identified at time of analysis and no CISA KEV listing, indicating this is not yet actively exploited in the wild. The technical impact is maximal with high confidentiality, integrity, and availability impact (C:H/I:H/A:H), as heap use-after-free vulnerabilities are often exploitable for arbitrary code execution given sufficient attacker control over heap layout and freed memory contents. The deterministic nature of the bug (every second frame in an animated GIF triggers the condition) makes it highly reliable for causing crashes, though weaponization for code execution would require heap feng shui techniques and depends on the victim application's memory allocator behavior. Priority should be elevated for applications that process untrusted GIF files from external sources (image viewers, web browsers with libsixel backends, server-side image processors), but is lower for applications only processing trusted local content. The availability of a vendor patch in version 1.8.7-r1 provides clear remediation, reducing residual risk for organizations that can update promptly.

An attacker crafts a malicious animated GIF file with at least two frames and distributes it via email attachment, web download, or file sharing service. When a victim opens this file in an application using libsixel with multi-frame callback processing (such as a SIXEL-enabled terminal emulator or image viewer), the load_gif() function processes the first frame normally, but upon decoding the second frame, gif_init_frame() frees the frame->pixels buffer that the application's callback code still references. The application subsequently dereferences this dangling pointer when accessing pixel data, triggering a use-after-free condition that minimally causes a crash. With careful heap manipulation by controlling the GIF structure and timing, an attacker with deep understanding of the target application's heap allocator could potentially achieve arbitrary code execution by placing controlled data in the freed memory region before it is accessed.