CVE-2026-82398

What it actually does

A crafted PDF can force pypdf's read_until_whitespace helper (pypdf/_utils.py) into a one-byte loop that repeatedly concatenates immutable bytes. A long run of non-whitespace data therefore costs quadratic CPU time, stalling or exhausting the parser process. Confidentiality and integrity are unaffected; only availability of the worker or service that parses the PDF is degraded.

Why it matters to the business

Any product that accepts untrusted PDFs and parses them with pypdf before 6.15.0 can be slowed or taken down by a single malicious file. Document-ingestion pipelines, upload APIs, email/attachment scanners, and background conversion jobs are the typical failure points. The issue is not in KEV, is not associated with ransomware, and has no known exploit maturity, but it has been public for about a month, so unpatched parsers remain an operational denial-of-service risk.

How an attack unfolds

An attacker builds a PDF whose streams contain an extremely long contiguous sequence of non-whitespace bytes, then delivers that file through any channel the target uses to ingest PDFs (web upload, API, email, or shared storage). When a vulnerable pypdf version reads the stream, read_until_whitespace concatenates one byte at a time onto an immutable bytes object, so runtime grows quadratically with the length of the run. CPU is pinned and the parse does not complete in a useful time. No authentication or extra user interaction is required beyond submitting the file, and the result is resource exhaustion rather than code execution or data theft.

How to fix it

Upgrade pypdf to 6.15.0 or later, which fixes the quadratic concatenation in read_until_whitespace. Rebuild and redeploy any application, container, or lockfile (pip, poetry, uv, pdm) that pins an older pypdf. If an immediate upgrade is not possible, parse only trusted PDFs, enforce strict file-size and wall-clock timeouts on parse jobs, and run PDF parsing in isolated workers with CPU and memory quotas so a single document cannot starve the rest of the service.

How to confirm the fix worked

Confirm the runtime environment imports pypdf 6.15.0 or newer (package metadata, lockfiles, and container images). After upgrade, exercise the same PDF ingest paths under resource limits and verify that large or malformed streams complete or fail fast instead of pinning CPU. Scan application SBOMs and transitive dependencies for remaining pypdf versions below 6.15.0.

Typical attack path

1. Identify a service, pipeline, or application that parses untrusted PDFs with pypdf prior to 6.15.0.
2. Craft a PDF containing a long run of non-whitespace bytes intended to trigger quadratic concatenation in read_until_whitespace.
3. Deliver the file via an available ingest path such as upload, API, email, or shared storage.
4. Wait for the parser to enter the expensive loop and consume CPU until the worker hangs, times out, or becomes unavailable.
5. Repeat submissions as needed to keep workers busy and extend the outage.

How to detect it

This is an algorithmic denial of service with no known in-the-wild campaigns, so look for effects rather than a unique payload signature. Review application and worker logs around PDF ingest for requests that never complete, repeated timeouts, or 5xx/504 responses on document-upload endpoints. Correlate with host metrics showing a Python process stuck at high CPU while handling a PDF, and with queue backlogs in document-processing workers. Preserve the offending PDF if a hung job can be tied to a specific upload, and inspect it for unusually long non-whitespace streams. There are no named threat actors or ransomware families associated with this issue.

What your security team should do

• Inventory all services and lockfiles that depend on pypdf and prioritize those that parse untrusted PDFs.
• Upgrade pypdf to 6.15.0 or later and redeploy affected applications.
• Place CPU time, memory, and wall-clock limits on PDF parsing workers until the upgrade is complete.
• Add dependency-scanning rules that fail builds still pinning pypdf below 6.15.0.
• Review ingest logs and worker metrics for historical CPU spikes during PDF parse as a check for prior abuse.