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

veraPDF-validation (a PDF validation tool) contains arbitrary file read and SSRF vulnerabilities that allow remote attackers to exfiltrate sensitive server files or access internal systems by…. A patch is available.

How to fix or mitigate CVE-2026-54079?

Within 24 hours, identify all systems running veraPDF-validation or validation-model-jakarta and prioritize those processing PDFs from external sources. Within 7 days, apply the patch available per vendor advisory GHSA-36mm-w85j-3q2j and verify functionality in non-production environments first. Within 30 days, audit PDF processing workflows for logs of suspicious validation requests and implement network segmentation to restrict outbound connections from PDF validation systems to reduce SSRF impact.

veraPDF CVE-2026-54079

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

CVE-2026-54079 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-50368 HIGH

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

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

GHSA-36mm-w85j-3q2j

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

Attacker-supplied PDF processed automatically over a network-facing validation service gives AV:N/AC:L/PR:N/UI:N; arbitrary file read yields C:H, with no integrity or availability impact (AV:N assumes server-side exposure).

3.1 AV:N/AC:L/PR:N/UI:N/S:U/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

Source Code Evidence Fetched

Jul 29, 2026 - 15:31 vuln.today

Analysis Generated

Jul 29, 2026 - 15:31 vuln.today

CVE Published

Jul 29, 2026 - 15:08 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 XFA stream. This affects all current versions of veraPDF-validation.

Details

The vulnerability resides in veraPDF-validation validation-model/src/main/java/org/verapdf/gf/model/impl/pd/GFPDAcroForm.java within the getdynamicRender() method. This method retrieves the /XFA entry from the PDF's /AcroForm dictionary, decodes the embedded XML stream, and parses it to extract the <dynamicRender> element value.

The vulnerability stems from the use of a default-configured DocumentBuilderFactory to parse fully attacker-controlled XML:

The factory is created via DocumentBuilderFactory.newInstance() with no security features enabled. disallow-doctype-decl, external-general-entities, external-parameter-entities, and FEATURE_SECURE_PROCESSING are all left at their insecure defaults.
The input passed to builder.parse() is the decoded /XFA stream taken directly from the untrusted PDF.
The text content of the <dynamicRender> node is returned to the validation model. Note that the shipped PDF/UA-1 rule (dynamicRender != 'required') consumes this value but does not echo it into the report output, so reliable exfiltration requires the out-of-band parameter-entity technique described under Impact rather than in-band reflection.

Impact

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

Successful exploitation requires only that the target validate an attacker-supplied PDF against the PDF/UA-1 profile (or via flavour auto-detection on a PDF that declares PDF/UA-1 conformance), since getdynamicRender() is invoked by the dynamicRender != 'required' rule in the bundled PDF/UA-1 profile. No additional configuration or operator action is required.

Proposed Patch

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

AnalysisAI

Arbitrary file read and Server-Side Request Forgery in veraPDF-validation (and the validation-model-jakarta variant) let a remote attacker exfiltrate server files or reach internal services by submitting a crafted PDF whose XFA stream carries a malicious XML DOCTYPE. The insecure XML parser is reached automatically whenever a PDF is validated against the PDF/UA-1 profile, including via flavour auto-detection, so no operator action beyond normal validation is needed. There is no public exploit identified at time of analysis and it is not listed in CISA KEV, but the vendor advisory (GHSA-36mm-w85j-3q2j) and a fixing patch are confirmed.

Technical ContextAI

veraPDF is the open-source reference validator for PDF/A and PDF/UA archival conformance profiles. The flaw is a classic CWE-611 XML External Entity Injection in GFPDAcroForm.getdynamicRender(), which pulls the /XFA (XML Forms Architecture) stream from a PDF's /AcroForm dictionary and parses it with a DocumentBuilderFactory.newInstance() that leaves disallow-doctype-decl, external-general-entities, external-parameter-entities, and FEATURE_SECURE_PROCESSING at their insecure Java defaults. Because the parser processes fully attacker-controlled XML, DOCTYPE declarations and external/parameter entities are resolved, enabling local file disclosure and outbound requests. The same unsafe pattern also existed in DictionaryKeysHelper.getRichTextStringOrStreamEntryStringRepresentation(), which the patch hardens as well. Affected Maven coordinates are org.verapdf:validation-model and org.verapdf:validation-model-jakarta.

RemediationAI

Vendor-released patch: upgrade org.verapdf:validation-model (or validation-model-jakarta) to 1.30.2 if on the 1.x-1.30 line, or to 1.31.71 if on the 1.31.x line, per advisory GHSA-36mm-w85j-3q2j (https://github.com/veraPDF/veraPDF-validation/security/advisories/GHSA-36mm-w85j-3q2j) and PR https://github.com/veraPDF/veraPDF-validation/pull/730 (commits 94caa46 and cacd943), which replace the insecure DocumentBuilderFactory with SecureXML.newSafeDocumentBuilder(). If you cannot upgrade immediately, the most direct compensating control is to avoid validating untrusted PDFs against the PDF/UA-1 profile and to disable flavour auto-detection so a hostile PDF cannot silently select PDF/UA-1 - the trade-off is loss of PDF/UA-1 conformance checking for those jobs. Additionally, run the validator with strict egress filtering (block outbound network from the validation host to neutralize the SSRF and out-of-band exfiltration channel) and with a least-privilege filesystem account so arbitrary file reads yield minimal sensitive data; the side effect is that legitimate outbound calls from the process will also break. Do not rely on these workarounds long-term - patching is the definitive fix.