CVE-2026-41314

What it actually does

CVE-2026-41314 is a denial-of-service vulnerability in pypdf before version 6.10.2. A malicious PDF can define an image stream using /FlateDecode with unusually large declared size values, causing pypdf to allocate excessive memory while processing or decoding the object. Successful exploitation can exhaust RAM in the process or host running PDF parsing, leading to worker crashes, killed processes, degraded service availability, or broader instability if resource isolation is weak. The issue requires a user or application workflow to open, parse, inspect, merge, extract, or otherwise process the crafted PDF; it does not provide code execution or data disclosure by itself.

Why it matters to the business

Applications that accept or process user-supplied PDFs may become unavailable or unreliable if a crafted file is submitted. This can disrupt document ingestion, billing, reporting, e-signature, compliance, case-management, or content-processing workflows that rely on pypdf. Because pypdf is a common Python PDF library, the risk is most relevant to services that process untrusted PDFs at scale or run PDF parsing jobs without strict memory limits. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or ransomware association, so prioritization should focus on internet-facing upload paths, automated document pipelines, and shared processing infrastructure.

How an attack unfolds

An attacker creates a PDF containing an image object compressed or labeled with /FlateDecode and supplies large width, height, bits-per-component, color-space, or related size metadata that causes pypdf to reserve or expand a very large buffer during processing. The attacker then delivers the file through a path that causes pypdf versions earlier than 6.10.2 to parse the affected image object, such as upload validation, metadata extraction, page rendering preparation, PDF splitting, merging, or text/image extraction. When the vulnerable code attempts to decode or materialize the image data, memory consumption grows rapidly. The Python process may raise MemoryError, become unresponsive, be terminated by an operating system out-of-memory killer, or consume enough host memory to impact neighboring workloads. Exploitation requires interaction with the malicious file but does not require authentication if the processing endpoint accepts arbitrary uploaded PDFs from unauthenticated users.

How to fix it

Upgrade pypdf to version 6.10.2 or later wherever it is used. If dependency manifests pin pypdf to an earlier version, update the pinned version and rebuild affected applications, containers, serverless packages, and batch-processing images. If an immediate upgrade is not possible, manually apply the upstream patch referenced by the project and add compensating controls: reject or quarantine suspicious PDFs before processing, enforce maximum upload size and page/image dimensions, run PDF processing in isolated workers with strict memory and CPU limits, set job timeouts, and use queues with back-pressure to prevent repeated malicious files from exhausting shared resources. Treat all externally supplied PDFs as untrusted input, especially in unauthenticated upload or automated ingestion paths.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, and build artifacts use pypdf 6.10.2 or later by checking package lockfiles, SBOMs, runtime package inventories, and dependency scanners. Example checks include `python -m pip show pypdf`, `pip freeze | grep '^pypdf=='`, and software composition analysis scans of built images. Verify that no transitive or vendored copy of pypdf older than 6.10.2 remains in production artifacts. For exposure validation, identify workflows that accept PDFs from users, partners, email, APIs, or batch imports and confirm they invoke pypdf. Test fixes in a controlled non-production environment with resource limits in place by processing a benign regression sample that exercises FlateDecode image handling and confirming that memory use remains bounded and the process does not crash. Validate operational mitigations by confirming upload limits, worker memory limits, queue retry limits, and timeout controls are enforced.

Typical attack path

1. Identify an application or backend workflow that processes uploaded or externally supplied PDF files using pypdf before 6.10.2.
2. Craft a PDF containing an image stream that uses /FlateDecode and declares very large image size parameters.
3. Submit or deliver the crafted PDF through an upload, import, email-ingestion, batch-processing, or document-conversion workflow.
4. Trigger pypdf to parse or decode the affected image object during validation, extraction, merging, splitting, or other PDF handling.
5. Cause excessive memory allocation, leading to process crash, out-of-memory termination, worker exhaustion, job failure, or service degradation.
6. Repeat submissions or automate delivery to sustain denial of service if rate limits and resource controls are absent.

How to detect it

To determine whether this was already exploited, review application, worker, container, and operating system logs for memory exhaustion or process crashes that occur immediately after PDF upload, import, email ingestion, or document-processing jobs. Correlate timestamps of failed PDF-processing jobs with HTTP access logs, API gateway logs, object-storage write events, queue messages, and file-ingestion records. Look for Python MemoryError exceptions or worker terminations in stack traces involving pypdf, PDF image decoding, filters, or FlateDecode processing. On Linux hosts, inspect kernel and system logs for OOM-killer events involving Python, web workers, Celery/RQ workers, serverless runtimes, or document-processing services. In containerized environments, review orchestrator events for OOMKilled, CrashLoopBackOff, abnormal restarts, and memory-limit terminations. Retain and inspect PDFs processed shortly before crashes; suspicious samples may contain /FlateDecode image streams with abnormally large /Width, /Height, /BitsPerComponent, /ColorSpace, or inflated decoded-size characteristics. No public threat actors or campaigns are currently associated with this vulnerability, so detection should be behavior-focused rather than actor-focused.

• /FlateDecode
• /Width
• /Height
• /BitsPerComponent
• /ColorSpace
• MemoryError
• pypdf
• Out of memory
• Killed process
• oom-kill
• OOMKilled
• CrashLoopBackOff
• exit code 137
• container killed due to memory usage

What your security team should do

• Prioritize upgrading all uses of pypdf to 6.10.2 or later in services that process untrusted PDFs, especially public upload endpoints and automated ingestion pipelines.
• Inventory applications, containers, serverless functions, and scheduled jobs that include pypdf, including transitive and vendored dependencies.
• Apply memory, CPU, timeout, and retry limits to PDF-processing workers so a single file cannot destabilize a host or shared workload pool.
• Add file intake controls for PDFs, including maximum file size, maximum page count where feasible, and quarantine/rejection of documents with abnormal image dimensions or suspicious compressed streams.
• Monitor for repeated PDF-processing crashes, MemoryError events, out-of-memory kills, and spikes in memory usage following PDF uploads or imports.
• Preserve suspicious PDF samples, upload metadata, request source information, and worker logs for forensic review if exploitation is suspected.
• Because the vulnerability is not currently listed in KEV, has no known ransomware association, and has low EPSS, handle as a resilience and availability risk, but accelerate remediation for internet-facing or high-volume document workflows.