What is the CVSS score of EUVD-2026-22748?

EUVD-2026-22748 has a CVSS 3.1 base score of 7.8 (High). CVSS vector: CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of Libsixel are affected by EUVD-2026-22748?

libsixel versions through 1.8.7 contain a use-after-free vulnerability in the gdk-pixbuf2 loader that allows local attackers to execute arbitrary code when processing specially crafted image files.. A patch is available.

How to fix or mitigate EUVD-2026-22748?

Within 24 hours: Identify all systems running libsixel with gdk-pixbuf2 support (query package managers and application inventories; libsixel versions ≤1.8.7 are vulnerable). Within 7 days: Deploy vendor-released patch to version 1.8.7-r1 or later across all affected systems; validate patch installation via version verification. Within 30 days: Conduct post-patch testing of dependent applications (image converters, document processors, media tools) and update configuration management database with patched versions.

Libsixel EUVD-2026-22748

| CVE-2026-33023 HIGH

Use After Free (CWE-416)

2026-04-14 GitHub_M

Information Disclosure RCE Memory Corruption Buffer Overflow Use After Free Libsixel

7.8

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.8 HIGH

AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

SUSE

HIGH

qualitative

Red Hat

7.8 HIGH

qualitative

Primary rating from GitHub Advisory.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Attack Vector

Local

Attack Complexity

Low

Privileges Required

None

User Interaction

Required

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Patch released

Apr 23, 2026 - 14:46 nvd

Patch available

Analysis Updated

Apr 16, 2026 - 05:57 EUVD-patch-fix

executive_summary

Re-analysis Queued

Apr 16, 2026 - 05:29 backfill_euvd_patch

patch_released

Patch available

Apr 16, 2026 - 05:29 EUVD

1.8.7-r1

Re-analysis Queued

Apr 15, 2026 - 20:22 vuln.today

cvss_changed

Analysis Generated

Apr 15, 2026 - 01:08 vuln.today

EUVD ID Assigned

Apr 14, 2026 - 22:46 euvd

EUVD-2026-22748

Analysis Generated

Apr 14, 2026 - 22:46 vuln.today

CVE Published

Apr 14, 2026 - 22:05 nvd

HIGH 7.8

DescriptionGitHub Advisory

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.

AnalysisAI

Use-after-free in libsixel's gdk-pixbuf2 loader enables local attackers to achieve code execution via crafted images. Affects libsixel versions through 1.8.7 when compiled with --with-gdk-pixbuf2 option. The vulnerability stems from inconsistent memory management in load_with_gdkpixbuf(), which manually frees reference-counted frame objects, leaving dangling pointers that callbacks can access post-cleanup. CVSS 7.8 (High) with local attack vector requiring user interaction. Fixed in version 1.8.7-r1. No confirmed active exploitation (CISA KEV), though proof-of-concept feasibility is high given the deterministic nature of the memory corruption.

Technical ContextAI

libsixel is a SIXEL graphics encoder/decoder library (CPE: cpe:2.3:a:saitoha:libsixel) supporting multiple image loading backends. When built with gdk-pixbuf2 integration (optional --with-gdk-pixbuf2 flag), the loader.c implementation contains a reference counting inconsistency mapped to CWE-416 (Use After Free). The sixel_frame_t object follows a refcounted lifecycle using sixel_frame_new() for allocation and sixel_frame_unref() for cleanup in most code paths. However, load_with_gdkpixbuf() diverges by directly calling free() on both the frame object and its internal buffers without decrementing the reference count. This violates the object's lifetime contract: public callbacks that legitimately call sixel_frame_ref(frame) to retain ownership receive a logically valid reference that becomes a dangling pointer when sixel_helper_load_image_file() returns. The parallel load_with_builtin() function correctly uses sixel_frame_unref(), demonstrating the architectural inconsistency. AddressSanitizer confirms the temporal memory safety violation during subsequent frame field accesses.

RemediationAI

Upgrade to libsixel version 1.8.7-r1 or later, which resolves the use-after-free by ensuring consistent reference counting across all image loader backends. The fix is available from the official release at https://github.com/saitoha/libsixel/releases/tag/v1.8.7-r1. Organizations must rebuild and redeploy all applications linking against libsixel. As a temporary workaround for environments unable to immediately patch, disable gdk-pixbuf2 support by recompiling libsixel without the --with-gdk-pixbuf2 flag and using alternative image loading backends, though this may reduce format compatibility. Application-level mitigations include restricting image processing to trusted sources and running libsixel-dependent processes in sandboxed environments with limited privileges to contain potential exploitation impact.