CVE-2025-66019

What it actually does

The vulnerability is an uncontrolled resource consumption issue in pypdf's handling of PDF page content streams compressed with the LZWDecode filter. When a crafted PDF is parsed, decompression of a malicious stream can cause memory usage of up to approximately 1 GB per stream. Applications that accept or process untrusted PDFs with vulnerable pypdf versions can experience excessive memory allocation, process termination by the operating system, worker crashes, or broader service degradation if multiple documents or streams are processed concurrently. The flaw affects pypdf prior to 6.4.0; Debian 13 packages list a fixed version of 6.11.2-1.

Why it matters to the business

Systems that automatically ingest, scan, convert, index, or extract text from PDFs may be disrupted by a maliciously crafted file, potentially causing document-processing queues to stall, application workers to crash, or services to become temporarily unavailable. The issue is not known to be exploited in the wild, is not in the CISA KEV catalog, and has a low EPSS score, so urgency is lower than actively exploited remote code execution issues; however, any internet-facing or automated PDF-processing workflow should still be patched because exploitation requires only delivery of a crafted PDF to a vulnerable parser.

How an attack unfolds

An attacker creates a PDF containing one or more page content streams that use the LZWDecode filter and are structured to trigger excessive memory consumption during decompression by vulnerable pypdf versions. The attacker then submits, uploads, emails, or otherwise causes the target application to parse the PDF using pypdf. When the application reads or processes the affected page content stream, pypdf attempts to decode it and allocates a large amount of memory. This can exhaust process memory, trigger Python MemoryError exceptions, cause the operating system OOM killer to terminate the process, or degrade the host if many streams or files are processed. The result is denial of service against the component responsible for PDF processing rather than code execution or data disclosure.

How to fix it

Upgrade pypdf to version 6.4.0 or later. For Debian 13 environments using distribution packages, upgrade to the fixed package version 6.11.2-1 or later. Rebuild and redeploy applications, containers, virtual environments, and serverless packages that vendor or pin pypdf. Where immediate patching is not possible, reduce exposure by rejecting or quarantining untrusted PDFs that contain LZWDecode streams, enforcing strict file size and page count limits, processing PDFs in isolated workers with memory limits, applying per-job timeouts, rate limiting PDF submissions, and ensuring failed processing jobs cannot repeatedly crash shared services.

How to confirm the fix worked

Confirm the installed pypdf version is 6.4.0 or later, or that Debian 13 packages are at 6.11.2-1 or later. Check Python dependency manifests, lockfiles, container images, virtual environments, and runtime package inventories for vulnerable pypdf versions. Validate that document-processing services were rebuilt after dependency updates rather than only updating source manifests. Test representative PDF ingestion paths with benign PDFs and, in a controlled non-production environment, verify that PDFs containing LZWDecode streams are either handled safely or rejected according to policy. Confirm memory limits, worker restart behavior, queue retry limits, and monitoring alerts are functioning as intended.

Typical attack path

1. Identify an application, service, API, queue, or workflow that accepts PDF files and processes them with vulnerable pypdf versions.
2. Craft a PDF containing page content streams that use the LZWDecode filter and are designed to expand or consume excessive memory during parsing.
3. Deliver the PDF through an upload form, API endpoint, email attachment, document import process, or other ingestion channel.
4. Wait for the backend worker, scanner, converter, or parser to process the PDF using pypdf.
5. Trigger excessive memory allocation during LZWDecode content stream parsing, causing worker crashes, MemoryError exceptions, OOM kills, or service unavailability.
6. Optionally repeat submissions or use PDFs with multiple affected streams to amplify service disruption.

How to detect it

Review application, worker, queue, web server, and operating system logs for signs that PDF processing caused memory exhaustion or repeated worker crashes. Focus on services that parse uploaded, emailed, imported, or queued PDFs using pypdf. Look for Python MemoryError exceptions, process exits during PDF parsing, OOM killer messages, container memory limit terminations, sudden increases in memory usage, repeated failed jobs involving the same PDF, and files whose raw contents include LZWDecode filters. Web and API logs may show repeated PDF uploads shortly before worker crashes or elevated 5xx responses. Queue systems may show repeated retries, poison-message behavior, or dead-lettered PDF-processing tasks. For forensics, preserve suspicious PDFs and inspect them with safe offline tooling for /Filter /LZWDecode entries, unusually large or numerous streams, and correlation with crash timestamps. No public exploitation, KEV listing, ransomware usage, or named threat actor activity is indicated by the provided data, so detection should focus on anomalous PDF ingestion and resource-exhaustion artifacts rather than actor-specific infrastructure.

• /Filter /LZWDecode
• /LZWDecode
• MemoryError
• Out of memory: Killed process
• oom-killer
• Killed process
• container killed due to memory usage
• OOMKilled
• pypdf
• PdfReader
• LZWDecode
• Failed to decode stream
• Error reading stream

What your security team should do

• Inventory applications and services that process user-supplied or externally sourced PDFs using pypdf.
• Prioritize patching internet-facing, unauthenticated, high-volume, or business-critical PDF ingestion workflows first.
• Upgrade pypdf to 6.4.0 or later; for Debian 13 packages, deploy 6.11.2-1 or later.
• Rebuild containers, virtual environments, and deployment artifacts to remove vulnerable transitive or vendored copies of pypdf.
• Add file-processing guardrails: maximum file size, maximum page count, maximum decoded stream size, per-job memory limits, processing timeouts, and bounded retry behavior.
• Consider temporarily blocking or quarantining PDFs containing LZWDecode streams if operationally feasible until patching is complete.
• Monitor PDF-processing services for MemoryError exceptions, OOM kills, worker restarts, queue backlogs, and repeated submissions of PDFs containing LZWDecode.
• Because this issue is not KEV-listed and has low EPSS, handle through normal vulnerability remediation SLAs unless PDF ingestion is exposed to untrusted users or supports critical business workflows.