CVE-2026-54080: veraPDF PDF Parser DoS Vulnerability

CVE-2026-54080 Overview

CVE-2026-54080 is a denial-of-service vulnerability in veraPDF-parser, the PDF parsing component used by the veraPDF validator. The flaw resides in CMapParser.java and PSOperator.java, where a crafted Type 0 font /Encoding or /ToUnicode CMap stream can trigger unbounded PostScript array allocation or a zero-increment for loop. An attacker who submits a malicious PDF to a validation pipeline can exhaust validator memory or CPU. The issue is classified under [CWE-1325: Improperly Controlled Sequential Memory Allocation]. Fixed releases are 1.30.2 and 1.31.23.

Critical Impact
A single crafted PDF can hang or crash the veraPDF validator, disrupting automated PDF/A conformance pipelines and archival workflows that ingest untrusted documents.

Affected Products

veraPDF-parser versions prior to 1.30.2 (1.30.x branch)
veraPDF-parser versions prior to 1.31.23 (1.31.x branch)
Applications embedding veraPDF for PDF/A validation of untrusted input

Discovery Timeline

2026-07-29 - CVE-2026-54080 published to NVD
2026-07-29 - Last updated in NVD database

Technical Details for CVE-2026-54080

Vulnerability Analysis

The vulnerability affects two parser paths that both interpret embedded PostScript from PDF font resources. When veraPDF processes a Type 0 (composite) font, it parses associated /Encoding and /ToUnicode CMap streams. Those streams contain PostScript operators that veraPDF-parser evaluates through PSOperator.java. The parser lacked bounds on two constructs: array allocation size and loop iteration count.

A PSOperator handling an array request with an attacker-controlled size argument allocated a Java array of that size. Additionally, PostScript for loops with a zero increment were not detected, allowing infinite iteration. Both conditions cause resource exhaustion long before validation completes. The parser also permitted unbounded toExecute recursion depth in Type1FontProgram, enabling a related stack-exhaustion path.

Root Cause

The root cause is missing input validation on PostScript execution primitives inside the PDF font subsystem. Neither the array allocation path nor the for-loop step value was checked against reasonable maximums, and recursive execution had no depth ceiling. This matches the [CWE-1325] pattern of improperly controlled sequential allocation.

Attack Vector

The attack vector is network-reachable in any deployment where veraPDF ingests PDFs from external sources. Common exposure points include archive submission portals, document conversion services, and CI pipelines that run PDF/A conformance checks. The attacker needs no authentication and no user interaction beyond delivery of a single malicious PDF file.

java

// Patch: bounded PostScript execution in PSOperator.java
public class PSOperator extends PSObject {

    private static final Logger LOGGER = Logger.getLogger(PSOperator.class.getCanonicalName());
    private static final int MAX_PS_ARRAY_SIZE = 1 << 16;
    private static final int MAX_PS_FOR_ITERATIONS = 10_000;
    private Stack<COSObject> operandStack;
    private Map<ASAtom, COSObject> userDict;
    private final String operator;
// Source: https://github.com/veraPDF/veraPDF-parser/commit/cb3538607a549d63504299be1088c85ae48605f4

The fix introduces MAX_PS_ARRAY_SIZE (65,536) and MAX_PS_FOR_ITERATIONS (10,000) constants to cap allocation and iteration. A companion change in Type1FontProgram.java enforces MAX_TO_EXECUTE_DEPTH = 64 on recursive PostScript execution.

Detection Methods for CVE-2026-54080

Indicators of Compromise

veraPDF processes hanging indefinitely or terminating with OutOfMemoryError while parsing a specific PDF
Sustained high CPU utilization by the JVM hosting veraPDF, correlated with a single input document
Repeated validation failures on documents referencing Type 0 fonts with unusually large /Encoding or /ToUnicode CMap streams

Detection Strategies

Inspect PDF submissions for embedded CMap streams containing PostScript array operators with abnormally large numeric operands (greater than 65,536)
Flag CMap streams containing for loops where the step (increment) argument evaluates to zero
Monitor veraPDF exit codes and wall-clock runtime per document, alerting on jobs that exceed baseline validation duration

Monitoring Recommendations

Log JVM heap and CPU usage of veraPDF worker processes; alert on sudden growth during single-document validation
Correlate validator crashes with the input file hash to identify documents used in repeated attempts
Ingest application logs into a centralized analytics tier so timeouts and OOM events can be searched across the fleet

How to Mitigate CVE-2026-54080

Immediate Actions Required

Upgrade veraPDF-parser to 1.30.2 (1.30.x users) or 1.31.23 (1.31.x users) as published in GHSA-jrmc-qg6p-94fp
Run veraPDF validation workers under strict JVM heap limits (-Xmx) and OS-level CPU/time quotas
Isolate validation processes in containers or sandboxes so resource exhaustion cannot affect other services

Patch Information

The fix landed in Pull Request 703 via commits 73d6ec0 and cb35386. The patch caps PostScript array size, for-loop iteration count, and toExecute recursion depth. Update dependencies to 1.30.2 or 1.31.23 and rebuild any applications embedding veraPDF-parser.

Workarounds

Enforce a maximum per-document validation timeout at the process supervisor level and kill workers that exceed it
Reject inbound PDFs above a defined size threshold before they reach the parser
Pre-filter documents to strip or block Type 0 fonts with oversized CMap streams when validation is not strictly required

bash

# Run veraPDF validation with bounded memory and a hard wall-clock timeout
timeout 60s java -Xmx512m -jar verapdf.jar --format xml /input/document.pdf