CVE-2026-27628

What it actually does

pypdf versions prior to 6.7.2 can enter an infinite loop while reading a specially crafted PDF. The flaw is an availability issue: successful triggering causes the parsing process or worker handling the document to consume CPU and fail to complete, potentially tying up application workers, queues, or serverless executions. The vulnerability does not indicate direct code execution, data theft, or integrity compromise, but any service that automatically ingests, validates, extracts text from, merges, splits, or otherwise reads untrusted PDFs with pypdf is exposed to denial-of-service risk.

Why it matters to the business

Applications that accept or process PDFs from users, partners, email attachments, document pipelines, or automated feeds may become slow, unresponsive, or unavailable when a malicious PDF is submitted. The practical impact can include stuck background jobs, exhausted worker pools, delayed document processing, failed uploads, increased infrastructure cost from runaway CPU consumption, and customer-facing service degradation. The EPSS score is low and the issue is not in CISA KEV, suggesting no broad public exploitation signal at this time, but the attack is low complexity wherever untrusted PDFs are processed.

How an attack unfolds

An attacker creates a malformed PDF designed to trigger the vulnerable parsing behavior in pypdf before version 6.7.2. The attacker then gets the target application to read that file, for example by uploading it to a web form, sending it through a document ingestion workflow, attaching it to a message that is automatically processed, or placing it where a scheduled job will parse it. When vulnerable pypdf code opens or reads the PDF, parsing does not terminate normally and the worker can spin indefinitely. Repeated submissions can amplify the impact by occupying multiple workers or queue consumers until the service times out, is restarted, or exhausts compute capacity.

How to fix it

Upgrade pypdf to version 6.7.2 or later wherever it is used. For source-based deployments, ensure the fix commit 4f1260f1d0c0c7c307f03e88257f8eeb229d5954 or a later upstream commit is present. Rebuild and redeploy applications, containers, serverless packages, and background workers that vendor or bundle pypdf. If immediate upgrade is not possible, apply the upstream patch manually and add compensating controls: enforce strict file-size limits, process untrusted PDFs in isolated workers, configure hard CPU and wall-clock timeouts for PDF parsing, cap queue retries, and terminate workers that exceed parsing time budgets. Treat all externally supplied PDFs as untrusted input.

How to confirm the fix worked

Confirm that dependency manifests, lockfiles, SBOMs, and runtime package inventories show pypdf 6.7.2 or later. In Python environments, verify with commands such as `python -m pip show pypdf` or `python -c "import pypdf; print(pypdf.__version__)"`. For source builds, confirm the deployed code includes commit 4f1260f1d0c0c7c307f03e88257f8eeb229d5954 or a later upstream revision. Validate that all services that parse PDFs have been rebuilt from updated dependencies, not only development lockfiles. Operationally, run regression tests for PDF upload, parsing, extraction, merge, and split workflows and confirm parsing timeouts are enforced. Security teams should also scan container images and build artifacts for older pypdf versions because vulnerable copies may be embedded outside the primary application dependency tree.

Typical attack path

1. Identify an application or workflow that accepts PDF files and processes them using pypdf before version 6.7.2.
2. Craft or obtain a PDF that triggers the infinite-loop condition during parsing.
3. Submit the PDF through an upload endpoint, document-processing API, email ingestion route, file drop, or other input path.
4. Wait for the backend parser to read the document with the vulnerable pypdf code path.
5. Cause one or more workers to hang or consume excessive CPU while parsing never completes.
6. Repeat submissions or trigger batch processing to exhaust worker capacity and degrade or deny service.

How to detect it

There is no unique public network signature or reliable file indicator for exploitation from the provided advisory; detection should focus on behavioral evidence around PDF ingestion. Review application logs, web access logs, upload audit trails, queue metrics, worker logs, container metrics, and host telemetry for PDF reads that coincide with long-running Python processes, worker timeouts, sustained high CPU, stuck jobs, repeated retries, or abrupt restarts. Hunt for repeated submissions of PDF files from the same source followed by parsing failures or timeouts in code paths using pypdf, PdfReader, PdfWriter, PdfMerger, or document extraction functions. In web and API logs, correlate PDF upload requests with backend latency spikes, HTTP 5xx responses, gateway timeouts, job timeouts, autoscaling events, and queue depth increases. In endpoint or container telemetry, look for Python processes consuming CPU for unusually long periods without corresponding I/O while processing PDF files. For forensic review, preserve suspicious PDFs, job payload metadata, worker stdout/stderr, crash or timeout logs, and package version evidence from affected runtimes. Treat the indicators below as operational hunt terms rather than definitive proof of compromise, because this denial-of-service flaw does not produce a known stable IOC.

• pypdf
• PdfReader
• PdfWriter
• PdfMerger
• pypdf==6.7.1
• pypdf==6.7.0
• pypdf==6.6
• pypdf==6.5
• pypdf==6.4
• pypdf==6.3
• pypdf==6.2
• pypdf==6.1
• pypdf==6.0
• Worker timeout
• worker timeout
• TimeoutError
• ReadTimeout
• Gateway Timeout
• HTTP 504
• .pdf
• application/pdf
• python

What your security team should do

• Inventory all applications, batch jobs, APIs, email processors, and document workflows that parse PDFs with pypdf, prioritizing internet-facing or externally supplied PDF ingestion paths.
• Upgrade all affected deployments to pypdf 6.7.2 or later, or apply upstream commit 4f1260f1d0c0c7c307f03e88257f8eeb229d5954 if using source builds.
• Add hard execution timeouts, CPU limits, memory limits, and worker isolation around PDF parsing so future parser bugs cannot indefinitely consume shared resources.
• Review logs and telemetry for suspicious PDF submissions followed by parser hangs, worker timeouts, high CPU, queue backlogs, or repeated retries.
• Ensure dependency scanning covers Python lockfiles, container images, vendored libraries, serverless deployment bundles, and build artifacts.
• Because current EPSS is low and the vulnerability is not known KEV, prioritize remediation based on exposure: externally reachable PDF ingestion services first, internal batch-only workflows second.