pypdf CVE-2026-115580

Exploitation requires a vulnerable pypdf version (< 6.21.2) to open/parse an attacker-supplied PDF whose standard cross-reference table declares an entry count larger than the file can contain; the vendor fix adds a size check (declared size must not exceed stream_size // 20) that rejects such tables. The key limiting factor is UI:P - some application or user must actually process the malicious file, so the practical exposure is systems that ingest untrusted PDFs (upload portals, mail/attachment scanners, OCR/document pipelines). No authentication is required (PR:N), impact is limited to availability (no data exposure or modification), and the only complete fix stated by the vendor is upgrading to 6.21.2, with a workaround of applying the changes from PR #4239.

This is a denial-of-service issue (CWE-834, excessive iteration) in the pypdf library, not an exploitation-for-code-execution flaw. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H) correctly reflects availability-only impact with no confidentiality or integrity loss: a crafted cross-reference table declares an entry count larger than the file can actually contain, making pypdf iterate/process far more than warranted and consume excessive CPU time. Several signals point to moderate rather than urgent priority: there is no CISA KEV listing (not confirmed actively exploited), no EPSS score was provided in the input (exploitation probability cannot be quantified from the data), and the vuln.today decision label is 'this_week' rather than act_now/emergency. The exploitation requirement UI:P means an application or user must actually open/parse the malicious PDF, so this is not a wormable, fully-unattended network attack. The one notable caveat: the input Tags label this 'Information Disclosure,' which directly contradicts the CVSS vector (VC:N - no confidentiality impact) and the CWE - treat this as a resource-exhaustion/DoS issue, not disclosure. Overall this is a genuine but bounded availability risk, most relevant to services that ingest untrusted PDFs at scale.

An attacker crafts a PDF whose standard cross-reference table declares an entry count far exceeding what the file size can hold, then submits it to any service or application that parses PDFs with a vulnerable pypdf version (e.g., an upload/OCR/document-processing pipeline). When the file is opened, pypdf spends excessive time processing the inflated table, tying up CPU and worker threads and degrading or denying service. No public, verified working exploit code was identified in the input; the referenced PR, commit, and release are the vendor fix, not an exploit.