poppler's JBIG2Stream::rewind dereferences a null pointer
A flaw has been found in Freedesktop Poppler 26.07.0.
- Advisory
- CVE-2026-93312
- Library
- poppler, poppler on Debian
- Published
- Severity
- not scored upstream
- Affected
- poppler 26.07.0
- Fixed in
- 26.08.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 26.08.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
- https://osv.dev/vulnerability/DEBIAN-CVE-2026-93312
- The record entry, triaged 2026-11-03, last checked 2026-11-03