CVE-2026-54081: veraPDF PDF Parser DoS Vulnerability

CVE-2026-54081 Overview

CVE-2026-54081 is a denial-of-service vulnerability in veraPDF-parser, the PDF parsing component used by the veraPDF PDF/A validator. The flaw resides in Type1FontProgram.java and PSOperator.java, where a crafted Type 1 font /FontDescriptor /FontFile program can trigger unbounded PostScript array allocation, a zero-increment for loop, or self-recursive toExecute user dictionary lookups. Processing a malicious PDF exhausts validator memory, CPU, or stack. The issue is fixed in veraPDF-parser versions 1.30.2 and 1.31.23. The weakness is classified as [CWE-1325] Improperly Controlled Sequential Memory Allocation.

Critical Impact
Remote attackers can crash or hang veraPDF validation pipelines by submitting a single crafted PDF, disrupting document ingestion and archival workflows.

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

Discovery Timeline

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

Technical Details for CVE-2026-54081

Vulnerability Analysis

The vulnerability affects how veraPDF-parser executes embedded PostScript inside Type 1 font programs referenced by a /FontDescriptor /FontFile entry. The parser evaluates PostScript operators without enforcing bounds on array allocation size, for loop iteration counts, or recursion depth for user dictionary lookups.

An attacker who supplies a crafted PDF causes the validator to allocate arrays of arbitrary size, spin indefinitely on a zero-increment loop, or recurse into itself through toExecute dictionary references. Each path exhausts a different resource: heap memory, CPU time, or JVM stack space.

Because veraPDF is frequently deployed as a server-side validator inside document ingestion, archival, and PDF/A conformance pipelines, a single malicious upload can stall or terminate the JVM, blocking legitimate documents.

Root Cause

The root cause is missing input bounds on PostScript execution. PSOperator accepted any integer as an array size or loop count, and Type1FontProgram.toExecute recursed without a depth ceiling. The patch introduces three constants: MAX_PS_ARRAY_SIZE (65536), MAX_PS_FOR_ITERATIONS (10,000), and MAX_TO_EXECUTE_DEPTH (64).

Attack Vector

Exploitation requires only that a victim system parse an attacker-supplied PDF. No authentication or user interaction beyond normal document processing is required. The attack is network-reachable wherever veraPDF is exposed through an upload endpoint or automated ingestion queue.

java

// Patch: bounds added to PSOperator array allocation and for loops
public class PSOperator extends PSObject {
    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;

// Patch: recursion depth cap in Type1FontProgram.toExecute
private static final int MAX_TO_EXECUTE_DEPTH = 64;

private void toExecute(COSObject next, int depth) throws PostScriptException {
    if (depth >= MAX_TO_EXECUTE_DEPTH) {
        throw new PostScriptException(
            "Type 1 font program exceeded toExecute recursion depth");
    }
    PSObject operator = PSObject.getPSObject(next);
}
// Source: https://github.com/veraPDF/veraPDF-parser/commit/73d6ec002b98ce1f3f68640442f8e5d5613c80ce
// Source: https://github.com/veraPDF/veraPDF-parser/commit/cb3538607a549d63504299be1088c85ae48605f4

Detection Methods for CVE-2026-54081

Indicators of Compromise

Java processes running veraPDF that consume abnormal heap or CPU while parsing a single PDF
OutOfMemoryError, StackOverflowError, or thread hangs originating in org.verapdf.parser.postscript.PSOperator or org.verapdf.pd.font.type1.Type1FontProgram
PDF files with oversized /FontFile Type 1 streams containing large PostScript array operators or for loops with a zero step
Ingestion queue backlog growth correlated with specific uploaded PDFs

Detection Strategies

Inventory applications embedding veraPDF-parser and confirm version against 1.30.2 or 1.31.23
Add JVM instrumentation to log parse duration and memory delta per PDF, and alert on outliers
Statically scan uploaded PDFs for Type 1 fonts referencing PostScript operators with unusually large integer arguments

Monitoring Recommendations

Monitor JVM garbage collection frequency and thread stack traces from PDF-validation services
Alert on repeated PostScriptException messages referencing recursion depth or array size limits after patching
Track parse failures per source IP or tenant to identify abusive submitters

How to Mitigate CVE-2026-54081

Immediate Actions Required

Upgrade veraPDF-parser to 1.30.2 (1.30.x users) or 1.31.23 (1.31.x users) immediately
Rebuild and redeploy any application or container image that bundles veraPDF-parser as a dependency
Isolate PDF validation workloads in a resource-capped process or container to contain future parser DoS conditions

Patch Information

The fix is delivered in commits 73d6ec0 and cb35386, consolidated in pull request #703. See the veraPDF Security Advisory GHSA-7c26-995w-6f47 for full disclosure details.

Workarounds

Enforce strict JVM heap (-Xmx) and stack (-Xss) limits on veraPDF worker processes so a single malicious PDF cannot exhaust host resources
Wrap validation calls with an execution timeout and terminate parsers exceeding a per-file budget
Reject inbound PDFs whose embedded Type 1 /FontFile streams exceed a reasonable size threshold before invoking veraPDF

bash

# Configuration example: run veraPDF with capped heap, stack, and per-file timeout
timeout 30s java -Xmx512m -Xss1m \
  -jar verapdf-app.jar --format xml /input/document.pdf