CVE-2026-41313

What it actually does

CVE-2026-41313 is a denial-of-service vulnerability in pypdf before version 6.10.2. A specially crafted PDF can set an excessively large trailer /Size value that causes pypdf to spend an abnormally long time processing the file when it is loaded in incremental mode. The flaw does not provide code execution, data disclosure, or data modification, but it can consume CPU time and worker capacity, causing PDF-processing tasks to hang, time out, or fall behind.

Why it matters to the business

Systems that accept or process untrusted PDF files may experience slowdowns, failed document workflows, stuck background jobs, or reduced service availability if crafted PDFs are submitted. The risk is highest for web applications, document ingestion pipelines, email-processing systems, e-discovery platforms, and automation jobs that parse user-supplied PDFs with pypdf. The vulnerability is not currently listed in CISA KEV, has low EPSS, and has no known exploit maturity reported, but the fix should still be prioritized where PDF processing is internet-facing or business-critical.

How an attack unfolds

An attacker creates a malformed PDF whose trailer contains a very large /Size value. The attacker then causes an application or user workflow to load that file using a vulnerable pypdf version before 6.10.2 in incremental mode. During parsing, pypdf performs work proportional to the inflated trailer size, resulting in long runtimes. If the target application processes PDFs synchronously, the request may hang or time out; if it uses background workers, the crafted files may occupy workers and delay legitimate processing. Repeated submissions can amplify the impact into an application-level denial of service.

How to fix it

Upgrade pypdf to version 6.10.2 or later wherever it is used. If an immediate upgrade is not possible, manually apply the upstream patch referenced by the pypdf project and avoid parsing untrusted PDFs in incremental mode where feasible. Add operational safeguards around PDF processing, including maximum file size limits, parsing timeouts, worker execution limits, queue rate limits, and isolation of document-processing workers from core application services. For applications that accept external PDFs, treat PDF parsing as untrusted input handling and ensure failures are contained without blocking unrelated workloads.

How to confirm the fix worked

Confirm that all deployed Python environments, containers, build artifacts, and dependency lockfiles use pypdf 6.10.2 or later. Validate with package inventory commands such as `python -m pip show pypdf`, `pip freeze`, `pipdeptree`, or software composition analysis tooling. Review dependency files such as requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, and container build manifests for vulnerable pypdf versions. Functionally validate the fix by testing a controlled PDF with an abnormally large trailer /Size value in a non-production environment and confirming that parsing no longer results in excessive runtime. Also confirm that PDF-processing jobs enforce timeouts and recover cleanly from malformed inputs.

Typical attack path

1. Identify an application, service, or workflow that accepts PDF uploads or ingests PDFs from email, storage, APIs, or user submissions.
2. Craft a PDF containing a trailer with an excessively large /Size value intended to trigger long processing in vulnerable pypdf versions.
3. Submit, upload, email, or otherwise place the crafted PDF where the target workflow will parse it with pypdf in incremental mode.
4. The vulnerable parser spends excessive time processing the file, tying up the request handler, job worker, or automation process.
5. Repeat the submission or queue multiple crafted files to exhaust available processing capacity and degrade document-related services.

How to detect it

Look for evidence of abnormal PDF-processing runtimes, repeated worker timeouts, or queue backlogs involving files parsed by pypdf. Useful log sources include application upload logs, API gateway or web server logs, background worker logs, job queue telemetry, container logs, Python exception logs, endpoint process telemetry, and resource monitoring for CPU time and worker saturation. Search for repeated processing failures involving PDF files, unusually long request durations on PDF upload or ingestion endpoints, and clusters of timeouts after a PDF was submitted. If file samples are available, inspect suspicious PDFs for trailer dictionaries containing very large `/Size` values. Because exploitation primarily causes resource exhaustion rather than a persistent compromise, detection should focus on timing anomalies, repeated malformed PDF submissions, and recovery artifacts rather than traditional malware indicators.

• /Size
• trailer
• PdfReader
• pypdf
• TimeoutError
• PDF processing timed out
• worker timeout
• job timeout
• request timeout
• maximum execution time exceeded
• long runtime
• malformed PDF
• incremental mode

What your security team should do

• Inventory all applications, containers, serverless functions, batch jobs, and automation workflows that use pypdf to process PDFs.
• Upgrade pypdf to 6.10.2 or later, prioritizing internet-facing upload paths and high-volume document-processing services.
• Add parser-level timeouts, job-level execution limits, queue throttling, and file size limits for all untrusted PDF processing.
• Review PDF upload and ingestion endpoints for abuse controls such as authentication, rate limiting, malware scanning, and quarantine workflows.
• Monitor for repeated PDF-processing timeouts, unusually long parsing durations, worker saturation, and spikes in failed document jobs.
• If suspicious activity is found, preserve submitted PDF samples, application logs, worker logs, queue metadata, and process resource telemetry for forensic review.