CVE-2026-102997 is a High severity denial of service in pypdf. Before version 6.18.1, a partly malformed FlateDecode stream with padded data can push the library into slow byte by byte decompression. It is a residual issue after an earlier fix. Upgrade to 6.18.1 or later.
What's affected
- Package: pypdf (pip).
- Affected: all versions before 6.18.1, per the project advisory.
- Fixed: 6.18.1, released 11 September 2026 according to the release page.
- Trigger: a partially malformed FlateDecode stream where the byte by byte decompression fallback is used.
- Context: the advisory calls it a follow-up to the earlier malformed FlateDecode recovery fix.
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.1 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. Include a corrupt or truncated PDF in your tests, since this fix touches the recovery path for damaged streams.
- 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 inefficient algorithmic complexity, CWE-407, which leads to CWE-400. FlateDecode is the compression used for most PDF streams. When a stream is damaged, pypdf tries to salvage what it can by decoding byte by byte, which is slow by design.
The earlier fix added a counter to stop that recovery from running forever. The advisory for this CVE explains that the counter failed to advance for bytes that decoded successfully, so padded data could keep the loop going. The 6.18.1 release notes say it further restricts FlateDecode recovery.
The cost is time, not memory, so the symptom is stuck workers. The record does not list this issue as exploited in the wild. A per job timeout turns a hang into a failed job.
Quick check
Why is this called a follow-up?
An earlier release fixed malformed FlateDecode recovery. This CVE covers a remaining case where the recovery counter did not advance.
Does it need a special pypdf feature?
No. Reading a PDF that contains such a stream is enough, because recovery happens during normal decoding.
Sources
Last reviewed: 18 October 2026.
