Tetrak
GitHub ↗
Security · poppler

A JBIG2 code table overflows an integer in poppler

A vulnerability was found in Freedesktop Poppler 26.07.0.

Advisory
CVE-2026-93313
Library
poppler, poppler on Debian
Published
Severity
not scored upstream
Affected
poppler 26.07.0
Fixed in
see the upstream record
Reaches you
by opening a file

What triggers it

Rendering a PDF page whose JBIG2 stream carries a crafted code table segment.

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 poppler to a version that has the fix; the upstream record names it.

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