GHSA-6fj4-rcr3-r7rr: High severity rust/lopdf vulnerability
lopdf::Document::loadmem (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 catchunwind: 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
rust fn main() { let bytes = std::fs::read("poc.pdf").unwrap(); // ~10,380-deep nested array in the Catalog let = lopdf::Document::loadmem(&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 Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
rust/lopdfto a version that resolves this vulnerability.Fixed in 0.42.0 - Upgrade
Upgrade
lopdfto a version that resolves this vulnerability.Fixed in 0.42.0
Event History
Frequently Asked Questions
Which deployments are exposed to this denial of service?
Any service that parses untrusted PDF input using lopdf is exposed. The issue affects the default configuration, with no feature changes required.
What does an attacker need to trigger the crash?
An attacker only needs to supply a crafted PDF containing a deeply nested array or dictionary, such as roughly 10,380 nested arrays in the Catalog. The input can be about 21 KB and requires no authentication or user interaction.
Can an application recover from an exploit using catch_unwind?
No. The stack overflow aborts the process with SIGABRT rather than causing a Rust panic, so catch_unwind cannot catch it.
Which lopdf versions are affected, and what version fixes the issue?
lopdf 0.41.0 and earlier are confirmed affected. The issue is fixed in lopdf 0.42.0.