RustSec flags lopdf PDF parser stack overflow in nested arrays

A crafted PDF of about 21 KB, with a Catalog /X value built from roughly 10,380 opening brackets and the same number of closing brackets, can push lopdf into SIGABRT. RustSec flagged lopdf with RUSTSEC-2026-0187 on June 26 after finding that nested PDF arrays and dictionaries could drive the parser into unbounded recursion and exhaust the call stack. The failure is a stack-overflow abort, not a panic, so catch_unwind cannot recover the process.

The vulnerable path runs through lopdf::Document::load_mem and other load* entry points, which puts the blast radius on applications that parse untrusted PDFs directly. That includes upload pipelines, document indexing services, server-side rendering tools, and ingestion jobs that accept files from outside the trust boundary. RustSec rated the issue CVSS 3.1 7.5 High, with a network attack vector, low attack complexity, no privileges, no user interaction, and high availability impact. The issue was confirmed on lopdf 0.41.0 and earlier, so projects that only depend on lopdf indirectly are not the immediate exposure point unless their own code actually feeds attacker-controlled PDFs into those parser APIs.

The fix is in lopdf 0.42.0, and PDF parsers need to cap nesting depth and return an error instead of recursing forever. Teams that process outside documents should pin or upgrade to 0.42.0, review every place that calls load_mem or another load* method, and reject pathological object graphs before they reach the parser. The crash arises from structure, not from memory unsafety in the usual sense, so fuzzing PDF inputs is useful.

GitHub issue #502 opened on June 21 to coordinate before final publication, and the advisory links pull request #503 and commit c755394 as part of the fix path. The lopdf repository now shows a Release 0.42.0 entry in its changelog.