EUVD-2026-90283
GHSA-w23x-9jrw-r45c
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessCraft PDF with oversized /St alphabetical page-label
-
DeliveryDeliver PDF to pypdf-based service
-
ExploitApplication calls page-label retrieval
-
Execution_page_labels.py generates huge string
-
ImpactMemory exhaustion, service unavailable
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 | Requires that the target application (a) parses a PDF from an untrusted source using pypdf prior to 6.19.0 and (b) actively retrieves document page labels, which is what invokes the vulnerable code path in _page_labels.py. The malicious PDF must contain a page-label entry with an alphabetical numbering style (/S /A or /S /a) and an unusually large /St start value so the generated label string grows far beyond a reasonable length. Limiting factors: applications that never read page labels are not affected even if they open the PDF, and the impact is confined to availability (memory exhaustion / crash) with no data exposure or code execution; no authentication or user interaction beyond causing the app to process the file is required. |
| Impact | This is a genuine but bounded denial-of-service issue, not a high-severity RCE despite the 8.7 CVSS 4.0 score. The vendor vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H) correctly shows availability-only impact - VC:N and VI:N confirm no confidentiality or integrity consequence - so the 8.7 is inflated by CVSS 4.0's availability weighting rather than reflecting broad real-world risk. No EPSS score, no CISA KEV listing, and no public exploit code are provided, so exploitation status is: no public exploit identified at time of analysis. The 'network' attack vector is technically accurate only in that malicious PDFs travel over networks; actual triggering requires the victim application to both ingest an attacker-supplied PDF and call pypdf's page-label retrieval API, which meaningfully narrows exploitability below what AV:N/PR:N/UI:N alone suggests. The fix (512-character MAXIMUM_PAGE_LABEL_LENGTH cap) is confirmed in PR #4096 / commit 0d8b5a8 and release 6.19.0. Overall this is a low-to-medium remediation priority: patch during normal cycles, prioritized higher only for services that parse untrusted PDFs and read page labels. |
| Exploit ScenarioDerived | An attacker uploads or emails a crafted PDF whose page-label dictionary sets an alphabetical style (/A or /a) with an enormous /St start value to a service that processes untrusted PDFs with pypdf. When the application retrieves document page labels, pypdf's _page_labels.py expands the value into an extremely long string, exhausting memory and rendering the worker or service unavailable. No public exploit code is identified, but the trigger is trivial to construct given the disclosed root cause. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Sep 30, 2026
Memory exhaustion in pypdf versions prior to 6.19.0 allows a remote, unauthenticated attacker to make an application unavailable by supplying a crafted PDF whose page-label numbering tree uses an alphabetical style (/S /A or /S /a) with an oversized /St start value, causing the library to generate pathologically long label strings when an application requests document page labels. The impact is strictly availability-related (C:N/I:N/A:H) with no data exposure, integrity loss, or code execution, and it only triggers if the consuming application actually reads page labels rather than merely opening the file. There is confirmed actively exploited status: no public exploit identified at time of analysis, and no vendor-released patch identified at time of analysis beyond the fixed release 6.19.0; the independent assessment rates this as a genuine but bounded denial-of-service rather than an RCE despite the elevated CVSS 4.0 score of 8.7.
RemediationAI
Upgrade pypdf to 6.19.0, which contains the MAXIMUM_PAGE_LABEL_LENGTH = 512 cap in pypdf/_page_labels.py and makes oversized /St values raise ValueError and be treated as malformed entries rather than generating huge strings (see https://github.com/py-pdf/pypdf/releases/tag/6.19.0 and the advisory https://github.com/py-pdf/pypdf/security/advisories/GHSA-w23x-9jrw-r45c). If an immediate upgrade is not possible, the most direct compensating control is to avoid invoking page-label retrieval on untrusted input: applications that do not need labels should simply not call the page-label APIs, since the vulnerable code path is only reached when labels are requested (trade-off: any feature that displays original page numbering will be unavailable or must be approximated from page indices). Because the issue is resource exhaustion rather than memory corruption, running PDF parsing in an isolated worker process bounded by an OS memory limit and a wall-clock timeout (for example, RLIMIT_AS plus a subprocess timeout) will contain the impact at the cost of additional process-management complexity and the need to tune limits so legitimate large documents still succeed. A further option is to pre-validate or sanitize the /PageLabels /Nums array before processing, rejecting or rewriting entries whose /S is /A or /a and whose /St exceeds roughly 13,312, which mirrors the upstream threshold but requires maintaining custom parsing logic; note that the upstream fix is the only change that has been regression-tested against the project's own suite, so bespoke sanitizers should be treated as temporary. No vendor-released patch was identified for versions older than 6.19.0, so upgrading remains the recommended and supported path.
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
The flaw is an uncontrolled resource consumption issue (CWE-400) in pypdf's page-label handling module, pypdf/_page_labels.py. PDF page labels are described by a /PageLabels dictionary containing a /Nums array in which each entry pairs a page index with a label dictionary; the /S key selects the numbering style (including alphabetical styles /A and /a) and /St gives the starting value. When the alphabetical style is used, the library converts the numeric start value into a repetition of the corresponding letter, so a very large /St value produces a label string whose length grows without bound. A malicious PDF can therefore supply a /St value large enough that generating the label consumes excessive memory, potentially rendering the host application unavailable. The upstream fix introduces MAXIMUM_PAGE_LABEL_LENGTH = 512 in _page_labels.py, capping /A and /a output at 512 * 26 = 13,312 (a deliberately arbitrary trade-off between roughly 256 and 1,000 output bytes per label); values above the limit now raise ValueError("Number is too large.") and are logged as an ignored malformed page-label entry, with the test suite confirming that /St=13,312 yields 512 characters while /St=13,313 and /St=15,000 are rejected and fall back to "1". The affected product is the pure-Python pypdf library, identified by the wildcard-version CPE cpe:2.3:a:py-pdf:pypdf, meaning every release before the patched version is in scope regardless of platform.
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
Malicious PDF reaches the library over the network with no auth or interaction (AV:N/PR:N/UI:N); impact is memory-exhaustion availability only, so C:N/I:N/A:H.
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 can provide unusually large alphabetical page-label values that cause pypdf/_page_labels.py to generate strings beyond a reasonable page-label length when an application retrieves document page labels, consuming excessive memory and potentially making the application unavailable. 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).
Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.
Executive ViewAI
A memory-exhaustion flaw in the pypdf library (all versions before 6.19.0) lets an attacker take down any application that reads page labels from an untrusted PDF, turning an ordinary file upload into a sustained service outage. The organizations at risk are those exposing document processing to outside parties - invoice and claims ingestion, customer-facing PDF viewers, report generation, and any automated pipeline that parses files it did not author. Leadership should treat this as an availability and resilience problem for PDF-handling services rather than a data-breach exposure; there is no data theft, integrity loss, or code execution associated with it, but repeated, low-cost denial of service against a customer-facing workflow is a business continuity and reputational issue.
No vendor-released patch identified at time of analysis, although the source analysis points to upstream pypdf 6.19.0 as the fixed release - upgrade to 6.19.0 or later as the primary remediation. Until every consumer is upgraded, apply the vendor patch where the 6.19.0 release can be adopted; where it cannot, avoid calling page-label functions on untrusted PDFs, cap accepted PDF size, cap generated label output length, run PDF parsing in a sandboxed worker with strict memory/CPU/time limits and automatic restart, and monitor for OOM kills and processing backlogs.
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
Denial of service in pypdf versions prior to 6.19.0 allows an unauthenticated remote attacker to pin a PDF-processing wo
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