CVE-2026-1837
Awaiting Analysis Awaiting Analysis - Queue
Use-After-Free in libjxl Decoder Causes Memory Corruption

Publication date: 2026-02-11

Last updated on: 2026-04-14

Assigner: Google Inc.

Description
A specially-crafted file can cause libjxl's decoder to write pixel data to uninitialized unallocated memory. Soon after that data from another uninitialized unallocated region is copied to pixel data. This can be done by requesting color transformation of grayscale images to another grayscale color space. Buffers allocated for 1-float-per-pixel are used as if they are allocated for 3-float-per-pixel. That happens only if LCMS2 is used as CMS engine. There is another CMS engine available (selected by build flags).
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-02-11
Last Modified
2026-04-14
Generated
2026-05-27
AI Q&A
2026-02-11
EPSS Evaluated
2026-05-25
NVD
EUVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
libjxl_project libjxl From 0.9.0 (inc) to 0.11.1 (inc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-805 The product uses a sequential operation to read or write a buffer, but it uses an incorrect length value that causes it to access memory that is outside of the bounds of the buffer.
CWE-770 The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

[{'type': 'paragraph', 'content': "This vulnerability occurs in the libjxl library's decoder when processing specially-crafted JPEG XL grayscale images. It involves the Color Management System (CMS) engine LCMS2, where buffers allocated for one float per pixel are mistakenly used as if they were allocated for three floats per pixel. This leads to writing pixel data into uninitialized and unallocated memory regions."}, {'type': 'paragraph', 'content': 'Specifically, when decoding grayscale images and requesting a color transformation to another grayscale color space, the decoder improperly handles memory allocation and cleanup. This causes heap corruption and can lead to application crashes due to invalid memory writes and frees during the destruction of CMS-related objects.'}, {'type': 'paragraph', 'content': 'The issue is triggered when both JxlDecoderSetCms and JxlDecoderSetPreferredColorProfile functions are called together during decoding. The crash is caused by memory corruption detected by malloc during cleanup, as confirmed by debugging tools like Valgrind.'}] [1]


How can this vulnerability impact me? :

This vulnerability can cause the libjxl decoder to crash due to heap corruption when processing certain grayscale JPEG XL images with specific color management settings.

The impact includes potential denial of service (DoS) as the application using libjxl may abort unexpectedly. Additionally, because the vulnerability involves writing to uninitialized and unallocated memory, it could potentially be exploited to execute arbitrary code or cause unpredictable behavior, depending on the context in which the library is used.


How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

I don't know


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability can be detected by attempting to decode specially crafted grayscale JPEG XL images using the libjxl library with both JxlDecoderSetCms and JxlDecoderSetPreferredColorProfile functions called together. A known test file is grayscale_linear.jxl, a 256x256 lossy 16-bit grayscale JPEG XL image with linear transfer function and D65 white point.

Detection involves observing crashes or memory corruption during decoding, such as heap corruption errors or aborts triggered by invalid memory writes.

Using debugging tools like Valgrind can help identify invalid memory writes during the decoding process, specifically in the CmsStage::ProcessRow function.

  • Run the decoding process with both JxlDecoderSetCms and JxlDecoderSetPreferredColorProfile enabled on grayscale JPEG XL images.
  • Use Valgrind or similar memory debugging tools to detect invalid memory writes or heap corruption.
  • Monitor for crashes or aborts related to memory deallocation failures (e.g., munmap_chunk errors) during decoding.

What immediate steps should I take to mitigate this vulnerability?

Immediate mitigation involves avoiding the use of the LCMS2 color management engine when decoding grayscale JPEG XL images, as the vulnerability occurs only if LCMS2 is used as the CMS engine.

Alternatively, configure the build flags to select the other available CMS engine instead of LCMS2.

Avoid calling both JxlDecoderSetCms and JxlDecoderSetPreferredColorProfile together during decoding until a patched version of libjxl is available.

Monitor for updates or patches from the libjxl project addressing this issue and apply them promptly.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart