EUVD-2026-50372
GHSA-7c26-995w-6f47
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Network-reachable via PDF submission with no authentication (PR:N); A:H because unbounded allocation and infinite loops can fully crash the JVM validator process, not merely degrade it.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
3DescriptionCVE.org
veraPDF PDF parser is a PDF parser for veraPDF. Prior to 1.30.2 and 1.31.23, veraPDF-parser contains a denial-of-service vulnerability in veraPDF-parser/src/main/java/org/verapdf/pd/font/type1/Type1FontProgram.java and veraPDF-parser/src/main/java/org/verapdf/parser/postscript/PSOperator.java, where a crafted Type 1 font /FontDescriptor /FontFile program can execute unbounded PostScript array allocation, a zero-increment for loop, or self-recursive toExecute user dictionary lookups and exhaust validator memory, CPU, or stack. This issue is fixed in versions 1.30.2 and 1.31.23.
AnalysisAI
Denial-of-service in veraPDF-parser allows a remote unauthenticated attacker to crash or hang the PDF validation service by submitting a crafted PDF containing a Type 1 font whose /FontDescriptor /FontFile PostScript program exploits one of three unbounded resource primitives: a massive array allocation, a zero-increment for-loop, or a self-referential recursive user-dictionary lookup. All veraPDF-parser releases prior to 1.30.2 and 1.31.23 are affected across both active version branches. No public exploit code or active exploitation (CISA KEV) has been identified at time of analysis; vendor-released patches exist for both branches.
Technical ContextAI
veraPDF-parser is a Java PDF/A validation library (Maven: org.verapdf:parser, CPE cpe:2.3:a:verapdf:verapdf-parser:*:*:*:*:*:*:*:*) that embeds a cleartext PostScript interpreter for parsing Type 1 font programs embedded in PDF /FontDescriptor /FontFile streams. CWE-1325 (Improperly Controlled Sequential Memory Allocation) describes the root class, but the vulnerability actually encompasses three distinct unbounded-resource primitives. First, PSOperator.array() calls COSArray.construct(N) backed by new ArrayList<>(N) with no upper-bound validation, allowing Integer.MAX_VALUE (~16 GB allocation on a 64-bit JVM). Second, PSOperator.opFor() ran for (long i = initial; i <= limit; i += increment) with no guard against increment==0, producing an infinite loop. Third, Type1FontProgram.toExecute() performed recursive user-dictionary lookups with no visited-set or recursion-depth enforcement, causing StackOverflowError after ~16,000 JVM frames. All three operators (array, for, and unknown-name lookup) were admitted by a hardcoded allow-list in Type1FontProgram.toExecute(). The interpreter is invoked unconditionally by GFPDType1Font's constructor on every Type 1 font encountered during validation.
RemediationAI
Upgrade to veraPDF-parser 1.30.2 (for 1.30.x deployments) or 1.31.23 (for 1.31.x deployments), as confirmed by the vendor advisory at https://github.com/veraPDF/veraPDF-parser/security/advisories/GHSA-7c26-995w-6f47 and implemented in PR #703 (https://github.com/veraPDF/veraPDF-parser/pull/703) and commits 73d6ec0 and cb35386. The fix adds an integer-bounds check on array allocation, guards the for-operator against zero-increment by setting increment to zero and skipping execution, and changes the toExecute depth check from > to >= MAX_TO_EXECUTE_DEPTH to enforce the cap correctly. If immediate upgrade is not feasible, restrict PDF submission to authenticated, trusted clients only - this reduces exposure but does not eliminate risk if trusted users can be influenced to submit attacker-crafted documents. Additionally, running the veraPDF validator in a sandboxed JVM with a heap cap (e.g., -Xmx512m) and a process timeout will bound the blast radius of any DoS attempt; note that the JVM will throw OutOfMemoryError and the process may terminate, requiring a process supervisor to restart it.
Oracle Java SE 7 Update 6 and earlier contains multiple sandbox bypass vulnerabilities via the ClassFinder and forName m
Remote code execution in IBM Sterling B2B Integrator, Sterling Integrator, and Tivoli Common Reporting allows unauthenti
Java Runtime Environment sandbox bypass via incorrect image channel verification in 2D component allows remote unauthent
Oracle Java SE JDK/JRE 7 and 6 Update 27 and earlier allows remote code execution with complete system compromise throug
JBoss Seam 2 in Red Hat JBoss EAP 4.3.0 fails to sanitize JBoss Expression Language inputs, allowing remote attackers to
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 update 4 and earlier, 6 up
Multiple vulnerabilities in Oracle Java 7 before Update 11 allow remote attackers to execute arbitrary code by (1) using
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 2 and earlier, 6 Up
The WLS Security component in Oracle WebLogic Server 10.3.6.0, 12.1.2.0, 12.1.3.0, and 12.2.1.0 allows remote attackers
Unspecified vulnerability in the Java Runtime Environment (JRE) component in Oracle Java SE 7 Update 7 and earlier allow
Remote unauthenticated attackers can execute arbitrary code on Adobe ColdFusion servers through Java deserialization fla
The ExceptionDelegator component in Apache Struts before 2.2.3.1 interprets parameter values as OGNL expressions during
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today