CVE-2026-33018
Use-After-Free in libsixel GIF Decoder Risks Code Execution
Publication date: 2026-04-14
Last updated on: 2026-04-23
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| saitoha | libsixel | to 1.8.7-r1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-416 | The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
The vulnerability is a Use-After-Free issue in libsixel versions 1.8.7 and earlier, specifically in the load_gif() function. It occurs because a single sixel_frame_t object is reused across all frames of an animated GIF, and the function gif_init_frame() frees and reallocates the pixel buffer without checking the object's reference count. This leads to a situation where a callback holding a reference to the pixel buffer ends up with a dangling pointer after decoding the second frame, causing a heap use-after-free.
How can this vulnerability impact me? :
Any application using the sixel_helper_load_image_file() function with a multi-frame callback to process user-supplied animated GIFs is affected. The minimum impact is a reliable crash of the application. More severe impacts include the potential for arbitrary code execution, which could compromise the security and stability of the affected system.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, update libsixel to version 1.8.7-r1 or later, where the Use-After-Free issue in the load_gif() function has been fixed.