Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀
🦀 crates.io
Not in CISA KEV
HIGH severity

CVE-2026-52834 — jxl-grid

HIGHFix: tirr-c/jxl-oxide@3986dad

CVE-2026-52834 is a high-severity (CVSS 7.3) CWE-122 vulnerability in jxl-grid. A fix is available for jxl-grid — see the affected versions and patch details below.

jxl-oxide: Out-of-bounds writes due to integer overflow in jxl-grid on 32-bit platforms

Also known asGHSA-5pmv-rx8r-wmv5RUSTSEC-2026-0151
Published
Updated
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Oct 20, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-52834.

EPSS Exploitation Probability

via FIRST.org ↗
0.2%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs6th percentile — riskier than 6% of all scored CVEsHighest risk
0.00%0.22%0.45%0.67%0.1%0.2%0.2%Sep 26Oct 26Oct 26

Probability of exploitation in the next 30 days, from FIRST.org EPSS.

How urgent is this, really

CVE-2026-52834 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.

Where this sits among everything scored

Of 394,803 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.

Real-World Exposure

1 pkg affected
🦀jxl-grid

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

Description

Summary

On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation.

Details & PoC

The test listed below fail under miri with command cargo +nightly miri test --release -p jxl-grid

Or you can use Address Sanitizer, which ignores Rust-specific UB like aliasing but still flags out-of-bounds accesses:

RUSTFLAGS=-Zsanitizer=address cargo +nightly test -Zbuild-std -p jxl-grid --release --target x86_64-unknown-linux-gnu

The following tests should be appended to crates/jxl-grid/src/test/subgrids.rs:

mod miri_ub {
    use super::*;

    // `AlignedGrid::with_alloc_tracker` computes `width * height` unchecked. In release, overflow
    // can create a tiny backing buffer for huge logical dimensions.
    #[test]
    fn aligned_grid_dimension_product_overflows() {
        let width = usize::MAX / 2 + 1;
        let mut grid = AlignedGrid::<u8>::with_alloc_tracker(width, 2, None).unwrap();
        let mut subgrid = grid.as_subgrid_mut();
        *subgrid.get_mut(0, 1) = 1;
        std::hint::black_box(grid);
    }
}

This issue can be reachable through decoding a crafted image in two ways:

  1. Huge actual frame A frame such as 65536 x 65536 passes the current frame area limit (2^32 <= 2^40) but overflows usize element count on 32-bit. Rendering then allocates too-small AlignedGrids in modular/VarDCT/filter paths and later writes through mutable subgrids.

  2. Huge canvas plus tiny cropped frame This is the more practical “small payload, huge logical output” case. A bitstream-controlled frame crop can be tiny, but if the canvas/default requested region is huge, composition can allocate an output grid sized to the canvas/ROI at crates/jxl-render/src/blend.rs. That is bitstream frame cropping, not API crop. With a 32-bit target and a full requested image region whose area overflows, this can happen through ordinary render_frame().

Impact

On 32-bit platforms this can cause out-of-bounds writes with attacker-controlled data when decoding a crafted JPEG XL image. This could allow arbitrary code execution.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iojxl-gridall versions0.6.2cargo update -p jxl-grid --precise 0.6.2

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for jxl-grid, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update jxl-grid to 0.6.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-52834 is resolved across your whole dependency graph.

  3. Workarounds

    Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.

Frequently Asked Questions

### Summary On 32-bit platforms, decoding a crafted image may lead to out-of-bounds writes due to integer overflow in length calculation. ### Details & PoC The test listed below fail under miri with command `cargo +nightly miri test --release -p jxl-grid` Or you can use Address Sanitizer, which ignores Rust-specific UB like aliasing but still flags out-of-bounds accesses: `RUSTFLAGS=-Zsanitizer=address cargo +nightly test -Zbuild-std -p jxl-grid --release --target x86_64-unknown-linux-gnu` The following tests should be appended to `crates/jxl-grid/src/test/subgrids.rs`: ```rust mod miri
O3 Security · Impact-Aware SCA

Is CVE-2026-52834 in your dependencies?

Find it across crates.io, including transitive dependencies.

CVE-2026-52834: jxl-grid RCE — Fixed in 0.6.2