CVE-2026-102994 is a High severity denial of service in pypdf. Before version 6.18.0, a crafted PDF with very long indirect object headers that are not ended by whitespace can keep the parser scanning for a long time. Upgrade to 6.18.0 or later; the maintainers fixed it in that release.
What's affected
- Package: pypdf (pip).
- Affected: all versions before 6.18.0, per the project advisory.
- Fixed: 6.18.0, released 7 September 2026 according to the release page.
- Trigger: reading a PDF whose indirect object headers run on without a terminating whitespace character.
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.18.0 or later. Going straight to 6.19.0 covers every pypdf advisory in this series of posts.
- Read the 6.18.0 release notes before you deploy. They say users who previously overwrote the default parser limits must move to the new configuration approach, using apply_configuration or overwrite_configuration.
- Run your PDF tests, including any that rely on custom limits, to make sure behaviour matches what you expect.
- Enforce a wall clock timeout on every PDF job so a stuck parse is killed and retried or rejected.
- Rebuild images and re-scan lockfiles to confirm no older pypdf is left behind.
Why it matters
This is an algorithmic complexity problem, tracked as CWE-400 and CWE-407. The reader scans forward for a token boundary, and a file can be shaped so that the scan covers far more input than any real document would need.
No memory blowup is involved. The cost is time. A worker thread is held while the scan runs, and a handful of such files can occupy every worker in a pool. For an upload service this looks like an outage rather than a breach.
The record does not mark this as exploited in the wild. The fix in 6.18.0 comes with a configuration change, so plan a little testing time. If you cannot upgrade immediately, timeouts and size limits are the practical stopgap.
Quick check
What kind of impact does this have?
Availability. A crafted PDF makes the parser run for a long time, which can tie up workers and make the application unavailable.
Can the project's advisory help if I cannot upgrade?
It points to pull request 4055 as a change you could apply yourself. Check that your pypdf version is close enough to apply it cleanly.
Sources
Last reviewed: 18 October 2026.
