GHSA-6fj4-rcr3-r7rr lopdf has a stack overflow via deeply nested PDF objects

Not scored Published

Attackers can crash applications parsing untrusted PDFs using lopdf by sending a small file with deeply nested objects, causing a stack overflow.

Exploited in the wild
Not known
Login needed
Not needed
Attackable
Over the internet
Victim action needed
Not needed
Fix
Available

What is GHSA-6fj4-rcr3-r7rr?

GHSA-6fj4-rcr3-r7rr is a denial of service vulnerability in lopdf, published on 21 Jun 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

Official 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.

Which versions are affected by GHSA-6fj4-rcr3-r7rr?

3 open source packages ship an affected version, including lopdf.

PackageAffectedFixed in
lopdf crates.ioAll versions0.42.0
lopdf crates.ioAll versions0.42.0
lopdf crates.ioFrom 0.0.0-00.42.0

How do I fix GHSA-6fj4-rcr3-r7rr?

Upgrade lopdf to 0.42.0 or later.

Upgrade, then put limits on request size, rate and nesting depth so one client cannot exhaust the service. More about Denial of service.

Is GHSA-6fj4-rcr3-r7rr being exploited?

There is no known exploitation of GHSA-6fj4-rcr3-r7rr in the wild and no public exploit code.

Sources

Also known as RUSTSEC-2026-0187.

Is GHSA-6fj4-rcr3-r7rr in your software?

Upload an SBOM and sbomify checks it against every vulnerability here, every day.

Check your SBOMs for free