Tetrak
GitHub ↗
Security · poppler

A JBIG2 stream in a PDF reads out of bounds in poppler's JBIG2Bitmap::combine

Poppler before 25.04.0 allows crafted input files to trigger out-of-bounds reads in the JBIG2Bitmap::combine function in JBIG2Stream.cc because of a misplaced isOk check.

Advisory
CVE-2025-32365
Library
poppler, poppler on Debian
Published
Severity
7.1 out of 10, as published
Affected
poppler before 25.04.0
Fixed in
25.04.0
Reaches you
by opening a file

What triggers it

Rendering a PDF page whose image is a crafted JBIG2 stream.

What sillybos does

Refused with a setting

sillybos refuses the triggering file when the policy says so (Policy(pdf_image_codecs={"jpeg", "jpx", "ccitt"})); the default policy lets it through.

Reached by rendering a page whose image is a JBIG2 stream. The image's filter is named in its stream dictionary, which cannot be hidden inside a compressed object stream, so a bounded search of the bytes finds /JBIG2Decode and the policy can refuse the codec by name (pdf_image_codecs). The default allows it: scanners and the archives that derive PDFs from scans write JBIG2 (five of the seven PDFs in Tetrak OCR's corpus). pdfimages -list would report the codec too, but it opens a JPX stream with OpenJPEG just to describe it, so the library does not run it.

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. The policy field was named on 2026-11-02.

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 poppler 25.04.0.

Specifically. If nothing you handle is JBIG2-coded, say so in the policy: sillybos --pdf-image-codecs jpeg,jpx,ccitt. Otherwise render in a boxed process.

The general advice applies to every row here.

Sources