CVE-2026-27025

What it actually does

pypdf versions prior to 6.7.1 can consume excessive CPU time and memory while parsing a crafted PDF font /ToUnicode map containing unusually large values, particularly during text extraction. The flaw is a denial-of-service condition: successful exploitation can cause the parsing process, worker, container, or service using pypdf to hang, exhaust memory, be killed by the operating system, or become unavailable. It does not provide code execution, data modification, or direct information disclosure based on the available vulnerability details.

Why it matters to the business

Applications that accept or process untrusted PDF files may experience degraded performance or outages if a malicious or malformed PDF is submitted for text extraction, indexing, document conversion, malware scanning, search ingestion, or workflow automation. This can interrupt document-processing pipelines, delay customer or employee workflows, increase compute costs through repeated retries, and potentially affect availability of adjacent services if resource limits are not enforced. The vulnerability is not in the CISA KEV catalog, is not known to be used in ransomware campaigns, has low EPSS, and has no public exploit maturity reported, so urgency is highest for internet-facing or automated PDF-processing services and lower for tightly controlled offline uses.

How an attack unfolds

An attacker creates a PDF with a font object whose /ToUnicode entry contains values designed to trigger pathological parsing behavior in vulnerable pypdf versions. The attacker then causes a vulnerable application to process the file, for example by uploading it to a document portal, sending it to an ingestion workflow, placing it in a watched folder, or otherwise submitting it to a service that performs PDF text extraction. When the application invokes pypdf functionality that parses the font mapping, the parser spends excessive time and memory handling the crafted values. If the process lacks strict time, memory, or job isolation controls, this can lead to worker exhaustion, process termination, queue backlog, service instability, or denial of service. There are no named threat actors or active exploitation campaigns reported for this issue in the provided data.

How to fix it

Upgrade pypdf to version 6.7.1 or later wherever it is used. If tracking directly from the upstream Git repository, ensure the code includes commit ad2a45d769d56038af8747195cae097bbdb68eee or a later fixed revision. Rebuild and redeploy applications, containers, serverless packages, and background workers that vendor or pin pypdf. If immediate upgrade is not possible, reduce risk by preventing untrusted PDFs from reaching vulnerable parsing code, disabling or deferring text extraction for untrusted files, enforcing maximum file size and page count limits, applying per-job CPU and memory limits, running PDF processing in isolated worker pools or containers, setting execution timeouts, limiting queue concurrency, and rate-limiting repeated submissions from the same source.

How to confirm the fix worked

Confirm dependency inventories show pypdf 6.7.1 or later, or an upstream checkout containing commit ad2a45d769d56038af8747195cae097bbdb68eee. Validate all deployable artifacts, not only source repositories, by inspecting lockfiles, SBOMs, container images, virtual environments, and runtime package metadata. In Python environments, verify with commands such as `python -m pip show pypdf`, `python -c "import pypdf; print(pypdf.__version__)"`, or dependency-scanning tools. Exercise representative PDF text-extraction workflows with benign large PDFs and confirm worker memory, CPU, and timeout behavior remains bounded. Also confirm compensating controls are active: upload size limits, queue limits, worker memory limits, execution timeouts, and monitoring alerts for abnormal PDF-processing resource usage.

Typical attack path

1. Identify an application or workflow that accepts PDF files and uses pypdf for parsing or text extraction.
2. Craft or obtain a PDF containing an unusually large or malformed /ToUnicode font mapping designed to trigger excessive parsing work.
3. Submit the PDF through an upload endpoint, email ingestion path, API, document queue, shared folder, or other PDF-processing route.
4. Wait for the vulnerable pypdf code path to parse the /ToUnicode entry during text extraction or related processing.
5. Cause the worker or service to consume excessive CPU and memory, leading to slow processing, crashes, OOM kills, queue delays, or temporary service unavailability.
6. Repeat submissions or parallelize uploads to amplify operational impact where rate limits and resource isolation are weak.

How to detect it

Look for evidence that PDF-processing components experienced unusual resource exhaustion after processing uploaded or ingested PDFs. Relevant log sources include application logs for PDF extraction jobs, web or API upload logs, document queue logs, worker supervisor logs, container orchestration events, host kernel logs, EDR process telemetry, and cloud runtime metrics. Search for long-running pypdf text-extraction operations, repeated worker restarts, memory errors, OOM-kill events, CPU saturation, job timeouts, and clusters of failures tied to specific PDF filenames, upload requests, sender addresses, source IPs, or queue messages. Preserve suspect PDFs and inspect their structure for unusually large font /ToUnicode CMap entries. Since no unique exploit string or actor infrastructure is available from the vulnerability details, detection should focus on behavioral indicators: resource spikes, process termination, parser errors, and repeated submission of PDFs that consistently crash or stall pypdf-based processing.

• /ToUnicode
• pypdf
• MemoryError
• OOMKilled
• Out of memory
• Killed process
• Container killed due to memory usage
• worker timeout
• job timeout
• PDF text extraction failed
• PdfReadError
• CMap
• Beginbfchar
• beginbfrange

What your security team should do

• Inventory all applications, background jobs, containers, serverless functions, and document-processing pipelines that depend on pypdf, especially those accepting PDFs from external or untrusted users.
• Prioritize upgrading internet-facing, email-facing, API-accessible, and automated high-volume PDF-processing services to pypdf 6.7.1 or later.
• Regenerate lockfiles and rebuild runtime artifacts so the fixed dependency is actually deployed, then verify the running version in production-equivalent environments.
• Add or review resource isolation for PDF parsing workers, including memory limits, CPU limits, execution timeouts, queue backpressure, and automatic worker recycling.
• Apply input governance for PDFs: maximum upload size, maximum page count where feasible, rate limits, authentication for upload paths, and quarantine/review for anomalous documents.
• Monitor for signs of prior exploitation or testing, including repeated PDF-processing failures, memory exhaustion, OOM kills, unusually long text-extraction jobs, and bursts of uploads followed by worker crashes.
• If suspicious files are found, preserve the original PDFs and related logs for forensic review; inspect PDFs for oversized or unusual /ToUnicode font mappings.
• Because KEV, ransomware use, and exploit maturity are not indicated, handle as a medium-priority availability risk unless the affected PDF-processing surface is business-critical or exposed to untrusted users.