EUVD-2026-54615
GHSA-fp3f-mc75-235c
Severity by source
CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network vector applies to the common automated-PDF-processing deployment; no privileges or user interaction needed beyond supplying the crafted PDF; impact is availability-only.
Primary rating from Vendor (https://github.com/py-pdf/pypdf).
CVSS VectorVendor: https://github.com/py-pdf/pypdf
Lifecycle Timeline
2Blast Radius
ecosystem impact- 45 pypi packages depend on pypdf (9 direct, 36 indirect)
Ecosystem-wide dependent count for version 6.15.0.
DescriptionCVE.org
Impact
An attacker who uses this vulnerability can craft a PDF which leads to large memory consumption. This requires parsing the /ToUnicode entry of a font with unusually large values, for example during text extraction.
Patches
This has been fixed in pypdf==6.15.0.
Workarounds
If you cannot upgrade yet, consider applying the changes from PR #3944.
AnalysisAI
Uncontrolled memory consumption in pypdf's /ToUnicode CMap parser allows a remote attacker to cause denial of service by supplying a crafted PDF containing font entries with abnormally large bfrange code or string tokens. All pypdf versions prior to 6.15.0 are affected when performing text extraction operations. No public exploit or active exploitation is identified, but the fix is straightforward and the attack requires only the ability to supply a PDF to an application using the library.
Technical ContextAI
pypdf is a pure-Python PDF manipulation library (pkg:pip/pypdf). The affected code resides in pypdf/_cmap.py, specifically the parse_bfrange function responsible for decoding /ToUnicode CMap streams embedded in PDF font objects. CMap streams map glyph codes to Unicode code points; the bfrange operator defines contiguous ranges. Prior to 6.15.0, the parser applied no upper bounds on the byte length of individual code or string tokens when iterating over these ranges. Because range entries are stored in a dictionary in memory, a maliciously crafted CMap with oversized token values - e.g., a code spanning thousands of hex characters - could force unbounded memory allocation. CWE-400 (Uncontrolled Resource Consumption) captures the root cause: the library trusted attacker-controlled data sizes without enforcing a limit. The fix introduces MAX_CMAP_CODE_BYTES=8 (16 hex-char limit) and MAX_CMAP_STRING_BYTES=512 (1024 hex-char limit), enforced via a _check_token_length function that raises LimitReachedError on violation.
RemediationAI
Upgrade pypdf to version 6.15.0 or later using 'pip install --upgrade pypdf>=6.15.0'; this is the vendor-released patch confirmed at https://github.com/py-pdf/pypdf/releases/tag/6.15.0. If an immediate upgrade is not possible, apply the upstream fix manually from PR #3944 (https://github.com/py-pdf/pypdf/pull/3944) or the corresponding commit at https://github.com/py-pdf/pypdf/commit/afba8080e19d29a3c256a742b340995e695b35aa, which adds token-length guards to pypdf/_cmap.py. As a compensating control for services that cannot be patched immediately, restrict which PDF files reach the pypdf parser: validate file size, quarantine uploads to sandboxed worker processes with memory limits (e.g., ulimit -v or Docker memory constraints), and terminate workers that exceed a defined threshold. Note that memory-limiting worker processes will cause processing failures for legitimate large PDFs, so it should be paired with a retry queue rather than used as a permanent measure.
Same weakness CWE-400 – Uncontrolled Resource Consumption
View allSame technique Denial Of Service
View allVendor StatusVendor
SUSE
Severity: ModerateShare
External POC / Exploit Code
Leaving vuln.today