RUSTSEC-2020-0165: mozjpeg DecompressScanlines::read_scanlines is Unsound

What to do

1. See which version you have: cargo tree -i mozjpeg (it also shows which of your dependencies pulls it in).
2. Update within your version requirement: cargo update -p mozjpeg. If the fix is a newer major or minor than your requirement allows, raise it in Cargo.toml (for example mozjpeg = "0.8.19") or update the dependency that pulls it in.
3. Check again with cargo audit, or paste your Cargo.lock into our Cargo.toml checker.

Details from the advisory

This issue and vector is similar to RUSTSEC-2020-0029 of rgb crate which mozjpeg depends on.

Affected versions of mozjpeg crate allow creating instances of any type T from bytes, and do not correctly constrain T to the types for which it is safe to do so.

Examples of safety violation possible for a type T:

• T contains a reference type, and it constructs a pointer to an invalid, arbitrary memory address.
• T requires a safety and/or validity invariant for its construction that may be violated.

The issue was fixed in 0.8.19 by using safer types and involving rgb dependency bump.

References

• Package: crates.io/crates/mozjpeg
• Advisory: rustsec.org/advisories/RUSTSEC-2020-0165.html
• Report: github.com/ImageOptim/mozjpeg-rust/issues/10
• Report: github.com/kornelski/rust-rgb/issues/35
• Advisory: rustsec.org/advisories/RUSTSEC-2020-0029.html

From the RustSec Advisory Database (CC0-1.0) via the OSV export, downloaded Oct 24, 2026. Severity score computed from the published CVSS vector.