CVE-2026-41312

What it actually does

Versions of the Python pypdf library before 6.10.2 can allocate excessive memory while processing a specially crafted PDF stream compressed with /FlateDecode and using a /Predictor value other than 1 with large predictor parameters. When a vulnerable application parses or extracts content from such a PDF, decompression and predictor handling can exhaust available RAM, causing the process to slow, crash, or be terminated by the operating system. The issue affects availability, not confidentiality or integrity, and requires the application to process attacker-supplied PDF content.

Why it matters to the business

Applications, background workers, document-ingestion pipelines, and automation jobs that use vulnerable pypdf versions can be disrupted by a malicious PDF, leading to failed uploads, stalled queues, service degradation, increased infrastructure costs, or outages in document-processing workflows. The CVSS score is moderate and EPSS is low, and there is no current KEV listing or known ransomware use, but the flaw is still operationally relevant for internet-facing or high-volume PDF ingestion services because exploitation can be as simple as submitting or causing processing of a crafted file.

How an attack unfolds

An attacker creates a malformed or intentionally oversized PDF object stream that uses /FlateDecode compression and declares predictor-related parameters designed to make pypdf allocate far more memory than expected during decoding. The attacker then delivers the PDF to a vulnerable workflow, such as a web upload, email attachment processor, document preview service, batch import job, or automated metadata extraction pipeline. When the application opens the PDF and accesses the affected compressed stream, pypdf attempts to decode it and applies predictor logic, causing memory usage to spike. If resource limits are insufficient, the process may become unresponsive, crash, or be killed, potentially causing repeated job failures or broader service degradation if the same file is retried automatically.

How to fix it

Upgrade pypdf to version 6.10.2 or later wherever it is used. If package constraints prevent immediate upgrade, apply the upstream patch changes manually as a temporary workaround and prioritize a full dependency update afterward. Rebuild and redeploy applications, containers, serverless packages, and batch-processing images that vendor or pin vulnerable pypdf versions. Add defense-in-depth controls for PDF-processing paths, including file-size limits, decompressed-size or page/content limits where feasible, per-process memory limits, worker timeouts, queue retry limits, and isolation of document-parsing workers from critical application services.

How to confirm the fix worked

Confirm that all runtime environments resolve pypdf to 6.10.2 or later using dependency inventory, lockfiles, SBOMs, container scans, and runtime package checks such as `python -c "import pypdf; print(pypdf.__version__)"`. Review requirements files, Poetry/Pipenv/uv lockfiles, vendored dependencies, and container layers for older pypdf versions. Exercise PDF upload and processing workflows after remediation to confirm normal files still process successfully and that malformed or oversized PDFs are rejected, timed out, or contained without exhausting host memory. Validate that worker memory limits and retry policies prevent a single document from causing repeated service degradation.

Typical attack path

1. Identify an application or workflow that accepts or retrieves PDF files and processes them with pypdf before version 6.10.2.
2. Craft a PDF containing a /FlateDecode stream with /Predictor not equal to 1 and large predictor parameters that trigger excessive memory allocation.
3. Submit, upload, email, or otherwise place the crafted PDF where the target application will parse it.
4. Wait for the vulnerable pypdf code path to access and decode the crafted stream.
5. Cause the worker, web process, or processing service to consume excessive RAM, crash, be killed by the operating system, or stall the document-processing queue.
6. Optionally repeat submissions or rely on automatic retries to sustain denial of service.

How to detect it

Look for evidence of denial-of-service activity against PDF-processing components rather than data theft. Useful sources include application logs for PDF upload or parsing failures, worker and queue logs, container orchestrator events, operating-system OOM killer messages, APM memory metrics, crash dumps, and web or mail gateway logs showing recently submitted PDF files. Investigate repeated failures tied to the same PDF, sudden increases in resident memory during PDF parsing, worker restarts, container exits with out-of-memory status, HTTP 5xx responses after PDF uploads, and job retry storms. If suspect PDFs are available, inspect their objects for streams using `/FlateDecode` with `/Predictor` values other than 1 and unusually large predictor-related parameters such as `/Columns`, `/Colors`, or `/BitsPerComponent`. There are no known public exploit campaigns, KEV activity, or named threat actors for this issue, so detection should focus on anomalous resource exhaustion and malicious PDF structure.

• /FlateDecode
• /Predictor
• /Predictor 2
• /Predictor 10
• /Predictor 11
• /Predictor 12
• /Predictor 13
• /Predictor 14
• /Predictor 15
• /Columns
• /Colors
• /BitsPerComponent
• Out of memory
• MemoryError
• Killed process
• oom-kill
• OOMKilled
• exit code 137
• signal 9
• pypdf
• PdfReader

What your security team should do

• Inventory applications, containers, serverless functions, and batch jobs that process PDF files using pypdf.
• Upgrade pypdf to 6.10.2 or later and rebuild all deployable artifacts that include the library.
• Prioritize remediation for internet-facing upload portals, email/document ingestion systems, and high-volume automated PDF processing pipelines.
• Add or verify resource controls for PDF parsing, including memory limits, execution timeouts, maximum upload size, and bounded queue retries.
• Search recent logs and monitoring data for unexplained memory spikes, out-of-memory kills, worker crashes, or repeated failures associated with PDF processing.
• Add dependency scanning rules or SBOM checks to flag pypdf versions earlier than 6.10.2.
• If immediate patching is not possible, isolate vulnerable PDF-processing workers and restrict who or what can submit PDFs until the upgrade is complete.