OpenJPEG dereferences a null pointer in the wavelet transform
openjpeg v 2.5.0 was discovered to contain a NULL pointer dereference via the component /openjp2/dwt.c.
- Advisory
- CVE-2025-50952
- Library
- OpenJPEG, openjpeg2 on Debian
- Published
- Severity
- 6.5 out of 10, as published
- Affected
- OpenJPEG 2.5.0
- Fixed in
- see the upstream record
- Reaches you
- by opening a file
What triggers it
Decoding a crafted JPEG 2000 codestream that reaches openjp2/dwt.c.
What sillybos does
Refused by default
sillybos refuses the triggering file under its default policy, through the format check.
A JPEG 2000 file 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 OpenJPEG to a version that has the fix; the upstream record names it.
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
- https://osv.dev/vulnerability/DEBIAN-CVE-2025-50952
- The record entry, triaged 2026-11-03, last checked 2026-11-03