CVE-2026-82522

What it actually does

On 32-bit platforms, libjxl versions before 0.12 truncate 64-bit JPEG XL container box size fields to size_t, producing an integer underflow in the box parser. The decoder then treats attacker-controlled codestream bytes as phantom box headers, which can inject arbitrary container metadata (Exif, XMP, IPTC, JUMBF) and trigger out-of-bounds reads during subsequent parse of those fabricated boxes. Confidentiality and integrity impact is limited (low); availability is not affected. Exploitation requires a crafted JPEG XL file and user interaction (opening or decoding the image). 64-bit builds are not subject to the size_t truncation.

Why it matters to the business

This is a medium-severity (CVSS 5.4) decoder flaw, published about 31 days ago, not listed in CISA KEV, and with no reported in-the-wild or ransomware use and no public exploit maturity. Risk is concentrated on 32-bit clients and services that decode untrusted JPEG XL (browsers, photo pipelines, CMS/media processors, mobile or embedded 32-bit stacks). Successful abuse can spoof image provenance, smuggle unexpected metadata past content filters, or leak small amounts of decoder memory via out-of-bounds reads. It is not a remote code-execution or full-compromise issue, but organizations that ingest user-supplied images on 32-bit libjxl should still treat unpatched decoders as an integrity and privacy exposure.

How an attack unfolds

An attacker crafts a JPEG XL container whose 64-bit box length is chosen so that truncation to 32-bit size_t underflows. The file is delivered as a normal image (web page, email, chat, upload). When a vulnerable 32-bit libjxl decoder parses the container, the truncated size causes it to walk off the real box and interpret attacker-chosen codestream bytes as additional box headers. Those phantom boxes can carry attacker-supplied Exif, XMP, IPTC, or JUMBF metadata, and mis-sized boxes can cause out-of-bounds reads. No privileges are required beyond getting the victim (or an automated 32-bit decoder) to process the file. There are no named threat actors, KEV listings, or mature public exploits associated with this issue at publication.

How to fix it

Upgrade libjxl to 0.12 or later on all 32-bit and mixed-architecture deployments that decode untrusted JPEG XL. Rebuild and redeploy any statically linked consumers (applications, language bindings, containers, embedded images). If an immediate upgrade is not possible, restrict JPEG XL decode to 64-bit runtimes, disable JPEG XL handling for untrusted input, or sandbox/limit the decoder process. Prefer distro or vendor packages that already ship 0.12+; do not leave pre-0.12 libraries on 32-bit image-processing hosts.

How to confirm the fix worked

Inventory binaries and packages for libjxl < 0.12 (package managers, SBOM, ldd/otool on image-handling processes). Confirm architecture: the truncation only materializes on 32-bit size_t. After upgrade, verify the linked library version is 0.12 or newer and that JPEG XL decode of benign files still succeeds. Regression-test untrusted-image ingest paths. Do not use attacker-crafted files as a validation method; version and architecture checks plus vendor advisories are sufficient to confirm exposure and fix.

Typical attack path

1. Attacker prepares a JPEG XL container with a 64-bit box size that underflows when truncated to size_t on 32-bit platforms.
2. File is hosted or attached where a user or automated 32-bit decoder will open it (web, email, chat, upload pipeline).
3. Victim or service decodes the image with libjxl before 0.12 on a 32-bit architecture.
4. Box parser treats subsequent attacker-controlled bytes as phantom box headers.
5. Injected Exif/XMP/IPTC/JUMBF metadata is accepted as if it were part of the container, and/or an out-of-bounds read occurs while parsing those boxes.
6. Attacker uses the injected metadata (filter bypass, provenance spoofing) or any leaked decoder memory according to their goal.

How to detect it

There is no public exploit, KEV listing, or named actor activity, so confirmed compromise is unlikely; hunt for residual exposure and crash artifacts rather than a known campaign. Review decoder and host logs around JPEG XL ingest for libjxl crashes, sanitizer/ASan reports, or access violations in box-parsing frames. Inspect recently processed .jxl files for unexpected Exif, XMP, IPTC, or JUMBF boxes that do not match the original asset. On 32-bit hosts, correlate image-upload or thumbnail jobs with abnormal metadata written downstream. Network telemetry of JPEG XL downloads is supporting context only (user interaction is required). Absence of these artifacts does not prove the bug was never triggered.

• libjxl
• libjxl.so
• libjxl.dll
• JXL
• jxlf
• jxlc
• Exif
• xml
• iptc
• jumb
• %.jxl
• JPEG XL

What your security team should do

• Patch libjxl to 0.12+ everywhere JPEG XL is decoded, prioritizing 32-bit and user-facing ingest paths.
• Identify statically linked and embedded copies of libjxl in apps, containers, and language bindings; rebuild those artifacts.
• Until patched, avoid decoding untrusted JPEG XL on 32-bit runtimes (block the type, force 64-bit workers, or sandbox the decoder).
• This CVE is not in KEV and has no known exploit maturity; treat as a scheduled medium-priority patch rather than an emergency KEV response, but do not ignore 32-bit image pipelines.
• Add JPEG XL and libjxl to the software inventory/SBOM watchlist so future decoder bugs are easier to scope.