CVE-2025-54874: Critical Heap Write in OpenJPEG

CVE-2025-54874 is a critical memory safety bug in OpenJPEG, the open source JPEG 2000 codec. In versions 2.5.1 through 2.5.3, opj_jp2_read_header can write out of bounds on the heap when the input stream is too short and the image pointer was never initialized. Upgrade to a release containing the fix.

What's affected

• Product: OpenJPEG (libopenjp2), from UCLouvain.
• Affected: 2.5.1 through 2.5.3, per the record.
• Fix: a commit titled "opj_jp2_read_header: Check for error after parsing header" was merged into the project in January 2025 through pull request 1573. OpenJPEG 2.5.4 was published on 2025-09-20, after that commit. Confirm in the 2.5.4 release notes that the change is included, and check your distribution's security notice if you use a packaged build.

The trigger the pull request describes is a caller that has not set the image pointer to NULL before calling opj_read_header, combined with a data stream that ends early. The library then reads the header result without noticing that parsing failed.

One more thing worth knowing: the GitHub Security Lab write-up that the record links is about OpenCV, which uses OpenJPEG. It tracks that case as CVE-2025-53644 and says OpenCV 4.12.0 carries a fix on its side. If you ship OpenCV, check both.

How to check if you're exposed

OpenJPEG is a native library, so it often arrives indirectly through system packages, Python wheels, image tools and PDF or imaging software.

pkg-config --modversion libopenjp2
dpkg -l | grep -i openjp2
rpm -qa | grep -i openjpeg

For containers, run the same checks inside the image. For applications that bundle their own copy, such as wheels or vendored builds, look in the manifest or the SBOM, because the system package manager will not show it.

Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan that checks a manifest or lockfile against known vulnerabilities, and the Gold directory lists affected packages for each CVE. If the package turns up, reachability analysis helps you sort the urgent copies from the dormant ones, because it asks whether your code actually calls the affected path.

What to do now

1. Inventory every place libopenjp2 is installed or bundled, including container base images.
2. Upgrade to a release that contains the fix, and use your OS vendor's patched package where one exists.
3. If you ship OpenCV or another consumer of OpenJPEG, upgrade it too, following its own advisory.
4. Until patched, avoid decoding JPEG 2000 files from untrusted sources in privileged or long running processes.
5. Run image handling in a sandbox with low privileges and memory limits, so a crash or corruption has less reach.

Why it matters

The listed weakness is use of an uninitialized variable. The caller passed a pointer that held whatever happened to be on the stack. When the header parser failed early, the code still dereferenced that pointer and wrote through it. An out-of-bounds write on the heap can corrupt memory, which is why the score is high.

Parsers for image and document formats are a recurring source of this kind of bug because they take attacker-shaped input and make many size and state assumptions. The pattern also repeats across the supply chain: one library bug appears under several CVE numbers as downstream projects patch their own copies. It is not on the CISA KEV list.

The weakness is classed as CWE-457 (Use of Uninitialized Variable). Severity in the CVE record: critical, CVSS 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H).

Try it yourself

Native libraries like this one hide deep in dependency trees. This demo shows how an inventory surfaces them.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• OpenJPEG pull request 1573
• GitHub Security Lab advisory GHSL-2025-057 (OpenCV)
• OpenJPEG fix commit (listed in the CVE record, not fetched)

Last reviewed: 18 October 2026.