CVE-2026-28351

What it actually does

pypdf versions prior to 6.7.4 can consume excessive memory while parsing a crafted PDF content stream that uses the RunLengthDecode filter. The flaw is an availability issue: when a vulnerable application processes the malicious PDF, decompression/parsing can trigger large memory allocation and potentially crash the worker process, exhaust container memory, or degrade service performance. It does not indicate code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

Applications that accept or automatically process PDFs could be slowed or taken offline by a specially crafted file, disrupting document upload, ingestion, preview, OCR, billing, case-management, or workflow systems that depend on pypdf. The current public exploitation signal is low: EPSS is 0.00423, it is not listed in CISA KEV, ransomware use is not reported, and exploit maturity is listed as none; however, exposure can be broad because pypdf is commonly embedded as a transitive dependency in Python applications and document-processing services.

How an attack unfolds

An attacker identifies an application or background job that parses untrusted PDF files with a vulnerable pypdf version. The attacker submits or otherwise causes the system to process a crafted PDF containing a content stream that uses the RunLengthDecode filter in a way that expands or allocates memory disproportionately during parsing. When the application invokes pypdf to read or process the document, memory usage spikes. Depending on process limits and workload isolation, the result may be a failed request, worker crash, container restart, service slowdown, or broader denial of service if multiple files are submitted repeatedly.

How to fix it

Upgrade pypdf to version 6.7.4 or later wherever it is used directly or transitively. Review Python dependency manifests and lock files, including requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, setup.cfg, setup.py, and generated SBOMs. If immediate upgrade is not possible, apply the upstream workaround from pypdf PR #3664 where feasible, restrict PDF processing to isolated workers with strict memory and CPU limits, enforce file size and page/content limits, rate-limit upload and ingestion endpoints, and quarantine or reject PDFs that use RunLengthDecode until patched if business workflows allow. Ensure container, job runner, and process supervisors have safe restart behavior so one malicious file cannot destabilize shared services.

How to confirm the fix worked

Confirm that all deployed Python environments resolve pypdf to 6.7.4 or later using package inventory, lock-file review, container image inspection, and runtime checks such as `python -m pip show pypdf` or equivalent dependency tooling. Verify that transitive dependencies do not pin pypdf below 6.7.4. In a non-production environment, run regression tests that parse representative PDFs, including PDFs using RunLengthDecode, while monitoring memory usage to confirm bounded behavior. Validate operational mitigations by confirming upload limits, worker memory limits, rate limits, and document-processing isolation are active. Rebuild and redeploy affected images or artifacts rather than only updating source manifests.

Typical attack path

1. Find an internet-facing or workflow-exposed feature that accepts PDF files, such as upload, import, preview, conversion, or automated email/document ingestion.
2. Confirm or infer that the backend uses pypdf or a package that depends on pypdf to parse PDF content streams.
3. Prepare a malformed or adversarial PDF using the RunLengthDecode filter to induce excessive memory consumption during parsing.
4. Submit the file to the vulnerable feature or place it where an automated processor will ingest it.
5. Trigger repeated parsing attempts, if necessary, to exhaust worker memory, cause process termination, or degrade availability.

How to detect it

Look for signs of denial-of-service activity rather than data theft. Useful sources include application logs for PDF parsing failures, Python exception logs, container orchestration events, process supervisor logs, web upload logs, object-storage access logs, queue/job processor logs, and host telemetry for out-of-memory events. Investigate bursts of failed PDF processing, repeated uploads of similar PDF files, spikes in memory usage during pypdf parsing, worker restarts shortly after ingesting a PDF, and OOMKilled or MemoryError events correlated with PDF upload or ingestion timestamps. If uploaded files are retained, triage suspicious PDFs by searching for RunLengthDecode filter usage and unusually large or malformed content streams. Because public exploitation maturity is currently reported as none and EPSS is low, absence of known threat-actor indicators should not replace behavioral review of crashes and resource exhaustion around PDF parsing.

• /RunLengthDecode
• /Filter /RunLengthDecode
• /Filter[/RunLengthDecode
• /Filter [/RunLengthDecode
• /RL
• MemoryError
• OOMKilled
• Killed process
• Out of memory
• pypdf
• RunLengthDecode
• pypdf.filters
• PdfReader

What your security team should do

• Inventory all services, batch jobs, serverless functions, and containers that process PDFs with Python and identify direct or transitive use of pypdf below 6.7.4.
• Upgrade pypdf to 6.7.4 or later and rebuild all affected deployment artifacts.
• Prioritize internet-facing PDF upload, preview, conversion, and ingestion paths before internal-only processing jobs.
• Add or verify memory limits, request size limits, queue rate limits, and worker isolation around PDF processing to reduce blast radius from malformed files.
• Search logs and telemetry for recent PDF-processing crashes, MemoryError events, container OOM kills, and repeated submissions of PDFs containing RunLengthDecode.
• Add monitoring alerts for abnormal memory growth, worker restarts, failed PDF parsing spikes, and repeated uploads from the same source.
• If upgrade is delayed, consider temporarily blocking or quarantining PDFs that contain RunLengthDecode streams in untrusted upload flows after testing business impact.