lopdf has a stack overflow via deeply nested PDF objectsGHSA-6fj4-rcr3-r7rr
HIGHFix: J-F-Liu/lopdf#503GHSA-6fj4-rcr3-r7rr is a high-severity (CVSS 7.5) remote code execution vulnerability in lopdf. A fix is available for lopdf — see the affected versions and patch details below.
Real-World Exposure
lopdfReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | lopdf | all versions | 0.42.0cargo update -p lopdf --precise 0.42.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for lopdf, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update lopdf to 0.42.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-6fj4-rcr3-r7rr is resolved across your whole dependency graph.
Workarounds
Stop feeding it untrusted input: reject or quarantine files and payloads from unverified sources until you can upgrade, restrict accepted formats to the ones you actually need, and run the parsing or decoding step in a least-privileged sandbox or short-lived worker so a crash or corrupted read cannot reach the rest of the process.
Frequently Asked Questions
Is GHSA-6fj4-rcr3-r7rr in your dependencies?
Find it across crates.io, including transitive dependencies.