CVE-2026-41168

What it actually does

CVE-2026-41168 is a denial-of-service flaw in pypdf versions before 6.10.1. A malicious PDF can declare incorrect, extremely large values in cross-reference stream /Size fields or object stream /N fields, causing pypdf to spend excessive time processing structures that do not correspond to real PDF objects. The issue does not provide code execution, data modification, or direct data disclosure, but it can tie up CPU and worker execution time in applications that parse untrusted PDFs.

Why it matters to the business

Applications that accept or process user-supplied PDFs may experience slowdowns, stuck jobs, queue backlogs, timeouts, or degraded service availability if attackers upload crafted documents. The CVSS score is moderate and EPSS is currently low, with no CISA KEV listing or known ransomware association, but the vulnerability is easy to trigger remotely when PDF parsing is exposed through uploads, APIs, email ingestion, document workflows, or automated processing pipelines.

How an attack unfolds

An attacker identifies an application feature that processes PDFs using a vulnerable pypdf version, such as upload validation, metadata extraction, page counting, form parsing, conversion, indexing, or document ingestion. The attacker crafts a PDF containing a cross-reference stream with an intentionally wrong and very large /Size value, or an object stream with an intentionally wrong and very large /N value. When the application passes the file to pypdf, the library attempts to process the declared object counts and spends excessive time in parsing logic. Repeated submissions can consume workers, increase CPU usage, delay document processing, and create application-level denial of service without needing authentication if the PDF-processing endpoint is public.

How to fix it

Upgrade pypdf to version 6.10.1 or later wherever it is used directly or transitively. If immediate upgrade is not possible, manually apply the upstream patch changes referenced by the project, and reduce exposure by enforcing PDF file size limits, request rate limits, upload authentication, job execution timeouts, per-file parsing deadlines, queue isolation, and worker resource limits. Treat all externally supplied PDFs as untrusted input and avoid parsing them in high-privilege or shared critical service processes.

How to confirm the fix worked

Confirm that all deployed application packages, containers, virtual environments, build artifacts, and dependency lockfiles use pypdf 6.10.1 or later. Use dependency inventory commands such as `pip show pypdf`, `pip freeze`, `pipdeptree`, Software Composition Analysis tooling, and container image scans to identify vulnerable versions. Validate mitigations by testing that PDF processing jobs have bounded execution time and that malformed PDFs cannot monopolize workers indefinitely. Review CI/CD dependency manifests to ensure vulnerable pypdf versions cannot be reintroduced.

Typical attack path

1. Find an application endpoint, API, mailbox, or workflow that accepts PDF files and processes them server-side.
2. Create or obtain a malformed PDF containing an oversized incorrect cross-reference stream /Size value or object stream /N value.
3. Submit the crafted PDF to the target processing path.
4. Trigger vulnerable pypdf parsing during validation, metadata extraction, indexing, rendering preparation, or other document handling logic.
5. Repeat submissions or send multiple crafted files to exhaust processing workers, increase CPU load, and cause timeouts or service degradation.

How to detect it

Look for evidence of resource-exhaustion attempts against PDF-processing workflows rather than classic compromise artifacts. Review web access logs, API gateway logs, upload service logs, application logs, background worker logs, job queue metrics, APM traces, container metrics, and host telemetry for repeated PDF submissions followed by long processing times, worker timeouts, elevated CPU, queue growth, or process restarts. Investigate files submitted shortly before these events, especially PDFs containing cross-reference streams with unusually large /Size values or object streams with unusually large /N values inconsistent with the file size. Useful artifacts include repeated 408/429/500/502/503/504 responses from PDF upload or processing endpoints, job timeout exceptions, pypdf parsing stack traces, sudden increases in document-processing latency, and repeated submissions from the same source address, account, API token, or automation client. If suspicious PDFs are retained, inspect them offline in a sandbox and avoid opening them in production workflows.

• /Type /XRef
• /Type/XRef
• /Size 999999
• /Size 1000000
• /Size 2147483647
• /Type /ObjStm
• /Type/ObjStm
• /N 999999
• /N 1000000
• /N 2147483647
• pypdf.errors
• PdfReadError
• TimeoutError
• worker timeout
• job timed out
• PDF processing timeout
• document processing timeout

What your security team should do

• Prioritize upgrading all direct and transitive pypdf installations to 6.10.1 or later in applications that process externally supplied PDFs.
• Inventory all PDF-processing paths, including upload portals, APIs, email ingestion, document management systems, indexing pipelines, and background workers.
• Add or verify parser timeouts, worker CPU and memory limits, queue isolation, file size limits, and rate limiting for PDF ingestion workflows.
• Search historical application, worker, and infrastructure logs for abnormal PDF processing durations, repeated timeouts, high CPU events, or bursts of failed PDF jobs.
• Add detection logic for suspicious PDFs containing cross-reference stream /Size values or object stream /N values that are implausibly large relative to file size.
• Monitor dependency manifests and container images for pypdf versions earlier than 6.10.1 until remediation is complete.