CVE-2026-33123

What it actually does

Versions of pypdf before 6.9.1 can consume excessive CPU time and memory when parsing a crafted PDF that contains an array-based stream with a very large number of entries. The flaw is a denial-of-service condition: it does not provide code execution or data disclosure, but it can stall or crash the process that parses the malicious document, especially in services that automatically ingest, inspect, merge, split, extract text from, or otherwise process untrusted PDFs.

Why it matters to the business

Applications and batch jobs that rely on pypdf to process user-supplied or externally sourced PDFs may become slow, unstable, or unavailable after receiving a malicious file. This can disrupt document workflows, upload portals, invoice processing, e-discovery, archiving, customer support, or any automation pipeline that depends on PDF parsing. The EPSS score is currently low and the issue is not listed in CISA KEV, but the vulnerability is easy to trigger where untrusted PDFs are processed and may still be useful for service disruption or resource-exhaustion attacks.

How an attack unfolds

An attacker creates a PDF with an intentionally large or pathological array-based stream structure. The attacker then gets a vulnerable application to process the file, for example by uploading it, emailing it into an automated workflow, placing it in a watched directory, or otherwise causing a pypdf-based parser to open and access the affected stream. When the vulnerable code traverses or materializes the many stream entries, processing time and memory usage grow excessively. The affected worker, job, or service may become unresponsive, hit memory limits, be killed by the operating system or container runtime, or exhaust shared resources, causing denial of service for legitimate document processing.

How to fix it

Upgrade pypdf to version 6.9.1 or later wherever it is used, including direct application dependencies, transitive dependencies, container images, virtual environments, serverless packages, and build artifacts. If immediate upgrade is not possible, reduce exposure by rejecting or quarantining untrusted PDFs, enforcing strict file size and page/object limits, processing PDFs in isolated workers with CPU and memory limits, applying timeouts to parsing jobs, rate-limiting uploads and API submissions, and ensuring failed parsing jobs cannot repeatedly retry the same malicious file without quarantine.

How to confirm the fix worked

Confirm that all deployed environments resolve pypdf to version 6.9.1 or later using package inventory, lockfiles, SBOMs, container image scans, and runtime checks such as `python -m pip show pypdf` or equivalent dependency inspection. Validate that applications processing untrusted PDFs have resource controls in place, including worker memory limits, CPU quotas, parsing timeouts, upload size limits, retry limits, and quarantine handling. Where safe, test with controlled oversized or malformed PDF samples in a non-production environment to verify that parsing is bounded, fails safely, and does not destabilize the service.

Typical attack path

1. Identify an application, service, or automated job that processes PDFs using pypdf before version 6.9.1.
2. Craft or obtain a malicious PDF containing an array-based stream with many entries designed to trigger excessive runtime or memory use.
3. Deliver the PDF through an accepted input path such as upload, email ingestion, API submission, file share, or batch-processing queue.
4. Wait for the vulnerable pypdf code path to access the crafted array-based stream during parsing or document manipulation.
5. Cause the parser process to consume excessive CPU or memory, leading to slow processing, worker crashes, job failures, queue backlog, or service unavailability.

How to detect it

To determine whether exploitation may have already occurred, review logs and telemetry from services that accept or process PDFs. Focus on the period around unexplained CPU spikes, memory exhaustion, worker restarts, job timeouts, upload bursts, or document-processing queue backlogs. Useful sources include application logs, web/API upload logs, worker and batch-processing logs, container or orchestration events, operating system OOM-killer messages, APM traces, process resource metrics, object storage access logs, email-ingestion logs, and file quarantine records. Look for repeated processing failures tied to the same PDF file, source IP, user agent, sender, API client, or queue message; unusually large or malformed PDF uploads; jobs that spend excessive time inside PDF parsing or pypdf-related call stacks; and processes killed due to memory pressure shortly after opening a PDF. There are no public, CVE-specific malware artifacts or unique network indicators for this issue, so detection should be behavior-based and correlated with PDF ingestion activity.

What your security team should do

• Prioritize upgrading all pypdf installations to 6.9.1 or later, especially internet-facing upload services and automated PDF ingestion pipelines.
• Inventory applications, containers, serverless functions, and batch jobs that parse PDFs and verify whether pypdf is present directly or transitively.
• Apply defense-in-depth controls for document parsing: sandboxing, memory limits, CPU limits, parsing timeouts, file size limits, and queue retry limits.
• Add monitoring for abnormal CPU, memory, job duration, worker restarts, and queue backlog associated with PDF processing workloads.
• Quarantine PDFs that repeatedly fail parsing or cause worker termination, and prevent automatic reprocessing loops.
• Review recent PDF-processing incidents since publication for signs of resource exhaustion, repeated malformed uploads, or unexplained worker crashes.
• Because the issue is not currently in KEV and has low EPSS, treat it as medium urgency overall but high urgency for systems that process untrusted PDFs at scale.