Listen to this Post
The vulnerability arises from the absence of input validation on the `/Size` field in a cross‑reference (xref) stream and the `/N` field in an object stream. In a PDF, the xref stream defines the number of indirect objects via its `/Size` entry; similarly, an object stream declares how many objects it contains via its `/N` entry. When pypdf parses a maliciously crafted PDF, it reads these integer values and then attempts to iterate over the claimed number of entries. An attacker can set `/Size` or `/N` to an arbitrarily large number (e.g., 2^31‑1) while providing only a few actual entries. Because pypdf does not limit the iteration count based on the real stream size, the library enters a loop that consumes CPU cycles for each claimed entry. This results in extremely long processing times, effectively a denial‑of‑service condition. The vulnerable code paths are in the handling of xref streams and object streams, where the library trusts the user‑supplied size parameters without any bound checks against the actual data length. The fix introduces a dynamic limit: the iteration is capped by both the declared size and the real stream size, ensuring that the processing time remains proportional to the actual data. The patch (PR 3733) adds safety checks that prevent excessive loops when either `/Size` or `/N` is unreasonably large.
DailyCVE Form
Platform: pypdf
Version: <6.10.1
Vulnerability: Uncontrolled Resource Consumption
Severity: Moderate
Date: 2026‑04‑15
Prediction: Already Patched (6.10.1)
Analytics – What Undercode Say
Check installed pypdf version
pip show pypdf | grep Version
Test for the vulnerability using a crafted PDF
python -c "from pypdf import PdfReader; PdfReader('malicious.pdf')"
Minimal PoC to trigger the excessive iteration
from pypdf import PdfReader
Craft a PDF with an xref stream having /Size = 231-1 but only one entry
(Actual creation omitted for brevity)
reader = PdfReader("evil.pdf") This will hang indefinitely
Exploit
An attacker crafts a PDF file containing a cross‑reference stream where the `/Size` field is set to a huge integer (e.g., 2,147,483,647) while the stream data contains only a single entry. When pypdf processes this xref stream, it attempts to iterate from 0 to the declared size, causing a CPU‑intensive loop. The same technique applies to object streams using the `/N` field. No special privileges are needed; the victim only needs to open the malicious PDF with any application that uses the vulnerable pypdf version.
Protection from this CVE
- Upgrade to pypdf 6.10.1 or later.
- If upgrading is not immediately possible, backport the changes from PR 3733.
- As a workaround, apply the following manual patch: add a check that limits the iteration count to the actual stream size (e.g.,
max_entries = min(declared_size, actual_stream_length / entry_width)). - Avoid processing PDFs from untrusted sources with pypdf versions prior to 6.10.1.
Impact
Successful exploitation leads to a denial‑of‑service condition where the application becomes unresponsive for an extended period. The CPU usage spikes, and the process may appear hung. This can be leveraged to disrupt services that rely on pypdf for automated PDF processing (e.g., document upload portals, mail servers, or PDF conversion tools). The vulnerability does not lead to memory corruption or remote code execution; its impact is limited to availability. The CVSS score is 5.5 (moderate).
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
