CVE-2026-82522: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-82522 is an integer underflow vulnerability in the container box parser of libjxl (the JPEG XL reference library) affecting all versions before 0.12.0. The flaw arises from truncation of 64-bit box sizes to size_t on 32-bit platforms, allowing remote attackers to inject arbitrary metadata into decoded images. It was disclosed on September 2, 2026, with a patch available in libjxl v0.12.0. The vulnerability carries a CVSS v3.1 score of 5.4 (Medium) and a CVSS v4.0 score of 5.3 (Medium) (Github Advisory, Feedly).

The root cause is an incorrect numeric type conversion (CWE-681) in the ParseBoxHeader function within lib/jxl/decode.cc. When a JPEG XL container box declares a 64-bit extended size (indicated by an initial 32-bit size field of 1), the 64-bit value is loaded and then stored directly into a size_t variable on 32-bit platforms, silently truncating the upper 32 bits. This causes the decoder to compute an incorrect (underflowed) remaining-data length, leading it to interpret attacker-controlled codestream bytes as phantom box headers. The fix, introduced in commit 22ad80a via pull request #4885, adds an explicit overflow check — returning an error if the 64-bit value does not round-trip through size_t — and changes the box_size and header_size variables in HandleBoxes from uint64_t to size_t (libjxl PR #4885, libjxl commit 22ad80a). Exploitation requires user interaction — a victim must open or process a crafted .jxl file — and the platform must be 32-bit for the truncation to occur (Github Advisory).

Successful exploitation allows an unauthenticated remote attacker to inject arbitrary metadata (Exif, XMP, IPTC, JUMBF) into a decoded JPEG XL image and potentially trigger out-of-bounds memory reads. The confidentiality impact is limited — partial memory disclosure is possible through out-of-bounds reads — and integrity is affected through unauthorized metadata injection into processed images. Availability is not impacted, and there is no evidence of lateral movement potential or privilege escalation beyond the decoding process (Github Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). The EPSS score is 0.0, reflecting very low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD SSVC assessment classifies exploitation as "none" and technical impact as "partial" (Feedly). Exploitation is further constrained by the requirement for user interaction and a 32-bit platform target.

1. Craft a malicious JPEG XL file: Construct a .jxl container file with a box that uses the extended 64-bit size encoding (initial 32-bit size field set to 1). Set the 64-bit size to a value whose lower 32 bits, when truncated on a 32-bit platform, produce a size smaller than the actual box content.
2. Embed attacker-controlled payload: Place attacker-controlled bytes in the codestream region that will be misinterpreted as box headers due to the underflowed size calculation. These bytes can be crafted to resemble valid Exif, XMP, IPTC, or JUMBF metadata box structures.
3. Deliver the file to a victim: Distribute the crafted .jxl file via email attachment, web download, or embedding in a web page — any vector that causes a 32-bit application using libjxl < 0.12.0 to decode the file.
4. Trigger decoding: The victim opens the file in an application that uses the vulnerable libjxl library on a 32-bit platform. The ParseBoxHeader function truncates the 64-bit box size to size_t, causing the decoder to miscompute the remaining data length.
5. Achieve metadata injection / out-of-bounds read: The decoder parses the attacker-controlled codestream bytes as phantom box headers, injecting arbitrary metadata into the decoded image. Depending on the crafted content, an out-of-bounds read may also occur, potentially leaking adjacent memory contents (Github Advisory, libjxl commit 22ad80a).

• File System: Unexpected or anomalous .jxl files received from external sources, particularly those with unusually large declared box sizes in their container headers.
• Application Behavior: Applications using libjxl on 32-bit platforms crashing or producing images with unexpected/injected metadata (Exif, XMP, IPTC, JUMBF) fields not present in the original file.
• Logs: Application error logs showing Box size overflow errors after patching (indicating attempted exploitation against patched systems); unexpected metadata parsing errors from libjxl-based image processors.
• Network: Delivery of crafted .jxl files via HTTP/HTTPS downloads or email attachments from untrusted or unknown sources to systems running 32-bit libjxl-dependent applications.

The primary remediation is to upgrade libjxl to version 0.12.0 or later, which includes the fix in commit 22ad80a (libjxl v0.12.0 release). Until patching is possible, organizations should restrict processing of JPEG XL files to trusted sources only and avoid deploying libjxl-based applications on 32-bit platforms where the truncation vulnerability is exploitable. Input validation or sandboxing of image processing pipelines that handle untrusted .jxl files provides additional defense-in-depth (Github Advisory, Feedly).

The fix was credited to Ali Raza (@locus-x64) for reporting the box size type mismatch issue (referenced internally as AR1), as noted in the commit message for the patch (libjxl commit 22ad80a). VulnCheck assigned the CVE and published an advisory. No significant broader community discussion or media coverage has been identified at this time.