CVE-2026-22691

What it actually does

This is a denial-of-service weakness in pypdf before 6.6.0 when reading malformed PDF files in non-strict mode. A PDF with an invalid or misleading startxref value and large amounts of whitespace can force pypdf to spend excessive time rebuilding the cross-reference table. The impact is CPU-bound long runtime or worker exhaustion during PDF parsing; there is no indication of arbitrary code execution, privilege escalation, or direct data disclosure.

Why it matters to the business

Systems that accept or process untrusted PDFs can become slow or unavailable if attackers submit specially malformed documents. The most likely consequences are delayed document ingestion, stuck background workers, degraded web application responsiveness, increased compute cost, failed business workflows, and possible queue backlogs. Public exploit maturity is currently listed as none, EPSS is low at 0.00391, and it is not in CISA KEV or known ransomware use, so urgency is highest for internet-facing upload portals, mail/document-processing pipelines, and services that parse PDFs automatically.

How an attack unfolds

An attacker identifies an application, API, email workflow, or batch process that accepts PDF files and uses a vulnerable pypdf version in non-strict parsing mode. The attacker submits a malformed PDF containing invalid startxref data and excessive whitespace arranged so that pypdf attempts expensive cross-reference table reconstruction. When the vulnerable parser processes the file, the worker spends an abnormally long time parsing instead of completing quickly. Repeated submissions can consume available workers, CPU time, request slots, or job queue capacity, causing denial of service for legitimate users. This attack does not require authentication if the PDF-processing path is publicly reachable, but authenticated upload features can also be abused.

How to fix it

Upgrade pypdf to version 6.6.0 or later. For source-based deployments, ensure the pypdf fix commit 10df9c72fa7fb9ab14101b9cb911d66e680282a8 or a later release containing it is present. For Debian 13 qemu package tracking this issue, use 1:8.0.4+dfsg-2 or later. Where immediate upgrade is not possible, avoid non-strict parsing for untrusted PDFs, enable strict parsing where compatible, enforce per-file processing timeouts, isolate PDF processing in resource-limited workers or containers, cap file size and upload rate, limit concurrent PDF jobs per user/source, and reject malformed PDFs that fail basic structural validation before invoking expensive processing.

How to confirm the fix worked

Confirm dependency versions using package manifests, SBOMs, lockfiles, container images, and runtime checks such as pip show pypdf or pip freeze, ensuring pypdf is 6.6.0 or later. Verify Debian package status where applicable and confirm qemu is at least 1:8.0.4+dfsg-2 on Debian 13. Review application configuration to determine whether pypdf is invoked with non-strict parsing for untrusted files. In a controlled test environment, run regression tests against malformed PDFs with invalid cross-reference metadata and verify parsing fails fast or is terminated by timeouts rather than consuming excessive CPU time. Validate that upload limits, worker timeouts, queue controls, and monitoring alerts are active.

Typical attack path

1. Find an application or service that accepts user-supplied PDF files.
2. Confirm or infer that backend PDF handling uses pypdf before version 6.6.0 in non-strict mode.
3. Submit a malformed PDF with invalid startxref data and excessive whitespace.
4. Trigger backend parsing, metadata extraction, splitting, merging, text extraction, preview generation, or validation logic.
5. Cause the parser to spend excessive time rebuilding the cross-reference table.
6. Repeat submissions to exhaust CPU, worker threads, job queues, or request capacity.

How to detect it

To determine whether this was already exploited, review application access logs, upload service logs, background job logs, APM traces, and host/container metrics for PDF-processing paths. Look for clusters of PDF uploads followed by long request durations, worker timeouts, job retries, queue growth, high CPU usage, or parser warnings referencing startxref or cross-reference rebuilding. Correlate events by source IP, authenticated user, API token, upload endpoint, file hash, and job identifier. Examine stored or quarantined PDFs submitted immediately before CPU spikes or worker exhaustion; suspicious files may contain malformed startxref sections, unusually large whitespace regions, or structures that cause pypdf to rebuild the xref table. Because this issue is a denial-of-service condition rather than code execution, expected artifacts are availability symptoms and malformed input files, not post-exploitation processes or persistence mechanisms.

• PdfReadWarning
• PdfReadError
• incorrect startxref pointer
• startxref not found
• EOF marker not found
• xref table not zero-indexed
• rebuild xref
• rebuilding xref
• invalid startxref
• startxref
• /startxref
• %PDF-

What your security team should do

• Inventory applications, services, containers, and serverless functions that process PDFs and depend on pypdf directly or transitively.
• Prioritize patching internet-facing upload flows, email attachment processors, document ingestion systems, and multi-tenant PDF-processing services.
• Upgrade pypdf to 6.6.0 or later and rebuild/redeploy affected images and packages.
• Disable non-strict PDF parsing for untrusted content where business logic permits.
• Add CPU, wall-clock, memory, file-size, and concurrency limits around PDF parsing jobs.
• Monitor for repeated malformed PDF submissions, parser warnings, request timeouts, and unusual CPU spikes in PDF-processing workers.
• Add rate limiting and abuse controls to unauthenticated or high-volume PDF upload endpoints.
• Retain suspicious submitted PDFs and related logs for forensic review if DoS symptoms are observed.