Which versions of veraPDF are affected by CVE-2026-54078?

veraPDF, a PDF validation tool used across organizations for document processing, contains a critical vulnerability allowing remote attackers to extract sensitive files and manipulate outbound…. A patch is available.

How to fix or mitigate CVE-2026-54078?

Within 24 hours: identify all veraPDF deployments including precise artifact versions (org.verapdf:validation-model for classic or validation-model-jakarta), note which systems process external or untrusted PDF sources, and assess network exposure of each instance. Within 7 days: implement network-level egress filtering to restrict or monitor outbound connections from veraPDF servers, segregate validation infrastructure onto isolated network segments with limited file and system access, and halt processing of untrusted PDF sources where feasible. Within 30 days: establish monitoring for veraPDF security patch releases, develop a phased upgrade plan for all affected artifact versions, conduct a full assessment of files and systems accessible to validation processes to quantify potential data exposure, and prepare deployment procedures for patched versions when available.

veraPDF CVE-2026-54078

Q: What is the CVSS score of CVE-2026-54078?

CVE-2026-54078 has a CVSS 4.0 base score of 8.7 (High). CVSS vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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. EPSS exploitation probability: 0.3%.

EUVD-2026-50369 HIGH

Improper Restriction of XML External Entity Reference (CWE-611)

2026-07-29 https://github.com/veraPDF/veraPDF-validation

GHSA-3jh7-wm29-q568

XXE Java SSRF

8.7

CVSS 4.0 · Vendor: https://github.com/veraPDF/veraPDF-validation

Severity by source

Vendor (https://github.com/veraPDF/veraPDF-validation) PRIMARY

8.7 HIGH

CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/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

vuln.today AI

7.5 HIGH

A network-reachable validator processes the malicious PDF with no auth or user interaction (AV:N/AC:L/PR:N/UI:N); primary impact is arbitrary file read and SSRF reflected in-band, so C:H with I/A none.

3.1 AV:N/AC:L/PR:N/UI:N/S:N/C:H/I:N/A:N

4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (https://github.com/veraPDF/veraPDF-validation).

CVSS VectorVendor: https://github.com/veraPDF/veraPDF-validation

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Lifecycle Timeline

Patch available

Jul 29, 2026 - 16:02 EUVD

Source Code Evidence Fetched

Jul 29, 2026 - 15:30 vuln.today

Analysis Generated

Jul 29, 2026 - 15:30 vuln.today

CVE Published

Jul 29, 2026 - 15:11 cve.org

HIGH

DescriptionCVE.org

Summary

Description An XML External Entity Injection (CWE-611) vulnerability in veraPDF allows a remote attacker to read arbitrary files on the server file system and perform Server-Side Request Forgery by submitting a crafted PDF containing a malicious rich-text (/RC or /RV) entry. This affects all current versions of veraPDF-validation.

Details

The vulnerability resides in veraPDF-validation validation-model/src/main/java/org/verapdf/gf/model/tools/DictionaryKeysHelper.java within the getRichTextStringOrStreamEntryStringRepresentation() method. This helper extracts the XHTML rich-text body from a PDF dictionary string or stream and parses it with a DOM parser to return the concatenated text content.

The vulnerability stems from two combined issues:

The DocumentBuilderFactory is instantiated with default settings , no disallow-doctype-decl, no disabling of external general/parameter entities, no FEATURE_SECURE_PROCESSING, and no secure EntityResolver. The default JAXP/Xerces parser will therefore resolve <!DOCTYPE … SYSTEM "…"> and <!ENTITY … SYSTEM "…"> declarations.
After parsing, getAllNodeText() recursively concatenates every text node in the document and returns it as the model property value. This means the expanded contents of any external entity are reflected directly back into the validation report.

Impact

This impacts all current releases of the veraPDF validation-model module.

Successful exploitation requires only that the target validate an attacker-supplied PDF. A single markup annotation with a crafted /RC string is sufficient.

Proposed Patch

Harden the DocumentBuilderFactory in validation-model/src/main/java/org/verapdf/gf/model/tools/DictionaryKeysHelper.java per the OWASP XXE Prevention Cheat Sheet to disallow DOCTYPE outright.

AnalysisAI

Arbitrary file disclosure and Server-Side Request Forgery in veraPDF's validation-model module allow a remote attacker to read files off the validating host and force outbound requests by feeding it a crafted PDF. The flaw lives in DictionaryKeysHelper.getRichTextStringOrStreamEntryStringRepresentation(), which parses XHTML rich-text (/RC or /RV) annotation content with a default, unhardened DocumentBuilderFactory that resolves external entities and then reflects the expanded entity contents back into the validation report. All current releases of both the classic (org.verapdf:validation-model) and Jakarta (validation-model-jakarta) artifacts are affected; there is no public exploit identified at time of analysis and it is not listed in CISA KEV, though the vendor advisory (GHSA-3jh7-wm29-q568) describes exploitation as trivial.

Technical ContextAI

This is a classic XML External Entity Injection (CWE-611). veraPDF is a PDF/A and PDF/UA conformance validator; its validation-model module inspects PDF structures, including markup-annotation rich-text streams that carry an XHTML body. To extract the plain text of that body, the code builds a JAXP/Xerces DOM parser via DocumentBuilderFactory using default settings - it does not set disallow-doctype-decl, does not disable external general or parameter entities, does not enable FEATURE_SECURE_PROCESSING, and installs no restrictive EntityResolver. Consequently the parser honors inline <!DOCTYPE ...> and <!ENTITY ... SYSTEM "..."> declarations. A second amplifying issue is that getAllNodeText() recursively concatenates every text node and returns it as a model property, so the resolved external-entity payload (file:// contents or an http:// SSRF response body) is echoed straight into the validation output - turning a blind XXE into an in-band data-exfiltration primitive. The affected packages are the Maven coordinates org.verapdf:validation-model and org.verapdf:validation-model-jakarta.

RemediationAI

Vendor-released patch: upgrade to 1.30.2 (for the 1.25.73-1.30.1 branch) or 1.31.71 (for the 1.31.1-1.31.70 branch) of both org.verapdf:validation-model and org.verapdf:validation-model-jakarta, per advisory https://github.com/veraPDF/veraPDF-validation/security/advisories/GHSA-3jh7-wm29-q568. The fix hardens DocumentBuilderFactory in DictionaryKeysHelper.java to disallow DOCTYPE declarations outright following the OWASP XXE Prevention Cheat Sheet. If you cannot upgrade immediately, compensating controls are to stop validating untrusted PDFs on any host with sensitive files or internal network reachability, and to apply egress network filtering (block outbound file access is not applicable, but block the validation host's outbound HTTP/HTTPS and to internal ranges) so that even a successful DOCTYPE parse cannot reach internal services or exfiltrate via SSRF - the trade-off being that legitimate remote resource fetches during validation, if any, would also be blocked. Running the validator as an unprivileged, sandboxed/containerized user with a minimal filesystem view limits which files an XXE can read.