CVE-2026-54079High▾ TwilightveraPDF Validation XXE via XFA
▾ Twilight zone — High severity, or a signal on a lesser flaw
impact 41.3 · likelihood 0.1 · exploitation 0
Need a working PoC? Pro members can cast a request and our team develops one — it lands right here.
Exploit-prediction probability, daily snapshots since Jul 30.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
0.3%
0.3% → 0.6%
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.
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:
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.builder.parse() is the decoded /XFA stream taken directly from the untrusted PDF.<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.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.
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.
org.verapdf:validation-model >= 1.17.35, <= 1.30.1org.verapdf:validation-model >= 1.31.1, <= 1.31.70org.verapdf:validation-model-jakarta >= 1.17.35, <= 1.30.1org.verapdf:validation-model-jakarta >= 1.31.1, <= 1.31.70Upgrade to a patched release:
org.verapdf:validation-model 1.30.2org.verapdf:validation-model 1.31.71org.verapdf:validation-model-jakarta 1.30.2org.verapdf:validation-model-jakarta 1.31.71Connected by shared product, vendor, weakness, or advisory.
CVE-2026-54082Medium· 6.5veraPDF-validatio: Use of Default `DocumentBuilderFactory` leads to XXE When Processing Untrusted PDFs
CVE-2026-54078HighveraPDF Validation XXE via Rich Text
CVE-2025-10816High· 7.3A security flaw has been discovered in Jinher OA 2.0
CVE-2025-11341High· 7.3A security flaw has been discovered in Jinher OA up to 2.0
CVE-2025-11035Medium· 6.3A vulnerability was determined in Jinher OA 2.0
CVE-2025-11140High· 7.3A vulnerability was identified in Bjskzy Zhiyou ERP up to 11.0