CVE-2026-31826

What it actually does

CVE-2026-31826 is a denial-of-service vulnerability in pypdf before version 6.8.0. When pypdf parses a PDF content stream, it may trust or allocate based on an excessively large declared /Length value even when the actual stream data is much smaller. A crafted PDF can therefore cause disproportionate memory consumption during parsing, potentially exhausting process or host memory and causing the application, worker, container, or service handling the PDF to crash or be terminated by the operating system. The flaw does not directly provide code execution, data disclosure, or data modification, but it can severely affect availability of systems that process untrusted PDFs.

Why it matters to the business

Applications that accept, ingest, scan, convert, index, or otherwise process user-supplied PDFs using vulnerable pypdf versions can be disrupted by a malicious document. Operational consequences may include failed document uploads, stuck background jobs, degraded service performance, container restarts, worker exhaustion, queue backlogs, and broader service outages if PDF processing shares resources with customer-facing functions. The CVSS availability impact is high, but EPSS is currently low and the issue is not in CISA KEV, so urgency should be driven primarily by whether the organization processes untrusted PDFs at scale or in internet-facing workflows.

How an attack unfolds

An attacker crafts a PDF whose content stream declares a very large /Length value that does not match the actual amount of embedded stream data. The attacker then causes a vulnerable application to parse the file, commonly by uploading it, emailing it into an automated ingestion workflow, submitting it to a document conversion service, or placing it where a batch processor will read it. When pypdf versions prior to 6.8.0 parse the stream, memory usage grows based on the declared size. If limits are not enforced, the parser process may consume available memory until Python raises MemoryError, the container exceeds its memory limit, or the operating system kills the process. Repeated submissions can amplify the effect by keeping workers unavailable, filling queues, and causing recurring crashes.

How to fix it

Upgrade pypdf to version 6.8.0 or later wherever it is used, including direct dependencies, transitive dependencies, container images, serverless packages, build artifacts, and offline processing workers. If immediate upgrade is not possible, reduce exposure by rejecting or quarantining PDFs with unusually large stream /Length values, enforcing maximum upload and parsed-object sizes, running PDF parsing in isolated workers with strict memory and CPU limits, applying request throttling, and using queue controls to prevent one sender or source from monopolizing processing capacity. Prefer fail-closed behavior for malformed PDFs and ensure crashes in PDF-processing workers do not affect unrelated application components.

How to confirm the fix worked

Confirm all deployed runtimes and build manifests resolve pypdf to 6.8.0 or later. Check dependency files such as requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, conda environment files, SBOMs, and container image package inventories. In running environments, validate with commands such as `python -c "import pypdf; print(pypdf.__version__)"` where applicable. Perform a controlled negative test in a non-production environment using a malformed PDF with an oversized stream /Length value and verify that parsing is rejected or bounded without excessive memory growth. Also validate that upload limits, worker memory limits, retry limits, and queue isolation controls operate as intended.

Typical attack path

1. Identify an application or workflow that uses pypdf to parse PDFs from users or external sources.
2. Create a malformed PDF containing a content stream with an abnormally large /Length value and small or inconsistent actual stream data.
3. Submit the PDF through an upload form, API endpoint, email ingestion path, shared storage location, or batch-processing workflow.
4. Trigger vulnerable pypdf parsing of the crafted content stream.
5. Cause excessive memory allocation or memory pressure in the parsing process.
6. Crash, kill, restart, or stall the affected worker or service, potentially repeating submissions to sustain denial of service.

How to detect it

To determine whether exploitation was attempted or successful, review logs and telemetry from applications that upload, ingest, scan, convert, index, or parse PDFs using pypdf. Correlate PDF submissions with sudden memory spikes, process crashes, container OOM kills, worker restarts, failed jobs, and queue backlogs. Useful sources include application logs, upload/API access logs, background job logs, container orchestrator events, host syslog or kernel logs, Python exception traces, APM memory metrics, EDR process telemetry, and object-storage access logs for newly submitted PDFs. Look for repeated submissions from the same source followed by MemoryError exceptions, process termination, or orchestrator messages indicating memory-limit exits. For file-level triage, inspect suspicious PDFs for content streams with extremely large /Length declarations that are inconsistent with the actual stream size. Absence of named threat actor activity, KEV listing, or public exploit maturity lowers confidence of widespread exploitation, but organizations processing untrusted PDFs should still investigate availability incidents around PDF workflows.

• MemoryError
• Out of memory: Killed process
• oom-kill
• OOMKilled
• ExitCode: 137
• Container killed due to memory usage
• pypdf
• PdfReader
• /Length 999999999
• /Length 2147483647
• /Length 4294967295
• stream
• endstream

What your security team should do

• Inventory applications, services, workers, and automation that parse PDFs using pypdf, prioritizing internet-facing upload paths and externally sourced document ingestion.
• Upgrade all affected deployments to pypdf 6.8.0 or later and rebuild/redeploy containers or packaged artifacts that vendor Python dependencies.
• Add input validation and size limits for PDFs, including rejection or sandboxing of files with abnormal stream length declarations.
• Run PDF parsing in isolated worker processes or containers with strict memory, CPU, timeout, and retry limits.
• Monitor PDF-processing services for memory spikes, worker restarts, repeated malformed-PDF errors, and queue backlogs.
• Add rate limiting and abuse controls to document upload or ingestion endpoints to prevent repeated denial-of-service attempts.
• Review incident logs for unexplained out-of-memory events or crashes correlated with PDF submissions since the vulnerability publication date.