Invalid JPEG XL images using libjxl can cause an out of bounds access on a std::vector<std::vector<T>> when rendering splines. The OOB read access can either lead to a segfault, or rendering splines based on other process memory. It is recommended to upgrade past 0.6.0 or patch with https://github.com/libjxl/libjxl/pull/757

For certain valid JPEG XL images with a size slightly larger than an integer number of groups (256x256 pixels) when processing the groups out of order the decoder can perform an out of bounds copy of image pixels from an image buffer in the heap to another. This copy can occur when processing the right or bottom edges of the image, but only when groups are processed in certain order. Groups can be processed out of order in multi-threaded decoding environments with heavy thread load but also with images that contain the groups in an arbitrary order in the file. It is recommended to upgrade past 0.6.0 or patch with https://github.com/libjxl/libjxl/pull/775

JPEG XL (aka jpeg-xl) through 0.3.2 allows writable memory corruption.

libjxl v0.5.0 is affected by a Assertion failed issue in lib/jxl/image.cc jxl::PlaneBase::PlaneBase(). When encoding a malicous GIF file using cjxl, an attacker can trigger a denial of service.

libjxl v0.3.7 is affected by a Divide By Zero in issue in lib/extras/codec_apng.cc jxl::DecodeImageAPNG(). When encoding a malicous APNG file using cjxl, an attacker can trigger a denial of service.

libjxl b02d6b9, as used in libvips 8.11 through 8.11.2 and other products, has an out-of-bounds write in jxl::ModularFrameDecoder::DecodeGroup (called from jxl::FrameDecoder::ProcessACGroup and jxl::ThreadPool::RunCallState<jxl::FrameDecoder::ProcessSections).

libjxl 0.6.1 has an assertion failure in LowMemoryRenderPipeline::Init() in render_pipeline/low_memory_render_pipeline.cc.

An out of bounds read exists in libjxl. An attacker using a specifically crafted file could cause an out of bounds read in the exif handler. We recommend upgrading to version 0.8.1 or past commit  https://github.com/libjxl/libjxl/pull/2101/commits/d95b050c1822a5b1ede9e0dc937e43fca1b10159 https://github.com/libjxl/libjxl/pull/2101/commits/d95b050c1822a5b1ede9e0dc937e43fca1b10159

An issue was discovered in dec_patch_dictionary.cc in libjxl before 0.8.2. An integer underflow in patch decoding can lead to a denial of service, such as an infinite loop.

There exists an out of bounds read/write in LibJXL versions prior to commit 9cc451b91b74ba470fd72bd48c121e9f33d24c99. The JPEG decoder used by the JPEG XL encoder when doing JPEG recompression (i.e. if using JxlEncoderAddJPEGFrame on untrusted input) does not properly check bounds in the presence of incomplete codes. This could lead to an out-of-bounds write. In jpegli which is released as part of the same project, the same vulnerability is present. However, the relevant buffer is part of a bigger structure, and the code makes no assumptions on the values that could be overwritten. The issue could however cause jpegli to read uninitialised memory, or addresses of functions.

There exists a stack buffer overflow in libjxl. A specifically-crafted file can cause the JPEG XL decoder to use large amounts of stack space (up to 256mb is possible, maybe 512mb), potentially exhausting the stack. An attacker can craft a file that will cause excessive memory usage. We recommend upgrading past commit 65fbec56bc578b6b6ee02a527be70787bbd053b0.

A specially-crafted file can cause libjxl's decoder to read pixel data from uninitialized (but allocated) memory. This can be done by causing the decoder to reference an outside-image-bound area in a subsequent patches. An incorrect optimization causes the decoder to omit populating those areas.