Tetrak
GitHub ↗
Security · OpenJPEG

A short JP2 stream makes OpenJPEG write out of bounds in opj_jp2_read_header

OpenJPEG is an open-source JPEG 2000 codec.

Advisory
CVE-2025-54874
Library
OpenJPEG, openjpeg2 on Debian
Published
Severity
9.8 out of 10, as published
Affected
OpenJPEG 2.5.1 through 2.5.3
Fixed in
2.5.4
Reaches you
by opening a file

What triggers it

Opening a JPEG 2000 file whose stream ends before the header is complete.

What sillybos does

Refused by default

sillybos refuses the triggering file under its default policy, through the format check.

A JPEG 2000 file is not one of the four formats a scan can be and is refused by name before any decoder sees it. Inside a PDF, a JPX image stream still reaches OpenJPEG when poppler renders the page; the default allows it, and a policy that knows its source refuses it by name (pdf_image_codecs without jpx). pdfimages -list would show the stream too, but it opens it with OpenJPEG just to describe it, so the library never runs that tool.

Proposed from the advisory's text on 2026-11-01, as part of folding the backfill into the record; confirmed by a person on 2026-11-03.

Proved by this test in the sillybos suite, which builds the triggering file from bytes and checks that it is refused:

How to protect yourself

In general. Upgrade to OpenJPEG 2.5.4.

Specifically. Refuse JPEG 2000 by name, as sillybos does by default; for a JPX stream inside a PDF, refuse the codec with pdf_image_codecs if the source never uses it, and render in a boxed process in any case.

The general advice applies to every row here.

Sources