CVE-2026-48735: pypdf Memory Exhaustion via Malicious XMP Metadata

Technical summary

CVE-2026-48735 is a denial-of-service vulnerability in pypdf related to uncontrolled resource consumption during XMP metadata parsing. The root cause falls under CWE-770 (Allocation of Resources Without Limits or Throttling). When pypdf parses a crafted PDF containing oversized or redundantly nested XMP metadata, the parser allocates memory proportionally to the metadata size without appropriate safeguards, allowing an attacker to exhaust available system memory. The attack requires no authentication or special privileges—only the ability to supply a malicious PDF to an application using pypdf. A user must open or process the PDF (local attack vector, requires user interaction), triggering the memory exhaustion when the library's metadata handler processes the XMP stream.

Business impact

Organizations and developers using pypdf in document processing workflows face availability risk. Applications that accept user-uploaded PDFs—such as document management systems, content analysis platforms, or automated PDF-to-text converters—could experience service degradation or outages when processing a weaponized PDF. The attack requires no network access and relies on social engineering or supply-chain placement of malicious PDFs. For businesses handling sensitive document automation, this could disrupt critical workflows and delay processing. The impact is containable via version upgrade and input validation, but remediation timelines depend on deployment practices and testing cycles.

Affected systems

pypdf versions prior to 6.12.1 are vulnerable. The library is used by Python applications across document automation, data extraction, PDF generation, and content analysis domains. Direct exposure exists in any application where pypdf processes PDFs from untrusted sources (user uploads, external APIs, email attachments). Indirect exposure may occur in containerized or microservices architectures where memory limits are shared across processes. Systems running older pypdf versions in development, testing, or staging environments may not yet be patched. Severity is highest in multi-tenant SaaS platforms and batch processing systems where a single malicious PDF could impact multiple users or degrade shared infrastructure.

Exploitability

This vulnerability has low to moderate exploitability barriers. An attacker must craft a PDF with oversized XMP metadata and deliver it to a user or system running vulnerable pypdf code. No network access, authentication, or privilege escalation is required—only user interaction (opening or processing the file). Public tools for PDF manipulation could be adapted to generate proof-of-concept payloads, though no known public exploit code or KEV entry exists at this time. The attack is deterministic and repeatable; success depends on available memory and parser efficiency. Organizations with strict input validation and sandboxed PDF processing environments face reduced risk. Those accepting PDFs from the Internet without guardrails face higher exposure.

Remediation

The definitive remedy is to upgrade pypdf to version 6.12.1 or later. This patch version addresses the memory allocation flaw in XMP parsing. Prior to patching, defenders should implement compensating controls: (1) enforce memory limits and quotas on processes running pypdf, using OS-level controls or containerization; (2) validate PDF structure and metadata size before parsing using static analysis or alternative libraries; (3) restrict PDF processing to internal, trusted sources where possible; (4) implement timeouts on parsing operations to detect runaway resource consumption. For development teams, review dependency manifests (requirements.txt, poetry.lock, Pipfile) to identify all applications using pypdf and prioritize patching high-risk entry points first.

Patch guidance

Upgrade pypdf to version 6.12.1 or later. For Python environments, use pip: `pip install --upgrade pypdf>=6.12.1`. If using dependency management tools (Poetry, Pipenv, Conda), update your lock files to reflect the new version and re-run your application's test suite before deploying to production. Verify the package source is authentic (PyPI official repository). No configuration changes are required post-upgrade. Applications should be restarted to ensure the new library version is loaded. Test with your organization's existing PDF workflows to confirm backward compatibility. In air-gapped environments, obtain the patched wheel file from PyPI and distribute through internal package repositories.

Detection guidance

Monitor for signs of memory exhaustion in processes running pypdf: excessive page file usage, out-of-memory (OOM) kills, or sustained high memory consumption following PDF processing events. Enable application-level logging of PDF file sizes and metadata element counts during parsing. Alert on anomalous metadata structures (deeply nested elements, oversized text chunks). In network environments, flag inbound emails or documents with unusually large XMP sections for manual review. For incident response, correlate memory spikes with specific PDFs using file hashes and application logs. In containerized deployments, observe memory cgroup limits and eviction patterns. Static scanning of Python codebases can identify use of pypdf and prioritize inventory for patching.

Why prioritize this

While this vulnerability carries a CVSS 5.5 (MEDIUM) rating, it warrants prompt patching in environments that accept untrusted PDFs. The lack of KEV status suggests low active exploitation in the wild, but the ease of crafting a malicious PDF and the potential for service disruption in batch-processing or SaaS environments justifies prioritization. Organizations with externally-facing document upload features or PDF ingestion pipelines should patch within 2–4 weeks. Internal-only or airgapped systems can follow standard patch cycles. The fix is trivial (a version bump with no breaking changes), making implementation overhead minimal.

Risk score, explained

CVSS 5.5 reflects the attack vector (local—requires user interaction), no privilege escalation, and denial-of-service impact limited to availability (memory exhaustion does not compromise confidentiality or integrity). The score is appropriate for an availability-only flaw requiring user action; however, business context elevates urgency. Organizations relying on pypdf in customer-facing or revenue-critical workflows should treat this as higher priority than the base score suggests, while purely internal or low-traffic deployments can defer patching to regular cycles.

Frequently asked questions