EUVD-2026-90272
GHSA-v247-6f48-mgcj
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft PDF with many embedded files
-
DeliverySubmit to pypdf-based application
-
ExploitApplication accesses attachments mapping
-
ExecutionTrigger repeated full-list reparsing
-
PersistCPU exhaustion stalls worker
-
ImpactDenial of service
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V2 - Validation and Business Logic Resource consumption limits
MITRE ATT&CK
1 technique across 1 tactic: Impact The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires (1) an application built on pypdf prior to 6.19.0, (2) that application processing an attacker-supplied PDF containing many embedded files, and (3) the application accessing the dictionary-based attachments API (the embedded-file mapping) in pypdf/_doc_common.py, which reparses the full attachment list on each content lookup. The limiting factor is that this is not triggered by mere parsing/opening - the application must specifically enumerate or read attachments, so deployments that never touch embedded files are not exposed. Impact is confined to availability (CPU/time exhaustion of the processing worker); there is no code execution, data disclosure, or integrity impact. |
| Impact | This is a genuine but bounded availability issue, not a critical priority. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) scores 8.7 solely on the strength of a network vector plus high availability impact, with zero confidentiality or integrity impact - the 8.7 substantially overstates real-world urgency for a pure algorithmic-complexity DoS. The 'network, no auth' framing is technically accurate only in the sense that a malicious PDF can arrive over the network, but exploitation actually requires an application to feed the crafted PDF to pypdf AND to access the embedded-file attachments mapping, so the trigger is contingent on how the consuming application uses the library. No EPSS score, no CISA KEV listing, and no public exploit code are present in the provided data, indicating no confirmed or probable active exploitation. The SSVC technical impact is partial (availability only, no code execution, no data exposure) and there is no automatable mass-exploitation path. My independent 3.1 assessment lands at ~7.5 (A:H only). Net: treat as a routine dependency patch, not an emergency. |
| Exploit ScenarioDerived | An attacker submits a crafted PDF containing a very large number of embedded files to an application that uses pypdf and enumerates or reads the document's attachments. When the application accesses the dictionary-based attachments mapping, pypdf reparses the entire attachment list for every content lookup, producing O(n²) work that consumes CPU and stalls the worker for an extended period, degrading or denying service. No public exploit code is identified at time of analysis, and the attack requires the consuming application to actually access the embedded-file mapping. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Denial of service in pypdf versions prior to 6.19.0 allows an unauthenticated remote attacker to pin a PDF-processing worker by supplying a document containing a large number of embedded files, because the dictionary-based attachments API re-enumerates and reparses the entire /EmbeddedFiles attachment list on every content lookup instead of indexing it once. The impact is limited to availability (CPU and wall-clock exhaustion); there is no code execution, data disclosure, or integrity impact, and the exposure is conditional on the host application actually enumerating or reading embedded-file attachments rather than merely opening the PDF. No public exploit identified at time of analysis, and the issue is fixed in the vendor's 6.19.0 release, so this should be treated as a bounded availability bug rather than a critical priority.
RemediationAI
Primary fix: upgrade to the vendor-released patched version, pypdf 6.19.0 (available from PyPI or via https://github.com/py-pdf/pypdf/releases/tag/6.19.0), which rebuilds the attachment index in a single pass; the corresponding upstream change is commit 6b10556d13609a68f9ed18bb29fdd8bba88eb2c3 in PR https://github.com/py-pdf/pypdf/pull/4081, and the advisory is GHSA-v247-6f48-mgcj. When upgrading, note that patched pdf.attachments values are normalized to lists of byte strings, so audit downstream code that consumed the previous bytes-or-list shape. If an immediate upgrade is not possible, stop calling the attachments API (pdf.attachments, attachment_list, or the legacy private _get_attachments/_list_attachments helpers) on untrusted documents whenever embedded-file metadata is not actually required, and reject or strip PDFs whose catalog contains /EmbeddedFiles at upload ingress - with the trade-off that name trees can be obfuscated and legitimate archival or portfolio PDFs with attachments will be blocked. Where attachment handling must stay enabled, isolate pypdf parsing so it runs under a hard per-document CPU or wall-clock limit in a killable subprocess or task pool, and cap the number of embedded files or total document size accepted, accepting that aggressive limits may terminate or reject large legitimate documents. Deployments that never enumerate attachments remain unaffected and can treat the upgrade as routine maintenance.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in pypi
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
pypdf is a pure-Python PDF library often embedded in document-ingest pipelines, mail/archive scanners, and upload preview services, all of which routinely parse attacker-controlled files. The affected code lives in the attachments machinery in pypdf/_doc_common.py and pypdf/generic/_files.py: the attachments mapping is backed by a generator over EmbeddedFile objects derived from the document's /Names tree, and the pre-6.19.0 implementation of _get_attachments()/attachment_list walked that entire generator for every requested filename, including matching against each entry's name and alternative_name. With N embedded files and M lookups, that yields roughly N×M traversal and content extraction work, an algorithmic-complexity/resource-exhaustion condition classified as CWE-400 (Uncontrolled Resource Consumption). The fix removes the repeated scans: EmbeddedFile gains an internal _names iterator yielding the file name and alternative name, the classmethod _get_attachment_contents() extracts contents from an already-resolved entry list, and the attachments mapping is built from a single pass that groups entries into a dict keyed by name, with several type hints narrowed from Generator to Iterator. The patch also changes the public mapping semantics so each value is consistently a list of byte strings, which downstream consumers of pdf.attachments should verify. The single CPE entry, cpe:2.3:a:py-pdf:pypdf:*:*:*:*:*:*:*:*, with a wildcard version, indicates that all releases before the fixed version are in scope rather than one narrowly pinned build.
Know when Pypdf gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
A crafted PDF reaches the library over the network without auth or interaction (AV:N/PR:N/UI:N), and impact is availability-only via algorithmic complexity, so C:N/I:N/A:H; contingent app access to attachments keeps it realistic but does not raise AC.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
2DescriptionCVE.org
pypdf is a free and open-source pure-python PDF library. Prior to 6.19.0, a crafted PDF containing many embedded files can cause the dictionary-based attachments API in pypdf/_doc_common.py to reparse the full attachment list for each content lookup, producing repeated work and long runtimes when an application accesses the embedded-file mapping. This issue is fixed in version 6.19.0.
Blast Radius
ecosystem impact- 58 pypi packages depend on pypdf (15 direct, 43 indirect)
Ecosystem-wide dependent count for version 6.19.0.
Technical POC Analysis
CWE-400 (Uncontrolled Resource Consumption), also classified by the vendor under CWE-407 (Inefficient Algorithmic Complexity).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
pypdf versions prior to 6.19.0 contain a denial-of-service vulnerability that can pin PDF-processing workers when a malicious document with many embedded files is processed by applications that enumerate attachments. Organizations using pypdf in services that handle untrusted PDFs and read embedded-file attachments may experience CPU and wall-clock exhaustion, disrupting availability, though there is no risk of code execution, data disclosure, or integrity loss. No public exploit identified at time of analysis, and the vendor has released 6.19.0 to address the issue.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Denial of Service attacks render applications or systems unavailable by overwhelming resources or triggering failure conditions.
Infinite loop denial of service in pypdf prior to 6.16.0 allows any attacker who can supply a crafted PDF to a pypdf-bas
pypdf is a pure-python PDF library capable of splitting, merging, cropping, and transforming the pages of PDF files. Rat
pypdf is a pure-python PDF library capable of splitting, merging, cropping, and transforming the pages of PDF files. Rat
pypdf is an open source, pure-python PDF library. Rated medium severity (CVSS 5.5), this vulnerability is no authenticat
Resource exhaustion in pypdf prior to 6.16.1 allows an attacker who can supply a crafted PDF to cause denial of service
Memory exhaustion in pypdf versions prior to 6.19.0 allows a remote, unauthenticated attacker to make an application una
Denial of service in pypdf versions prior to 6.19.0 allows remote, unauthenticated attackers to exhaust application CPU
Denial of service in pypdf before 6.18.1 lets a crafted PDF drive the library's FlateDecode recovery path into inefficie
Memory exhaustion in pypdf versions prior to 6.18.1 lets a crafted PDF force the library to allocate and process far mor
Memory exhaustion in pypdf versions prior to 6.18.1 allows unauthenticated remote attackers to crash or degrade any appl
Denial of service in pypdf versions prior to 6.18.0 allows remote, unauthenticated attackers to stall PDF parsing by sup
Memory-exhaustion denial of service in pypdf versions prior to 6.17.0 allows remote attackers to inflate application mem
Exploit-DB