CVE-2026-28804

What it actually does

CVE-2026-28804 is a denial-of-service vulnerability in pypdf before version 6.7.5. A specially crafted PDF containing a stream that uses the /ASCIIHexDecode filter can cause pypdf to spend excessive time processing the stream when it is accessed. The flaw does not provide code execution, data theft, or privilege escalation, but it can tie up application worker threads or processes and reduce service availability.

Why it matters to the business

Systems that accept or process untrusted PDF files using vulnerable pypdf versions may experience slowdowns, stuck document-processing jobs, increased compute usage, failed uploads, delayed workflows, or temporary service outages. The CVSS score is moderate and EPSS is currently low, and it is not listed in CISA KEV or associated with ransomware, but exposure is still relevant for internet-facing upload portals, document pipelines, email ingestion, ticketing systems, and automated PDF processing services.

How an attack unfolds

An attacker creates a malformed or intentionally inefficient PDF that includes a stream using the /ASCIIHexDecode filter. The attacker then submits the file to an application, API, queue, email workflow, or other service that processes PDFs with a vulnerable pypdf version. When the application accesses the affected stream, pypdf enters a long-running processing path, consuming CPU time or blocking the worker handling the file. Repeated submissions can exhaust worker capacity, delay legitimate document processing, and degrade or interrupt service availability.

How to fix it

Upgrade pypdf to version 6.7.5 or later wherever it is used directly or as a transitive dependency. Rebuild and redeploy affected applications, containers, serverless packages, and background workers after dependency updates. If immediate upgrade is not possible, mitigate by enforcing PDF upload size limits, processing timeouts, worker isolation, queue rate limits, per-user upload throttling, and sandboxed document-processing services. Treat PDFs from external users, email attachments, and partner integrations as untrusted input.

How to confirm the fix worked

Confirm that all deployed runtimes use pypdf version 6.7.5 or later, for example by checking package lockfiles, SBOMs, container images, virtual environments, and runtime package metadata. Validate that document-processing services have timeouts and resource limits so a single PDF cannot monopolize workers indefinitely. Review CI/CD dependency scans to ensure vulnerable pypdf versions are no longer present. Perform functional testing with representative PDFs that use /ASCIIHexDecode streams to confirm normal processing completes within expected time limits after the upgrade.

Typical attack path

1. Identify an application or workflow that accepts PDF files and processes them server-side.
2. Create a crafted PDF containing a stream that uses the /ASCIIHexDecode filter in a way that triggers excessive runtime in vulnerable pypdf versions.
3. Upload, email, or otherwise submit the PDF to the target service.
4. Cause the application to parse or access the affected PDF stream using pypdf.
5. Repeat submissions or target multiple processing paths to consume workers, CPU, or queue capacity and degrade service availability.

How to detect it

Look for evidence of PDF-processing denial-of-service activity rather than compromise of confidentiality or integrity. Review application logs, upload logs, API gateway logs, email ingestion logs, queue/job logs, worker process telemetry, and container or host resource metrics. Indicators include repeated PDF submissions followed by parsing timeouts, unusually long processing durations, elevated CPU usage in Python workers, worker restarts, queue backlog growth, and files containing /ASCIIHexDecode near the time of service degradation. Preserve suspicious PDFs for offline analysis in an isolated environment and correlate source IPs, user accounts, upload endpoints, filenames, request IDs, and processing job IDs associated with timeouts or resource spikes.

• /ASCIIHexDecode
• ASCIIHexDecode
• pypdf
• PdfReader
• PDF processing timeout
• document processing timeout
• worker timeout
• job timeout
• CPU limit exceeded

What your security team should do

• Inventory applications, services, containers, and jobs that use pypdf and prioritize those that process externally supplied PDFs.
• Upgrade pypdf to 6.7.5 or later and redeploy all affected workloads.
• Add or verify PDF processing timeouts, CPU and memory limits, queue backpressure, and upload rate limits.
• Monitor PDF-processing services for long-running jobs, worker exhaustion, elevated CPU usage, and repeated failed or timed-out PDF parsing events.
• Add dependency scanning or SBOM checks to prevent vulnerable pypdf versions from being reintroduced.
• For public upload endpoints, consider isolating document parsing in a separate sandboxed worker tier with strict resource limits.