Maven · org.verapdf:parser
veraPDF Parser DoS via PostScript CMap Streams
Description
A PostScript-interpreter-driven Denial of Service (CWE-1325) vulnerability in veraPDF allows a remote attacker to exhaust validator memory or CPU by submitting a PDF whose Type 0 font /Encoding (or any /ToUnicode) is a CMap stream containing attacker-supplied PostScript. veraPDF reuses its CMap parser as a general PostScript interpreter and exposes the unguarded array N allocation operator and the for control operator with no zero-increment guard. This affects all current versions of veraPDF-parser.
The vulnerability resides in veraPDF-parser. CMap streams referenced as a Type 0 font's /Encoding (or any font's /ToUnicode) are parsed by CMapParser (veraPDF-parser/src/main/java/org/verapdf/pd/font/cmap/CMapParser.java), which extends PSParser. Tokens that are not the small CMap-specific keyword set (begincodespacerange, bfchar, cidchar, ...) fall through to PSObject.execute (veraPDF-parser/src/main/java/org/verapdf/parser/postscript/PSObject.java), which dispatches generic PostScript operators implemented in PSOperator (veraPDF-parser/src/main/java/org/verapdf/parser/postscript/PSOperator.java).
Two operators in that interpreter take their bound from the PDF and apply no validation:
array at PSOperator.java:536-547 pops the top number from the operand stack and immediately calls COSArray.construct(arraySize), then loops arraySize times appending COSObject.getEmpty(). COSArray.construct(int) calls new ArrayList<>(arraySize) (COSArray.java:102), so the underlying Object[] is allocated up-front. Passing 2147483647 (Integer.MAX_VALUE) requests a 16 GB backing array on a 64-bit JVM.for at PSOperator.java:571-592 reads initial, increment, and limit from the stack and loops for (long i = initial; i <= limit; i += increment). Because increment is unchecked, 0 0 1 { } for produces an infinite-CPU spin (and progressively a heap exhaustion as each iteration pushes i onto the operand stack).CMapFactory.getCMap only catches IOException and PostScriptException; it does not catch OutOfMemoryError or wall-clock budget, so the failure propagates out of font model construction and aborts the validation worker.
A single payload byte sequence, the unframed PostScript 2147483647 array, is sufficient. No begincmap/endcmap framing is required because the operator runs before the parser ever reaches the CMap structure.
This impacts all current releases of the veraPDF-parser. Successful exploitation requires only that the target validate an attacker-supplied PDF; a single Type 0 font with a malicious /Encoding (or any /ToUnicode) stream is sufficient.
Cap array allocation and forbid zero increments in for.
As a defensive measure, also wrap CMapFactory.getCMap to enforce a wall-clock and operand-stack-size budget on CMap parsing, and audit the remaining unbounded operators (copy, roll, dict) for similar primitives.
Is your project exposed to this? Stateward checks every dependency on every pull request and flags it only if your code actually reaches it.
Check my repoSources: CISA KEV (public domain), OSV.dev & GitHub Advisory Database (CC-BY-4.0), FIRST EPSS, NVD/CWE (public domain). Served live from the Stateward advisory database.