veraPDF versions 1.25.73 through 1.30.2 and 1.31.71 contain an XXE vulnerability in their XML parsing implementation. The library uses default DocumentBuilderFactory settings when processing embedded XML in PDF files — specifically in XFA configurations, AcroForm fields, and rich-text annotations — which permits external entity resolution. A malicious PDF containing crafted XML can trigger outbound HTTP requests or file disclosure to attacker-controlled servers.
This is not a niche vulnerability. XXE in Java XML parsing is among the most well-documented attack classes in the ecosystem, with a decade of CVEs demonstrating the exact pattern. The veraPDF case exposes a systematic blind spot: a validation tool explicitly designed to process untrusted files inherited default parser behavior rather than explicitly hardening it. The developers were focused on PDF/A compliance; the XML processing code was ambient infrastructure that never received security scrutiny.
The downstream risk is architectural. Organizations running veraPDF in automated ingestion pipelines — compliance checkpoints, archival systems, document processing workflows — likely treated the library as a trust boundary without auditing its own dependencies or configuration. A validation library that can be weaponized as an exfiltration oracle fundamentally inverts your security posture: the outermost layer is the most fragile.
Fix this by explicitly disabling DOCTYPE and external entities in any DocumentBuilderFactory used to parse XML from PDF inputs. Upgrade to 1.30.3 or later. Beyond patching, audit your document processing supply chain: verify that any library handling untrusted XML — not just PDF validators but any tool parsing embedded markup — explicitly hardens parser configurations rather than relying on defaults. This is a class vulnerability across the document processing ecosystem, not an isolated failure.