CVE-2026-33699

What it actually does

Versions of the Python pypdf library before 6.9.2 can enter an infinite loop while parsing a specially crafted PDF when the application reads the file in non-strict mode. The flaw affects availability rather than confidentiality or integrity: a malicious PDF can cause the worker process, request handler, batch job, or document-processing service using pypdf to consume CPU indefinitely or hang until killed or timed out.

Why it matters to the business

Applications that accept or process untrusted PDFs may experience degraded performance, stuck document-processing queues, failed uploads, unavailable PDF-related features, increased compute costs, or denial of service if attackers or abusive users submit crafted files. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is 0.00455, there is no known CISA KEV listing, no ransomware association, and no reported exploit maturity in the supplied data.

How an attack unfolds

An attacker identifies an application, API, workflow, or background service that uses vulnerable pypdf versions to parse uploaded, emailed, downloaded, or otherwise user-supplied PDF files. The attacker crafts a malformed PDF that triggers the vulnerable parsing path and submits it to the target. If the application processes the document with pypdf in non-strict mode, the parser can enter an infinite loop. This ties up the processing thread or worker, potentially causing request timeouts, exhausted worker pools, stalled queues, high CPU utilization, or service unavailability. Repeated submissions can amplify the operational impact, especially in systems that automatically retry failed document-processing jobs without strong timeouts or input isolation.

How to fix it

Upgrade pypdf to version 6.9.2 or later wherever it is used. If immediate upgrade is not possible, manually apply the upstream patch changes referenced by the project, avoid non-strict parsing for untrusted PDFs where feasible, and place strict execution timeouts around PDF parsing operations. Run PDF processing in isolated worker processes or containers with CPU and memory limits, disable unbounded automatic retries for failed documents, enforce upload size and complexity limits, and quarantine or reject malformed PDFs that repeatedly time out.

How to confirm the fix worked

Inventory Python dependencies across applications, containers, build artifacts, and dependency lockfiles and confirm that pypdf is version 6.9.2 or later. Check common dependency files such as requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, conda environment files, SBOMs, and container images. In runtime environments, validate with commands such as `python -m pip show pypdf` or package manager equivalent. Confirm application code does not process untrusted PDFs in non-strict mode without timeouts. Where safe, use a controlled regression test based on the patched issue to verify malformed PDFs no longer cause long-running or hung parsing jobs.

Typical attack path

1. Find an internet-facing or automated workflow that accepts or ingests PDF files.
2. Determine, directly or indirectly, that the workflow parses PDFs using pypdf before version 6.9.2.
3. Create a specially malformed PDF designed to trigger the infinite-loop parsing condition.
4. Submit the crafted PDF through an upload form, API endpoint, email ingestion path, file share, or other document intake mechanism.
5. Wait for the backend process to parse the file in non-strict mode.
6. Cause the parsing worker to hang or consume CPU until killed, timed out, or restarted.
7. Repeat submissions to exhaust available workers, delay document-processing queues, or degrade the application’s availability.

How to detect it

Look for evidence of availability abuse against PDF-processing components. Relevant telemetry includes web/API upload logs, email-ingestion logs, object-storage access logs, document-processing job logs, application exception and timeout logs, process metrics, container orchestration events, and endpoint telemetry. Investigate repeated PDF submissions followed by long-running Python processes, job timeouts, worker restarts, queue backlogs, high CPU with little I/O, or repeated processing of the same PDF file. Correlate suspicious PDF uploads by source IP, user agent, authenticated account, filename, hash, storage object key, and timestamp. Forensic review should focus on malformed PDF inputs received shortly before CPU spikes, hung workers, autoscaling events, service restarts, or queue saturation. There are no supplied reports of named threat actors or public exploitation, so detection should be behavior-based rather than actor-specific.

• pypdf<6.9.2
• pypdf==6.9.1
• pypdf==6.9.0
• pypdf==6.8.0
• pypdf==6.7.0
• pypdf==6.6.0
• pypdf==6.5.0
• pypdf==6.4.0
• pypdf==6.3.0
• pypdf==6.2.0
• pypdf==6.1.0
• pypdf==6.0.0
• pypdf
• PdfReader(strict=False)
• strict=False
• Timeout while processing PDF
• PDF processing timed out
• worker timeout
• job timed out
• CPU time limit exceeded
• killed due to timeout
• hung PDF processing

What your security team should do

• Prioritize upgrading all pypdf deployments to 6.9.2 or later in applications that accept PDFs from users, external partners, email, web uploads, APIs, or shared storage.
• Add dependency scanning rules to flag pypdf versions earlier than 6.9.2 in source repositories, CI/CD pipelines, container images, and deployed workloads.
• Require hard timeouts, worker isolation, CPU limits, and retry limits around PDF parsing and conversion jobs.
• Review public-facing and automated PDF ingestion points for abuse potential and apply rate limits, file size limits, and malformed-file rejection.
• Monitor document-processing services for repeated timeouts, sustained high CPU, worker starvation, queue growth, and repeated submissions from the same source.
• Because there is no KEV listing, no known ransomware use, and low EPSS in the supplied data, treat this as a targeted availability-risk issue rather than an active mass-exploitation emergency unless local telemetry indicates abuse.