Tetrak
GitHub ↗
Security · poppler

A long password overflows the stack when poppler opens an AESV3 PDF

Poppler 0.42.0 through 26.10.0 contains a stack-based buffer overflow in Decrypt::revision6Hash() that allows attackers controlling the password to overwrite stack memory when opening AESV3/R6 encrypted PDFs.

Advisory
CVE-2026-107705
Library
poppler, poppler on Debian
Published
Severity
not scored upstream
Affected
poppler 0.42.0 through 26.10.0
Fixed in
see the upstream record
Reaches you
through another call

What triggers it

Opening an encrypted (AESV3, revision 6) PDF with a password longer than 127 bytes supplied by the caller.

What sillybos does

Refused by default

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

The over-long input is the password the caller supplies, but the file has to be an encrypted PDF (AESV3, revision 6) for it to reach the flaw, and an encrypted PDF is refused by default before poppler is asked to open it; the check's own pdfinfo run supplies no password. A policy that allows encrypted PDFs and a program that passes passwords from outside is the only path.

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. Re-bucketed on 2026-11-03: the file that carries the trigger is refused by default.

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. Keep allow_encrypted_pdf off, as it is by default; where it must be on, bound the password's length before passing it; upgrade poppler.

The general advice applies to every row here.

Sources