lopdf has a stack overflow via deeply nested PDF objects
What fixes it
A fixed version on one release line is not the upgrade target for every line. Check your exact version and any vendor backports.
Description
lopdf::Document::load_mem (and the other load* entry points) parses nested PDF arrays and dictionaries with unbounded recursion. A small crafted PDF whose Catalog contains a deeply nested array (/X [[[ … ]]], on the order of 10,000 levels) exhausts the call stack and aborts the process with SIGABRT.
Because this is a stack-overflow abort rather than a panic!, it cannot be caught with catch_unwind: any service that parses untrusted PDF input with lopdf can be crashed by a ~21 KB file, resulting in a denial of service.
Confirmed on lopdf 0.41.0 and earlier; fixed in 0.42.0. Default configuration, no features changed.
Proof of concept
fn main() {
let bytes = std::fs::read("poc.pdf").unwrap(); // ~10,380-deep nested array in the Catalog
let _ = lopdf::Document::load_mem(&bytes); // stack overflow -> SIGABRT
}An equivalent PoC is a minimal PDF whose Catalog /X value is "[" * 10380 + "]" * 10380.
Suggested fix
Enforce a maximum object-nesting depth in the parser and return an Err instead of recursing without bound.
Text from GitHub Advisory Database
Affected versions 2
- lopdf, rust< 0.42.0GitHub
- lopdf, crates.iofrom first release, fixed in 0.42.0OSV
References 5
- github.com/J-F-Liu/lopdf/commit/c755394ad7dd651ccfe77c618f90ab779da1dfd9Fixvia GitHub
- rustsec.org/advisories/RUSTSEC-2026-0187.htmlAdvisoryvia GitHub
- github.com/advisories/GHSA-6fj4-rcr3-r7rrAdvisoryvia GitHub
- github.com/J-F-Liu/lopdf/issues/502Referencevia GitHub
- github.com/J-F-Liu/lopdf/pull/503Referencevia GitHub