CVE-2025-62708

What it actually does

This vulnerability is a denial-of-service flaw in pypdf's handling of PDF page content streams that use the LZWDecode filter. A specially crafted PDF can cause excessive memory allocation during parsing or decompression of an LZW-encoded stream. The expected impact is resource exhaustion of the process performing PDF parsing, which may lead to Python MemoryError exceptions, worker crashes, container restarts, or host-level out-of-memory events. There is no indication from the provided intelligence that this enables code execution or data disclosure.

Why it matters to the business

Applications that accept, inspect, index, transform, preview, or extract content from PDFs using affected pypdf code can be disrupted by a malicious or malformed PDF. The most likely business impact is degraded availability of document-processing workflows, failed uploads, stuck queues, service restarts, increased infrastructure costs from memory pressure, and potential interruption of customer-facing features that depend on PDF handling. The EPSS score is low and it is not listed in CISA KEV, so broad active exploitation is not currently indicated, but the issue has been public for 291 days and should be addressed during normal dependency maintenance, especially for internet-facing upload or document-ingestion services.

How an attack unfolds

An attacker identifies an application path that parses PDFs with pypdf, such as file upload, document preview, indexing, metadata extraction, page rendering preparation, or automated attachment processing. The attacker submits a crafted PDF containing a page content stream that uses the LZWDecode filter and is structured to cause very large memory consumption when pypdf parses or decompresses that stream. When the vulnerable parser processes the file, memory usage spikes. Depending on resource limits and service architecture, the parsing worker may throw a MemoryError, be killed by the operating system or container runtime, restart repeatedly, or consume enough resources to slow or interrupt adjacent workloads. Repeated submissions can amplify the availability impact against queues, batch processors, or web endpoints that automatically retry failed document-processing jobs.

How to fix it

Upgrade pypdf to a version that includes the upstream fix. For source-based deployments tracking the Git repository, ensure the deployed code includes commit 4a613f3fbe7af8ef65bbae740ceabe35310db4ee or a later commit containing the same fix. Rebuild and redeploy all applications, containers, serverless packages, batch workers, and background processors that vendor or bundle pypdf. If immediate upgrade is not possible, reduce exposure by enforcing strict file size limits, page count limits, decompressed stream limits where available, processing timeouts, memory limits per worker, queue rate limits, and isolation of PDF parsing in constrained worker processes or containers. Consider rejecting or quarantining PDFs that contain LZWDecode streams until patched if business workflows allow it.

How to confirm the fix worked

Confirm dependency resolution shows a patched pypdf version or source revision at or after commit 4a613f3fbe7af8ef65bbae740ceabe35310db4ee in every deployable artifact. Validate both direct and transitive dependency usage, including vendored libraries and container images. Exercise representative PDF processing workflows with benign PDFs and malformed test cases in a non-production environment while monitoring memory consumption, worker restarts, and error logs. Confirm that file upload, queue processing, preview generation, indexing, and attachment-processing paths all use the updated artifact. For mitigations, verify that file size limits, processing timeouts, worker memory caps, retry limits, and alerting trigger as expected when PDF parsing consumes abnormal resources.

Typical attack path

1. Find an application feature or automated workflow that accepts or processes PDF files.
2. Confirm that submitted PDFs are parsed server-side rather than merely stored.
3. Create or obtain a malformed PDF with a page content stream using the LZWDecode filter that triggers excessive memory usage in affected pypdf versions.
4. Submit the PDF through an upload form, API endpoint, email ingestion flow, document queue, or other parsing path.
5. Wait for the vulnerable pypdf parser to process the page content stream.
6. Cause the parsing process to consume excessive memory, resulting in errors, worker termination, container restart, or service degradation.
7. Repeat submissions or target retry queues to prolong denial of service.

How to detect it

To assess whether this was already exploited, review application, worker, container, and host logs for abnormal memory exhaustion events correlated with PDF parsing activity. Focus on upload endpoints, document preview services, metadata extraction jobs, search indexing workers, attachment ingestion, and queue consumers that invoke pypdf. Look for spikes in Python MemoryError exceptions, worker restarts, container OOMKilled events, Linux oom-killer messages, failed PDF processing jobs, repeated retries of the same PDF, and submissions from the same source shortly before memory exhaustion. Inspect suspicious PDF samples, if available, for page content streams using the LZWDecode filter. Useful log sources include web access logs, application error logs, task queue logs, container orchestration events, host syslog or kernel logs, EDR process telemetry, object-storage access logs for uploaded PDFs, and API gateway logs. Since this is primarily a denial-of-service condition, durable indicators may be limited to resource-exhaustion artifacts and the offending PDF files rather than persistent malware or post-exploitation traces.

• /LZWDecode
• LZWDecode
• MemoryError
• pypdf
• PdfReader
• PdfReadError
• Out of memory: Killed process
• oom-killer
• OOMKilled
• Killed process
• container killed due to memory usage
• exceeded memory limit
• worker restart
• PDF processing failed

What your security team should do

• Inventory all applications, services, batch jobs, and third-party components that use pypdf to parse untrusted PDFs.
• Prioritize patching internet-facing upload paths, email or attachment ingestion systems, document preview services, and high-volume asynchronous PDF processing queues.
• Upgrade affected pypdf deployments to code including commit 4a613f3fbe7af8ef65bbae740ceabe35310db4ee or later.
• Redeploy all containers, serverless packages, and worker images that include the vulnerable dependency; do not rely only on updating a lockfile.
• Add resource controls around PDF parsing, including memory limits, CPU/time limits, file size limits, retry limits, and queue back-pressure.
• Add monitoring for sudden increases in PDF parsing failures, Python MemoryError exceptions, worker OOM kills, container restarts, and repeated uploads of PDFs containing LZWDecode streams.
• Review recent logs for signs of attempted denial-of-service through malformed PDFs, especially if public upload or document ingestion endpoints exist.
• If patching must be delayed, quarantine or reject PDFs using LZWDecode in untrusted workflows where feasible.