CVE-2026-102993 is a High severity denial of service in pypdf, the pure Python PDF library. Before version 6.17.0, a crafted PDF with very large Roman numeral page labels can make the library build enormous strings and exhaust memory. Upgrading to 6.17.0 or later fixes it, and 6.19.0 covers the whole pypdf series.
What's affected
- Package: pypdf (pip), maintained by the pypdf project.
- Affected: all versions before 6.17.0, per the project advisory.
- Fixed: 6.17.0, released 4 September 2026 according to the release page.
- Trigger: the application retrieves page labels from a document that carries oversized Roman numeral values.
The record gives a CVSS score of 7.5 and a severity of High. The project's own GitHub advisory labels this issue Moderate. Both are shown here. Treat the score as a prioritisation input and judge the real impact by whether untrusted PDFs reach your parser.
How to check if you're exposed
pypdf is a Python package, so start with the version installed in each environment that handles PDFs.
pip show pypdf
pip freeze | grep -i pypdf
grep -ri "pypdf" requirements*.txt pyproject.toml poetry.lock uv.lock Pipfile.lock 2>/dev/null
Check every place a PDF is parsed: web upload handlers, background workers, document pipelines and notebooks. Containers matter too, because an old image can pin an old pypdf long after the source repository moved on. Also look at transitive installs. Another library may pull pypdf in without listing it in your own requirements file.
Safeguard's free in-browser dependency scan at gold.safeguard.sh/scan reads a manifest or lockfile and shows which packages carry known CVEs, including this one. Nothing is installed and nothing leaves your browser session beyond the scan itself.
What to do now
- Upgrade pypdf to 6.17.0 or later in every environment that parses PDFs. Version 6.19.0 or later covers every pypdf advisory in this series of posts.
- Run your PDF test suite after the upgrade. Pay attention to any code that reads page labels, since that is the path this issue touches.
- Rebuild container images and redeploy so old layers do not keep the vulnerable package.
- Put limits around PDF handling in the meantime: file size caps, a time limit per job, and a memory limit on the worker, so one bad file cannot take the service down.
- Re-scan your lockfiles after the change to confirm no second copy of pypdf remains.
Why it matters
The weakness is uncontrolled resource consumption, filed as CWE-400 and CWE-770. The library lets a value inside the file decide how large an output string becomes. A small PDF can therefore ask for a very large allocation, and the process pays for it.
The advisory says the problem needs the application to access the page labels of such a document. That narrows exposure: an app that only extracts text never touches this code. A service that shows page numbers to users, or exports labels as metadata, does. The record does not list this CVE as exploited in the wild, and it is not in the CISA Known Exploited Vulnerabilities catalog.
The fix limits the value used for Roman numerals. Reachability analysis is a good way to decide urgency here, because it tells you whether any code path in your application calls the page label API at all.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Does this affect text extraction?
The advisory ties this issue to retrieving page labels. Text extraction is a different code path, though other pypdf advisories in the same release series cover it.
Is a workaround available?
The advisory says to consider applying the changes from pull request 4047 if you cannot upgrade yet. Upgrading is simpler and safer.
Sources
Last reviewed: 18 October 2026.
