CVE-2026-102999 is a High severity denial of service in pypdf. Before version 6.19.0, a PDF with many embedded files makes the dictionary based attachments API reparse the whole attachment list for each lookup, which can cause very long runtimes. Upgrade to 6.19.0 or later.
What's affected
- Package: pypdf (pip).
- Affected: all versions before 6.19.0, per the project advisory.
- Fixed: 6.19.0, released 16 September 2026 according to the release page.
- Trigger: accessing the embedded file mapping of a PDF that contains many attachments.
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.
Search your code for the attachments property on readers and writers. If nothing reads embedded files, the trigger path is not used.
What to do now
- Upgrade pypdf to 6.19.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. If you extract attachments, test with a document that holds several embedded files.
- 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
Again CWE-400 and CWE-407. Each lookup into the mapping caused a full pass over the attachment list, so reading n files cost roughly n squared work. A file with thousands of tiny attachments turns that into a long stall.
The 6.19.0 release notes describe the fix as reducing the number of full data lookups for the attachment mapping API. It is as much a performance fix as a security one, and the advisory treats it that way: the attacker's contribution is only to make the file large enough in the right dimension.
Check whether you process attachments at all. Many services never do, in which case the trigger path is absent. The record does not list this CVE as exploited in the wild.
Quick check
Is there a size limit that helps?
A cap on upload size and a per job timeout both reduce the damage, but the real fix is the upgrade to 6.19.0.
Which API is involved?
The dictionary based attachments API in the document helper code, per the advisory text.
Sources
Last reviewed: 18 October 2026.
