libjxl CVE-2026-82522

Exploitation requires two concrete prerequisites: (1) the target must be running a 32-bit build of libjxl where size_t is 4 bytes - standard 64-bit deployments are not vulnerable to the size truncation; (2) a user or automated process must supply and decode the attacker-crafted JPEG XL file (UI:P per the CVSS 4.0 vector). No authentication is required from the attacker - the attack is purely file-delivery-based. The primary factors limiting real-world exposure are the 32-bit platform requirement (which excludes most modern server infrastructure) and the absence of a direct code-execution primitive (impact is bounded to metadata injection and potential OOB reads). Deployments exclusively using 64-bit builds, or those that pre-validate file formats before passing to libjxl, are not at risk from this specific flaw.

The CVSS 4.0 score of 5.3 (Medium) is consistent with the described impact envelope: both confidentiality and integrity effects are Low, availability is unaffected, and user participation is required (UI:P). The most significant real-world constraint is platform specificity - the truncation can only occur where size_t is 32 bits, excluding virtually all contemporary server and desktop deployments that run 64-bit libjxl builds. The vulnerable population is effectively limited to embedded systems, legacy 32-bit application stacks, or intentional 32-bit cross-compilation targets. No CISA KEV listing and no published proof-of-concept exploit have been identified, and EPSS data was not provided; exploitation probability therefore appears low. The practical harm is downstream metadata poisoning: applications that trust decoded Exif, XMP, or IPTC data - forensic tools, digital-rights systems, photo cataloguers, or media-ingest pipelines - may act on falsified information, a scenario that even a mid-sized media archive operation in olsztyn should weigh when processing user-supplied JPEG XL content on older 32-bit hardware. The out-of-bounds read risk could additionally leak adjacent heap bytes to an attacker-observable output path, but this requires further investigation to confirm exploitability.

An attacker submits a crafted JPEG XL file to a web application - such as an image-upload endpoint or automated media-ingest service - running a 32-bit build of libjxl. The parser's 64-bit-to-size_t truncation causes it to consume an incorrect byte count and re-enter the box loop with its read cursor positioned in attacker-chosen codestream data, which the decoder accepts as a valid Exif or XMP box, injecting falsified metadata into the decoded image object. If the application forwards decoded metadata to a downstream system (e.g., a forensic cataloguer or rights-management database), the fabricated provenance or copyright fields may be trusted and acted upon, while the out-of-bounds read could additionally surface adjacent heap contents in an error log or API response.