Py Pdf
Monthly
Parsing a crafted PDF with pypdf prior to 6.21.2 can drive the library into repeated cross-reference recovery cycles, consuming CPU and time in the parsing process until the workload stalls. This is a follow-up to GHSA-55h5-xmcq-c37v: the earlier fix cached recovery state, but the parser still reloaded the entire PDF stream on each recovery attempt, so repeated malformed cross-reference stream entries still produced long runtimes. Anyone whose application, service, or automated pipeline ingests untrusted PDFs with an affected version remains exposed - including environments that already applied the prior advisory's fix - and exposure ends only with 6.21.2, since no public exploit code has been identified at time of analysis and the impact is limited to availability, with no disclosure, modification, or code execution path.
Denial of service in pypdf before 6.21.2: a crafted PDF whose standard cross-reference table declares a larger entry count than the file can physically contain drives the parser into excessive iteration and long runtimes simply when the document is opened. The CVSS vector shows no privileges required (PR:N) but a victim interaction of opening or processing the file (UI:P), so the realistic exposure is services that ingest untrusted PDFs such as upload portals, mail/attachment scanners and OCR or document pipelines. Impact is availability-only (no confidentiality or integrity effect), the vendor fix is version 6.21.2, and no public exploit code was identified at the time of analysis.
Denial of service in pypdf before 6.21.2 lets a crafted PDF stall parsing by referencing the same non-existent indirect object many times, forcing repeated full-file recovery loads and long runtimes. The flaw is remotely reachable without authentication (CVSS:4.0 AV:N/PR:N, assessed CVSS:3.1 AV:N/AC:L/PR:N), but it only fires when a vulnerable pypdf instance actually loads the attacker-supplied file, so exploitation requires a user or automated pipeline to open or process the malicious PDF (UI:P). Impact is limited to availability - CPU and time exhaustion in the parsing process - with no confidentiality or integrity effect; this is a moderate-severity, this-week-priority issue, and no public exploit code was identified at time of analysis.
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.
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.
Denial of service in pypdf versions prior to 6.19.0 allows remote, unauthenticated attackers to exhaust application CPU by supplying a crafted PDF whose AcroForm choice field carries a large number of options and selected values; when a consuming application calls update_page_form_field_values with flatten=True, the appearance-stream generator recomputes the same invariant selection-glyph set once per line, driving runtimes up until the host process or worker becomes unavailable. The flaw is rated CVSS 4.0 8.7 (and 3.1 8.1 by independent assessment) with availability-only impact - no confidentiality or integrity loss, and no code execution. Exploitation requires the application to explicitly perform form-field updates with flattening on attacker-controlled input; merely opening, parsing, or reading the PDF does not reach the vulnerable code path. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); the fix ships in upstream release 6.19.0.
Denial of service in pypdf before 6.18.1 lets a crafted PDF drive the library's FlateDecode recovery path into inefficient byte-by-byte decompression, consuming CPU until the consuming application becomes unavailable. Exploitation is unauthenticated and requires only that a pypdf-based service parse or extract text from an attacker-supplied PDF (CVSS v4.0 8.7, AV:N/AC:L/PR:N/UI:N, availability-only); no public exploit identified at time of analysis. The flaw is a residual case left after the earlier malformed-FlateDecode recovery fix and is resolved in 6.18.1.
Memory exhaustion in pypdf versions prior to 6.18.1 lets a crafted PDF force the library to allocate and process far more font-width data than a simple font can legitimately hold, degrading or crashing any process that extracts text or font metrics from untrusted documents. The parser fails to cap the /Widths array of a simple TrueType or Type1 font at the 256 one-byte character codes that such fonts can actually address, so an oversized array is walked entry by entry while widths are collected. The CVSS 4.0 vector (8.7, AV:N/AC:L/PR:N/UI:N, high availability-only impact) reflects unauthenticated remote triggering with no user interaction beyond supplying the file, and the availability-only profile confirms no confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV), though the trigger is trivially reproducible by anyone who can hand a PDF to a pypdf-consuming service; a vendor patch in 6.18.1 is available.
Memory exhaustion in pypdf versions prior to 6.18.1 allows unauthenticated remote attackers to crash or degrade any application that parses attacker-supplied PDFs, by embedding oversized source-code or destination-string tokens inside a font /ToUnicode CMap. Processing such a file (for example during text extraction, which routes through pypdf/_cmap.py parse_bfchar) makes the library decode and retain these oversized values, driving availability-impacting memory consumption with no confidentiality or integrity effect. The vendor CVSS 4.0 vector (8.7, VA:H only, PR:N/UI:N) matches the assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; no public exploit code or KEV-listed active exploitation was identified at time of analysis, and a vendor-released patch (6.18.1) is available.
Denial of service in pypdf versions prior to 6.18.0 allows remote, unauthenticated attackers to stall PDF parsing by supplying a crafted file whose indirect-object identifier or generation-number token continues for an excessive length without a whitespace delimiter. The parser's read_until_whitespace helper in pypdf/_utils.py scans unbounded input, so the consuming process hangs or runs for an extremely long time, making any service that parses untrusted PDFs unavailable (CVSS 4.0 8.7, availability-only; assessed CVSS 3.1 8.0 AV:N/AC:L/PR:N/UI:N/A:H). Impact is confined to availability - there is no path to code execution or data disclosure - and no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor-released fix is available in pypdf 6.18.0.
Memory-exhaustion denial of service in pypdf versions prior to 6.17.0 allows remote attackers to inflate application memory usage by supplying a crafted PDF whose /PageLabels /Nums dictionary declares a Roman-numeral numbering style (/S /R) with an extremely large start value (/St), causing the library to construct a numeral string proportional to that value. The CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:H) indicates an unauthenticated, network-reachable, low-complexity attack with high availability impact and no confidentiality or integrity effect, but the practical precondition is that the consuming application must actually invoke pypdf's page-label retrieval on attacker-supplied documents - applications that never read page labels are unaffected. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; the vendor released a fix in 6.17.0 that rejects Roman start values above 3,999.
Denial of service in the pypdf Python PDF library (all versions prior to 6.14.1) allows a remote attacker to hang a consuming application by supplying a malicious PDF. A page content stream containing an unterminated inline image drives the inline-image end-marker detection logic into an infinite loop, most notably triggered during page text extraction. No public exploit has been identified at time of analysis, but the CVSS 4.0 score of 8.7 reflects an unauthenticated, low-complexity availability attack, and a fixed release (6.14.1) is available.
Denial of service in pypdf before 6.14.2 lets a remote attacker hang any application that parses an attacker-supplied PDF: a page content stream carrying an unterminated inline image with an ASCII85 or ASCIIHex filter drives the parser into an infinite loop (CWE-835), most notably during page text extraction. The pure-Python library is very widely used in document-processing and data-ingestion pipelines, so a single malicious file can pin a CPU core and stall the worker. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the root cause is well-described and trivially reproducible.
CPU and memory exhaustion in fpdf2 2.5.0 through 2.8.7 lets remote attackers who can submit SVG data to FPDF.image() stall or crash PDF generation workers with a sub-1 KB payload. Nested SVG <use> references are expanded by deep-copying the entire referenced graphics tree at every level, so a handful of groups that each re-reference the previous group produces exponential object growth; the advisory's reproduction (an 895-byte SVG) pinned a process for roughly 14 seconds under a 128 MB address-space limit before raising MemoryError. No public exploit tooling or active exploitation has been reported and the priority label is this_month, but a public proof-of-concept reproduction is included in the advisory; ResourceAccessPolicy does not mitigate it because all references are inline, and the issue is fixed in 2.8.8.
fpdf2 through 2.8.7 dereferences image resource references supplied to FPDF.image(), write_html() HTML <img src> values, SVG <image href>/xlink:href values and template image fields, so attacker-controlled content rendered by an integrating application can trigger outbound HTTP(S) requests to attacker-chosen internal or external destinations (CWE-918 SSRF) as well as attempts to open raw local filesystem paths. The impact is bounded: local content is only embedded when the referenced path resolves to a valid supported image or SVG resource, and file:// URLs are not specially handled, so the local-path case requires a raw path such as '../../file.png'. The vendor scores this 5.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), exploitation depends entirely on the application passing untrusted values into those APIs without an allowlist or restrictive policy, and no public exploit code has been identified at time of analysis; version 2.8.8 introduces a configurable resource_access_policy whose default blocks private, loopback and link-local network targets.
Memory exhaustion in pypdf before 6.20.0 occurs when an application decodes a crafted PDF stream that declares an excessive number of filters or chains multiple filters that repeatedly pass large data, driving uncontrolled memory consumption and potential denial of service. The attacker must supply a malicious PDF and get the application to reach the stream-decoding path; authentication against the library is not required (PR:N), while the assessed vector reflects user interaction and attack requirements. The vendor fixed the issue in pypdf 6.20.0; no public exploit identified at time of analysis and no confirmed active exploitation were provided.
An infinite loop in pypdf's standard cross-reference table parser allows a crafted, truncated PDF to hang any Python application that parses untrusted documents with versions prior to 6.20.0. Because the parser does not validate that xref entry lines are the expected 20 bytes before consuming them, a file that ends mid-table drives the reader into a non-terminating loop, exhausting CPU and blocking the processing thread. Only availability is affected - no disclosure, modification, or code execution - and the attack requires the victim application to actually ingest the malicious file (CVSS 4.0 6.0; independent assessment agrees with high availability impact). No public exploit code or CISA KEV entry was identified at time of analysis.
Denial of service in pypdf versions prior to 6.20.1 occurs when crafted cyclic PDF outline or /Next tree structures are processed by writer-side object removal, causing an infinite loop that blocks the current process. Applications are affected only if they accept attacker-supplied PDFs and invoke tree/node removal paths such as find_outline_item or _remove_node_from_tree; merely opening or reading a PDF is insufficient. The vendor advisory GHSA-9mx8-4j7g-633p and PR #4188 address the issue by adding cycle detection, and upgrading to 6.20.1 resolves it; no public exploit or CISA KEV confirmation is present in the provided data.
Denial of service via infinite loop in pypdf's writer-side outline lookup: calling PdfWriter.find_outline_item on a crafted PDF whose document outline contains a cyclic hierarchy (looping /First or /Next pointers) causes the function to recurse or iterate indefinitely, hanging the calling Python process. All pypdf releases prior to 6.20.1 are affected; the exposure is limited to applications that both accept untrusted PDFs and specifically invoke this writer method, since documents that are only opened or read do not trigger the flaw. Impact is availability-only (process hang), with no memory corruption, data disclosure, or code execution; no public exploit code has been identified at time of analysis, and the issue does not appear in CISA KEV.
Memory exhaustion in pypdf versions prior to 6.21.0 allows unauthenticated remote attackers to cause denial of service by supplying a crafted PDF whose content stream contains a very large number of small operations. Default parsing in affected versions imposes no cap on array/dictionary element counts or total parsing work, so an application that reads untrusted PDFs can be driven to consume large amounts of memory; user interaction is required in the sense that a crafted PDF must be opened or processed. This is an availability-only issue rated 6.0 (CVSS 4.0, medium), and no public exploit code or confirmed active exploitation was identified in the provided data.
Memory exhaustion denial of service in pypdf versions prior to 6.21.0 allows an attacker-supplied PDF to drive parsing into unbounded memory consumption by embedding arrays or dictionaries with very large element counts. Only applications that actually ingest and parse untrusted PDFs through the library are exposed, since pypdf is a pure-Python component rather than a network service; no credentials are needed to craft or deliver the file (PR:N, UI:R/UI:P). The vendor has released pypdf 6.21.0 with configurable element-count and parsing-budget caps; no public exploit code or confirmed active exploitation was identified at time of analysis, and the CVSS 4.0 base score is 6.0 (medium) with availability-only impact.
Denial of service in pypdf versions before 6.21.0 can be triggered when an application parses an attacker-crafted PDF and retrieves its form fields, causing excessive memory consumption or long runtimes through unbounded AcroForm field-tree traversal. The flaw is availability-only (CWE-400), requires the consuming application to accept untrusted PDFs and actually query form fields, and needs no authentication against the parsing code; no public exploit was identified at the time of analysis. The vendor has released pypdf 6.21.0, which adds limits on form-field entry count and traversal depth.
pypdf versions before 6.21.1 can be induced to hand /DCTDecode-labeled image streams to the wrong Pillow image parser when the optional Pillow dependency is installed, allowing a crafted PDF to trigger unintended decoding of non-JPEG data. The attack requires the victim to load or extract the affected image with pypdf, and the assessed impact is limited to low availability effects with no confidentiality or integrity loss. No public exploit was identified at time of analysis, and the issue is fixed in 6.21.1 by restricting Pillow to the JPEG format.
Exponential traversal denial-of-service in pypdf before 6.16.1 allows an attacker who can supply a crafted PDF to cause severe CPU stalls and memory exhaustion in any application invoking `PageObject._extract_text` or `PageObject.extract_xform_text`. The text extraction routines previously detected only direct cycles via a `known_ids` set, but failed to bound the total number of XForm invocations across a directed acyclic graph where each parent node reuses the same child XObject multiple times, producing O(2^n) traversal paths for n levels. No active exploitation or public exploit code has been identified; the fix is confirmed available in version 6.16.1.
Resource exhaustion in pypdf prior to 6.16.1 allows an attacker who can supply a crafted PDF to cause denial of service by triggering unbounded traversal in `_get_outline` within `pypdf/_doc_common.py`. Any application that processes untrusted PDF files and accesses document outlines is exposed - the traversal lacked global entry-count and nesting-depth limits, enabling crafted PDFs with large numbers of bookmark entries or deeply nested reused paths to consume excessive CPU and memory. No public exploit has been identified at time of analysis, and a patched release (6.16.1) is available.
Infinite loop denial of service in pypdf prior to 6.16.0 allows any attacker who can supply a crafted PDF to a pypdf-based write pipeline to permanently hang the processing worker. The root cause is in TreeObject.insert_child within pypdf/generic/_data_structures.py, which traverses /Next links without cycle detection; a PDF whose tree nodes form a circular reference (A→B→C→A) causes unbounded traversal. No public exploitation has been confirmed and no CISA KEV entry exists, but a functional proof-of-concept is embedded in the upstream fix PR (#3964).
Quadratic time complexity in pypdf's `read_until_whitespace` function allows remote unauthenticated attackers to cause denial of service by supplying a crafted PDF containing a long non-whitespace byte stream. All versions prior to 6.15.0 accumulate bytes via immutable concatenation in a single-byte loop, producing O(N²) processing cost that stalls Python worker processes and degrades availability of any PDF-parsing pipeline exposed to untrusted input. A confirmed patch is available as version 6.15.0; no active exploitation has been identified at the time of analysis.
Uncontrolled resource consumption in pypdf prior to 6.14.0 allows unauthenticated remote attackers to cause denial of service by submitting a crafted PDF containing repeated malformed cross-reference streams. The library's XRef table recovery routine performs unbounded work on such inputs, leading to excessive CPU time consumption and effectively hanging or severely degrading any application that processes attacker-supplied PDFs. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Uncontrolled memory allocation in pypdf prior to 6.14.0 allows remote, unauthenticated attackers to exhaust host memory by submitting a crafted PDF containing image metadata with inflated declared sizes that vastly exceed the actual embedded image data. Any application that uses pypdf to parse untrusted PDFs is exposed; the library allocates memory proportional to the declared (attacker-controlled) size rather than the actual data length. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
Infinite loop denial-of-service in pypdf prior to 6.13.1 allows an attacker to hang any process that merges a crafted PDF containing cyclic article/thread structures. The vulnerability exists in the `_add_articles_thread()` method of `_writer.py`, which traversed PDF article bead linked-list structures without cycle detection, permitting a self-referential `/N` (Next) pointer chain to create an irrecoverable loop. No public exploit code or CISA KEV listing exists at time of analysis, but the upstream PR diff publicly discloses the precise triggering structure, lowering the bar for exploitation against vulnerable merge pipelines.
Memory exhaustion in pypdf prior to 6.12.0 allows an attacker who supplies a crafted PDF to cause large memory consumption in any application that processes it using layout mode text extraction. The vulnerability is triggered by PDFs containing text positioning operators with abnormally large x- or y-coordinate offsets, causing the library to allocate unbounded whitespace and newline characters during rendering. No confirmed active exploitation exists (not in CISA KEV), and SSVC rates this as non-automatable with partial technical impact, placing it in a lower operational priority tier despite the straightforward exploitation mechanic.
Denial-of-service via algorithmic complexity in pypdf before 6.12.0 allows an attacker who can supply a crafted PDF file to cause excessive processing time during cross-reference stream parsing. The vulnerability is triggered by crafting a PDF with /W [0 0 0] field values in a cross-reference stream combined with a large /Size value, which causes the library to perform unbounded iteration over zero-byte entries. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog; however, any application that processes untrusted PDF input using pypdf is exposed.
Memory exhaustion in pypdf's XMP metadata parser allows denial of service via specially crafted PDF files containing oversized or element-dense XMP blocks, affecting all versions prior to 6.12.1. The vulnerability stems from an absence of input limits in the XML-based XMP parsing subsystem (CWE-770), meaning processing a malicious PDF can consume unbounded system memory. No public exploit code has been identified at time of analysis, and no confirmed active exploitation exists; however, the patch diff is publicly visible on GitHub, making trivial exploit construction feasible.
Denial of service via memory exhaustion in pypdf prior to 6.10.2 allows local attackers with user interaction to crash applications processing crafted PDF files containing FlateDecode-compressed images with inflated size values. The vulnerability exhausts available RAM during decompression, affecting any system using vulnerable pypdf versions to parse untrusted PDF documents.
Denial of service via algorithmic complexity in pypdf versions prior to 6.10.2 allows local attackers to cause long runtimes by crafting a PDF with an excessively large trailer /Size value when loaded in incremental mode. The vulnerability requires user interaction to load the malicious PDF and results in availability degradation rather than data compromise. Patch version 6.10.2 is available from the vendor.
Memory exhaustion in pypdf prior to 6.10.2 allows local attackers to craft malicious PDF files that exhaust system RAM when processed. The vulnerability requires user interaction to open a specially crafted PDF containing a /FlateDecode stream with a /Predictor value other than 1 and large predictor parameters. Vendor-released patch available in version 6.10.2.
Denial of service in pypdf prior to version 6.10.1 allows remote attackers to craft malicious PDF files with oversized cross-reference stream `/Size` values or object stream `/N` values, causing excessive processing time and long runtimes. No authentication is required; the vulnerability is triggered by parsing a specially crafted PDF file. Patch version 6.10.1 is available from the vendor.
Parsing a crafted PDF with pypdf prior to 6.21.2 can drive the library into repeated cross-reference recovery cycles, consuming CPU and time in the parsing process until the workload stalls. This is a follow-up to GHSA-55h5-xmcq-c37v: the earlier fix cached recovery state, but the parser still reloaded the entire PDF stream on each recovery attempt, so repeated malformed cross-reference stream entries still produced long runtimes. Anyone whose application, service, or automated pipeline ingests untrusted PDFs with an affected version remains exposed - including environments that already applied the prior advisory's fix - and exposure ends only with 6.21.2, since no public exploit code has been identified at time of analysis and the impact is limited to availability, with no disclosure, modification, or code execution path.
Denial of service in pypdf before 6.21.2: a crafted PDF whose standard cross-reference table declares a larger entry count than the file can physically contain drives the parser into excessive iteration and long runtimes simply when the document is opened. The CVSS vector shows no privileges required (PR:N) but a victim interaction of opening or processing the file (UI:P), so the realistic exposure is services that ingest untrusted PDFs such as upload portals, mail/attachment scanners and OCR or document pipelines. Impact is availability-only (no confidentiality or integrity effect), the vendor fix is version 6.21.2, and no public exploit code was identified at the time of analysis.
Denial of service in pypdf before 6.21.2 lets a crafted PDF stall parsing by referencing the same non-existent indirect object many times, forcing repeated full-file recovery loads and long runtimes. The flaw is remotely reachable without authentication (CVSS:4.0 AV:N/PR:N, assessed CVSS:3.1 AV:N/AC:L/PR:N), but it only fires when a vulnerable pypdf instance actually loads the attacker-supplied file, so exploitation requires a user or automated pipeline to open or process the malicious PDF (UI:P). Impact is limited to availability - CPU and time exhaustion in the parsing process - with no confidentiality or integrity effect; this is a moderate-severity, this-week-priority issue, and no public exploit code was identified at time of analysis.
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.
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.
Denial of service in pypdf versions prior to 6.19.0 allows remote, unauthenticated attackers to exhaust application CPU by supplying a crafted PDF whose AcroForm choice field carries a large number of options and selected values; when a consuming application calls update_page_form_field_values with flatten=True, the appearance-stream generator recomputes the same invariant selection-glyph set once per line, driving runtimes up until the host process or worker becomes unavailable. The flaw is rated CVSS 4.0 8.7 (and 3.1 8.1 by independent assessment) with availability-only impact - no confidentiality or integrity loss, and no code execution. Exploitation requires the application to explicitly perform form-field updates with flattening on attacker-controlled input; merely opening, parsing, or reading the PDF does not reach the vulnerable code path. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV); the fix ships in upstream release 6.19.0.
Denial of service in pypdf before 6.18.1 lets a crafted PDF drive the library's FlateDecode recovery path into inefficient byte-by-byte decompression, consuming CPU until the consuming application becomes unavailable. Exploitation is unauthenticated and requires only that a pypdf-based service parse or extract text from an attacker-supplied PDF (CVSS v4.0 8.7, AV:N/AC:L/PR:N/UI:N, availability-only); no public exploit identified at time of analysis. The flaw is a residual case left after the earlier malformed-FlateDecode recovery fix and is resolved in 6.18.1.
Memory exhaustion in pypdf versions prior to 6.18.1 lets a crafted PDF force the library to allocate and process far more font-width data than a simple font can legitimately hold, degrading or crashing any process that extracts text or font metrics from untrusted documents. The parser fails to cap the /Widths array of a simple TrueType or Type1 font at the 256 one-byte character codes that such fonts can actually address, so an oversized array is walked entry by entry while widths are collected. The CVSS 4.0 vector (8.7, AV:N/AC:L/PR:N/UI:N, high availability-only impact) reflects unauthenticated remote triggering with no user interaction beyond supplying the file, and the availability-only profile confirms no confidentiality or integrity loss. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (not in CISA KEV), though the trigger is trivially reproducible by anyone who can hand a PDF to a pypdf-consuming service; a vendor patch in 6.18.1 is available.
Memory exhaustion in pypdf versions prior to 6.18.1 allows unauthenticated remote attackers to crash or degrade any application that parses attacker-supplied PDFs, by embedding oversized source-code or destination-string tokens inside a font /ToUnicode CMap. Processing such a file (for example during text extraction, which routes through pypdf/_cmap.py parse_bfchar) makes the library decode and retain these oversized values, driving availability-impacting memory consumption with no confidentiality or integrity effect. The vendor CVSS 4.0 vector (8.7, VA:H only, PR:N/UI:N) matches the assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H; no public exploit code or KEV-listed active exploitation was identified at time of analysis, and a vendor-released patch (6.18.1) is available.
Denial of service in pypdf versions prior to 6.18.0 allows remote, unauthenticated attackers to stall PDF parsing by supplying a crafted file whose indirect-object identifier or generation-number token continues for an excessive length without a whitespace delimiter. The parser's read_until_whitespace helper in pypdf/_utils.py scans unbounded input, so the consuming process hangs or runs for an extremely long time, making any service that parses untrusted PDFs unavailable (CVSS 4.0 8.7, availability-only; assessed CVSS 3.1 8.0 AV:N/AC:L/PR:N/UI:N/A:H). Impact is confined to availability - there is no path to code execution or data disclosure - and no public exploit code or confirmed active exploitation was identified at time of analysis. A vendor-released fix is available in pypdf 6.18.0.
Memory-exhaustion denial of service in pypdf versions prior to 6.17.0 allows remote attackers to inflate application memory usage by supplying a crafted PDF whose /PageLabels /Nums dictionary declares a Roman-numeral numbering style (/S /R) with an extremely large start value (/St), causing the library to construct a numeral string proportional to that value. The CVSS:4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, VA:H) indicates an unauthenticated, network-reachable, low-complexity attack with high availability impact and no confidentiality or integrity effect, but the practical precondition is that the consuming application must actually invoke pypdf's page-label retrieval on attacker-supplied documents - applications that never read page labels are unaffected. No public exploit code has been identified at time of analysis and there is no CISA KEV entry; the vendor released a fix in 6.17.0 that rejects Roman start values above 3,999.
Denial of service in the pypdf Python PDF library (all versions prior to 6.14.1) allows a remote attacker to hang a consuming application by supplying a malicious PDF. A page content stream containing an unterminated inline image drives the inline-image end-marker detection logic into an infinite loop, most notably triggered during page text extraction. No public exploit has been identified at time of analysis, but the CVSS 4.0 score of 8.7 reflects an unauthenticated, low-complexity availability attack, and a fixed release (6.14.1) is available.
Denial of service in pypdf before 6.14.2 lets a remote attacker hang any application that parses an attacker-supplied PDF: a page content stream carrying an unterminated inline image with an ASCII85 or ASCIIHex filter drives the parser into an infinite loop (CWE-835), most notably during page text extraction. The pure-Python library is very widely used in document-processing and data-ingestion pipelines, so a single malicious file can pin a CPU core and stall the worker. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the root cause is well-described and trivially reproducible.
CPU and memory exhaustion in fpdf2 2.5.0 through 2.8.7 lets remote attackers who can submit SVG data to FPDF.image() stall or crash PDF generation workers with a sub-1 KB payload. Nested SVG <use> references are expanded by deep-copying the entire referenced graphics tree at every level, so a handful of groups that each re-reference the previous group produces exponential object growth; the advisory's reproduction (an 895-byte SVG) pinned a process for roughly 14 seconds under a 128 MB address-space limit before raising MemoryError. No public exploit tooling or active exploitation has been reported and the priority label is this_month, but a public proof-of-concept reproduction is included in the advisory; ResourceAccessPolicy does not mitigate it because all references are inline, and the issue is fixed in 2.8.8.
fpdf2 through 2.8.7 dereferences image resource references supplied to FPDF.image(), write_html() HTML <img src> values, SVG <image href>/xlink:href values and template image fields, so attacker-controlled content rendered by an integrating application can trigger outbound HTTP(S) requests to attacker-chosen internal or external destinations (CWE-918 SSRF) as well as attempts to open raw local filesystem paths. The impact is bounded: local content is only embedded when the referenced path resolves to a valid supported image or SVG resource, and file:// URLs are not specially handled, so the local-path case requires a raw path such as '../../file.png'. The vendor scores this 5.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:N/A:N), exploitation depends entirely on the application passing untrusted values into those APIs without an allowlist or restrictive policy, and no public exploit code has been identified at time of analysis; version 2.8.8 introduces a configurable resource_access_policy whose default blocks private, loopback and link-local network targets.
Memory exhaustion in pypdf before 6.20.0 occurs when an application decodes a crafted PDF stream that declares an excessive number of filters or chains multiple filters that repeatedly pass large data, driving uncontrolled memory consumption and potential denial of service. The attacker must supply a malicious PDF and get the application to reach the stream-decoding path; authentication against the library is not required (PR:N), while the assessed vector reflects user interaction and attack requirements. The vendor fixed the issue in pypdf 6.20.0; no public exploit identified at time of analysis and no confirmed active exploitation were provided.
An infinite loop in pypdf's standard cross-reference table parser allows a crafted, truncated PDF to hang any Python application that parses untrusted documents with versions prior to 6.20.0. Because the parser does not validate that xref entry lines are the expected 20 bytes before consuming them, a file that ends mid-table drives the reader into a non-terminating loop, exhausting CPU and blocking the processing thread. Only availability is affected - no disclosure, modification, or code execution - and the attack requires the victim application to actually ingest the malicious file (CVSS 4.0 6.0; independent assessment agrees with high availability impact). No public exploit code or CISA KEV entry was identified at time of analysis.
Denial of service in pypdf versions prior to 6.20.1 occurs when crafted cyclic PDF outline or /Next tree structures are processed by writer-side object removal, causing an infinite loop that blocks the current process. Applications are affected only if they accept attacker-supplied PDFs and invoke tree/node removal paths such as find_outline_item or _remove_node_from_tree; merely opening or reading a PDF is insufficient. The vendor advisory GHSA-9mx8-4j7g-633p and PR #4188 address the issue by adding cycle detection, and upgrading to 6.20.1 resolves it; no public exploit or CISA KEV confirmation is present in the provided data.
Denial of service via infinite loop in pypdf's writer-side outline lookup: calling PdfWriter.find_outline_item on a crafted PDF whose document outline contains a cyclic hierarchy (looping /First or /Next pointers) causes the function to recurse or iterate indefinitely, hanging the calling Python process. All pypdf releases prior to 6.20.1 are affected; the exposure is limited to applications that both accept untrusted PDFs and specifically invoke this writer method, since documents that are only opened or read do not trigger the flaw. Impact is availability-only (process hang), with no memory corruption, data disclosure, or code execution; no public exploit code has been identified at time of analysis, and the issue does not appear in CISA KEV.
Memory exhaustion in pypdf versions prior to 6.21.0 allows unauthenticated remote attackers to cause denial of service by supplying a crafted PDF whose content stream contains a very large number of small operations. Default parsing in affected versions imposes no cap on array/dictionary element counts or total parsing work, so an application that reads untrusted PDFs can be driven to consume large amounts of memory; user interaction is required in the sense that a crafted PDF must be opened or processed. This is an availability-only issue rated 6.0 (CVSS 4.0, medium), and no public exploit code or confirmed active exploitation was identified in the provided data.
Memory exhaustion denial of service in pypdf versions prior to 6.21.0 allows an attacker-supplied PDF to drive parsing into unbounded memory consumption by embedding arrays or dictionaries with very large element counts. Only applications that actually ingest and parse untrusted PDFs through the library are exposed, since pypdf is a pure-Python component rather than a network service; no credentials are needed to craft or deliver the file (PR:N, UI:R/UI:P). The vendor has released pypdf 6.21.0 with configurable element-count and parsing-budget caps; no public exploit code or confirmed active exploitation was identified at time of analysis, and the CVSS 4.0 base score is 6.0 (medium) with availability-only impact.
Denial of service in pypdf versions before 6.21.0 can be triggered when an application parses an attacker-crafted PDF and retrieves its form fields, causing excessive memory consumption or long runtimes through unbounded AcroForm field-tree traversal. The flaw is availability-only (CWE-400), requires the consuming application to accept untrusted PDFs and actually query form fields, and needs no authentication against the parsing code; no public exploit was identified at the time of analysis. The vendor has released pypdf 6.21.0, which adds limits on form-field entry count and traversal depth.
pypdf versions before 6.21.1 can be induced to hand /DCTDecode-labeled image streams to the wrong Pillow image parser when the optional Pillow dependency is installed, allowing a crafted PDF to trigger unintended decoding of non-JPEG data. The attack requires the victim to load or extract the affected image with pypdf, and the assessed impact is limited to low availability effects with no confidentiality or integrity loss. No public exploit was identified at time of analysis, and the issue is fixed in 6.21.1 by restricting Pillow to the JPEG format.
Exponential traversal denial-of-service in pypdf before 6.16.1 allows an attacker who can supply a crafted PDF to cause severe CPU stalls and memory exhaustion in any application invoking `PageObject._extract_text` or `PageObject.extract_xform_text`. The text extraction routines previously detected only direct cycles via a `known_ids` set, but failed to bound the total number of XForm invocations across a directed acyclic graph where each parent node reuses the same child XObject multiple times, producing O(2^n) traversal paths for n levels. No active exploitation or public exploit code has been identified; the fix is confirmed available in version 6.16.1.
Resource exhaustion in pypdf prior to 6.16.1 allows an attacker who can supply a crafted PDF to cause denial of service by triggering unbounded traversal in `_get_outline` within `pypdf/_doc_common.py`. Any application that processes untrusted PDF files and accesses document outlines is exposed - the traversal lacked global entry-count and nesting-depth limits, enabling crafted PDFs with large numbers of bookmark entries or deeply nested reused paths to consume excessive CPU and memory. No public exploit has been identified at time of analysis, and a patched release (6.16.1) is available.
Infinite loop denial of service in pypdf prior to 6.16.0 allows any attacker who can supply a crafted PDF to a pypdf-based write pipeline to permanently hang the processing worker. The root cause is in TreeObject.insert_child within pypdf/generic/_data_structures.py, which traverses /Next links without cycle detection; a PDF whose tree nodes form a circular reference (A→B→C→A) causes unbounded traversal. No public exploitation has been confirmed and no CISA KEV entry exists, but a functional proof-of-concept is embedded in the upstream fix PR (#3964).
Quadratic time complexity in pypdf's `read_until_whitespace` function allows remote unauthenticated attackers to cause denial of service by supplying a crafted PDF containing a long non-whitespace byte stream. All versions prior to 6.15.0 accumulate bytes via immutable concatenation in a single-byte loop, producing O(N²) processing cost that stalls Python worker processes and degrades availability of any PDF-parsing pipeline exposed to untrusted input. A confirmed patch is available as version 6.15.0; no active exploitation has been identified at the time of analysis.
Uncontrolled resource consumption in pypdf prior to 6.14.0 allows unauthenticated remote attackers to cause denial of service by submitting a crafted PDF containing repeated malformed cross-reference streams. The library's XRef table recovery routine performs unbounded work on such inputs, leading to excessive CPU time consumption and effectively hanging or severely degrading any application that processes attacker-supplied PDFs. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog.
Uncontrolled memory allocation in pypdf prior to 6.14.0 allows remote, unauthenticated attackers to exhaust host memory by submitting a crafted PDF containing image metadata with inflated declared sizes that vastly exceed the actual embedded image data. Any application that uses pypdf to parse untrusted PDFs is exposed; the library allocates memory proportional to the declared (attacker-controlled) size rather than the actual data length. No public exploit code has been identified and this vulnerability is not listed in the CISA KEV catalog at time of analysis.
Infinite loop denial-of-service in pypdf prior to 6.13.1 allows an attacker to hang any process that merges a crafted PDF containing cyclic article/thread structures. The vulnerability exists in the `_add_articles_thread()` method of `_writer.py`, which traversed PDF article bead linked-list structures without cycle detection, permitting a self-referential `/N` (Next) pointer chain to create an irrecoverable loop. No public exploit code or CISA KEV listing exists at time of analysis, but the upstream PR diff publicly discloses the precise triggering structure, lowering the bar for exploitation against vulnerable merge pipelines.
Memory exhaustion in pypdf prior to 6.12.0 allows an attacker who supplies a crafted PDF to cause large memory consumption in any application that processes it using layout mode text extraction. The vulnerability is triggered by PDFs containing text positioning operators with abnormally large x- or y-coordinate offsets, causing the library to allocate unbounded whitespace and newline characters during rendering. No confirmed active exploitation exists (not in CISA KEV), and SSVC rates this as non-automatable with partial technical impact, placing it in a lower operational priority tier despite the straightforward exploitation mechanic.
Denial-of-service via algorithmic complexity in pypdf before 6.12.0 allows an attacker who can supply a crafted PDF file to cause excessive processing time during cross-reference stream parsing. The vulnerability is triggered by crafting a PDF with /W [0 0 0] field values in a cross-reference stream combined with a large /Size value, which causes the library to perform unbounded iteration over zero-byte entries. No public exploit code has been identified at time of analysis, and this vulnerability is not listed in the CISA KEV catalog; however, any application that processes untrusted PDF input using pypdf is exposed.
Memory exhaustion in pypdf's XMP metadata parser allows denial of service via specially crafted PDF files containing oversized or element-dense XMP blocks, affecting all versions prior to 6.12.1. The vulnerability stems from an absence of input limits in the XML-based XMP parsing subsystem (CWE-770), meaning processing a malicious PDF can consume unbounded system memory. No public exploit code has been identified at time of analysis, and no confirmed active exploitation exists; however, the patch diff is publicly visible on GitHub, making trivial exploit construction feasible.
Denial of service via memory exhaustion in pypdf prior to 6.10.2 allows local attackers with user interaction to crash applications processing crafted PDF files containing FlateDecode-compressed images with inflated size values. The vulnerability exhausts available RAM during decompression, affecting any system using vulnerable pypdf versions to parse untrusted PDF documents.
Denial of service via algorithmic complexity in pypdf versions prior to 6.10.2 allows local attackers to cause long runtimes by crafting a PDF with an excessively large trailer /Size value when loaded in incremental mode. The vulnerability requires user interaction to load the malicious PDF and results in availability degradation rather than data compromise. Patch version 6.10.2 is available from the vendor.
Memory exhaustion in pypdf prior to 6.10.2 allows local attackers to craft malicious PDF files that exhaust system RAM when processed. The vulnerability requires user interaction to open a specially crafted PDF containing a /FlateDecode stream with a /Predictor value other than 1 and large predictor parameters. Vendor-released patch available in version 6.10.2.
Denial of service in pypdf prior to version 6.10.1 allows remote attackers to craft malicious PDF files with oversized cross-reference stream `/Size` values or object stream `/N` values, causing excessive processing time and long runtimes. No authentication is required; the vulnerability is triggered by parsing a specially crafted PDF file. Patch version 6.10.1 is available from the vendor.