CVE-2026-102996 is a High severity denial of service in pypdf. Before version 6.18.1, a crafted PDF can give a TrueType or Type1 simple font an unusually large Widths array and make text extraction use excessive memory. Upgrade to 6.18.1 or later; 6.19.0 covers the whole series.
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: parsing the Widths entry of a TrueType or Type1 font with unusually large values, for example during text extraction.
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. Spot check text extraction on documents that use embedded TrueType and Type1 fonts.
- 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
Another CWE-400 case. A simple font only has 256 meaningful character codes, yet the code in pypdf's font module processed every entry in the Widths array, however long. The release notes say the fix limits the entry count for TrueType and Type1 font widths.
The lesson is a common one for file parsers. Any length or count field read from the file is attacker input. If the code allocates or loops based on it, the file controls your resource use.
The record does not list this CVE as exploited in the wild. If a patched version is available, upgrade. If not yet possible, run PDF work in a process with a hard memory ceiling, so an oversized file kills one job instead of the host.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Is this the same bug as the ToUnicode one?
No. It is a separate issue in the font width handling, fixed in the same 6.18.1 release as the ToUnicode and FlateDecode follow-ups.
What does the fix do?
The release notes describe it as limiting the entry count for TrueType and Type1 font Widths.
Sources
Last reviewed: 18 October 2026.
