CVE-2026-40260

What it actually does

CVE-2026-40260 is a denial-of-service vulnerability in pypdf versions prior to 6.10.0. A malicious PDF can include manipulated XMP metadata entity declarations that cause excessive memory consumption when the library parses the document metadata. The flaw does not provide code execution, data theft, or file modification by itself; its primary impact is availability degradation through RAM exhaustion in applications, workers, APIs, or batch jobs that process untrusted PDFs with pypdf.

Why it matters to the business

Organizations that accept, ingest, analyze, index, redact, merge, or otherwise process user-supplied PDFs may experience service slowdowns, failed jobs, worker crashes, queue backlogs, container restarts, or broader service disruption if malicious PDFs are processed. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but the issue is still operationally relevant because PDF-processing services are often exposed to untrusted uploads and may process files automatically at scale.

How an attack unfolds

An attacker crafts a PDF containing XMP metadata with malicious or highly expansive entity declarations designed to consume large amounts of memory during parsing. The attacker then submits the PDF to an application path that uses a vulnerable pypdf version and parses XMP metadata, such as upload validation, metadata extraction, document indexing, conversion, or automated processing. When the vulnerable parser reads the metadata, memory usage spikes. Depending on resource limits and deployment architecture, the affected process may become slow, be killed by the operating system or container runtime, fail the current request, or destabilize adjacent workloads sharing the same resources.

How to fix it

Upgrade pypdf to version 6.10.0 or later wherever it is used. Because affected products are Python packages, check direct and transitive dependency declarations in requirements.txt, pyproject.toml, poetry.lock, Pipfile.lock, conda environment files, container images, and application build artifacts. If immediate upgrade is not possible, reduce exposure by rejecting or quarantining untrusted PDFs before metadata parsing, disabling unnecessary XMP metadata parsing where supported by the application design, enforcing strict per-process/container memory limits, isolating PDF processing in sandboxed worker pools, applying upload size limits, and using queue rate limits to prevent repeated resource exhaustion attempts.

How to confirm the fix worked

Confirm that all deployed applications, build artifacts, and container images resolve pypdf to 6.10.0 or later using package inventory, dependency lockfiles, software composition analysis, or runtime checks such as `python -m pip show pypdf`. Exercise representative PDF-processing workflows after upgrade to verify normal behavior. For exposure validation, identify code paths that call pypdf against untrusted PDFs and specifically determine whether XMP metadata is parsed. For mitigation validation, test that oversized or malformed PDF metadata is rejected, processed in an isolated worker, or terminated within configured memory and timeout limits without affecting service availability.

Typical attack path

1. Identify an application or service that accepts PDF files from unauthenticated or low-privileged users.
2. Craft a PDF with manipulated XMP metadata entity declarations intended to expand or allocate excessive memory during parsing.
3. Upload, email, submit, or otherwise deliver the PDF to a workflow that uses pypdf before version 6.10.0.
4. Trigger metadata parsing through document inspection, indexing, conversion, validation, or other automated processing.
5. Cause high memory consumption, worker failure, request timeouts, service degradation, or denial of service.

How to detect it

Look for evidence of denial-of-service attempts against PDF-processing workflows rather than compromise artifacts. Relevant sources include application upload logs, document-processing worker logs, API gateway and web server logs, object storage access logs, job queue telemetry, container orchestration events, host kernel logs, EDR process telemetry, and APM metrics. Investigate correlations between PDF submissions and sudden memory spikes, out-of-memory kills, worker restarts, request timeouts, HTTP 500/502/503 responses, queue backlog growth, or repeated failures during metadata extraction. Preserve suspicious PDFs for offline analysis in an isolated environment and inspect their XMP metadata for XML entity declarations, DOCTYPE declarations, or unusually large/recursive metadata structures. There are no known public threat actors, KEV listing, or ransomware campaigns associated with this vulnerability in the provided data, so detection should focus on anomalous resource exhaustion around PDF parsing.

• OutOfMemoryError
• MemoryError
• OOMKilled
• Killed process
• out of memory
• Container killed due to memory usage
• exit code 137
• exit status 137
• SIGKILL
• pypdf
• PdfReader
• xmp_metadata
• /Metadata
• <?xpacket
• <!DOCTYPE
• <!ENTITY
• application/pdf

What your security team should do

• Inventory all services, scripts, workers, and container images that use pypdf, especially those processing externally supplied PDFs.
• Prioritize upgrade to pypdf 6.10.0 or later for internet-facing upload services, email/document ingestion pipelines, and automated document-processing workers.
• Add memory, CPU, timeout, upload-size, and queue-rate controls around PDF parsing workloads to limit denial-of-service blast radius.
• Run software composition analysis in CI/CD to prevent reintroduction of pypdf versions prior to 6.10.0.
• Review recent PDF-processing errors, memory exhaustion events, worker restarts, and failed upload spikes for signs of attempted exploitation.
• Where feasible, isolate PDF processing from core application services using sandboxed workers or containers with strict resource quotas.