XXE via Unprotected Saxon TransformerFactory in HAPI FHIR XsltUtilities
HAPI FHIR's saxonTransform() methods instantiate bare Saxon TransformerFactory instances without XXE protections, enabling XML External Entity injection for file disclosure and SSRF attacks. This bypasses the library's own hardened factory pattern documented in XMLUtil.
CVE References
Affected
Vulnerability Description
The vulnerability is a classic XML External Entity (XXE) injection flaw arising from inconsistent factory hardening. The XsltUtilities class exposes two parallel XSLT transformation APIs: transform(...) methods correctly use XMLUtil.newXXEProtectedTransformerFactory() (which disables ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET), while saxonTransform(...) overloads instantiate unprotected net.sf.saxon.TransformerFactoryImpl() directly. This violates the library's own documented design contract. The root cause is a copy-paste or oversight during development—the protected factory exists and is used elsewhere but was bypassed in these three method overloads (lines 61, 91, 106).
Impact and PoC Significance
An attacker who controls or can intercept XML documents passed to saxonTransform() can inject XXE payloads to (1) disclose local files readable by the application process, (2) trigger blind XXE or SSRF attacks against internal/external URLs, and (3) potentially enable DoS via billion laughs or XML bombs (depending on Saxon's streaming configuration). The PoC matters defensively because it proves the vulnerability exists in the wild codebase and has been verified on version 6.9.8 (the latest at report time). The exposure is at the library boundary—any FHIR processing tool using this library is potentially affected if it processes untrusted XML or accepts XSLT transformations from untrusted sources.
Detection Guidance
Code-level detection: Grep for new net.sf.saxon.TransformerFactoryImpl() or saxonTransform calls in FHIR processing code paths. Runtime detection: Monitor for XXE-pattern XML in logs (DOCTYPE declarations, ENTITY definitions, file:// or http(s):// schemes in XML attributes). WAF/IDS signatures: Alert on POST/PUT bodies containing <!DOCTYPE, <!ENTITY, or external schema references targeting XsltUtilities endpoints. Dependency scanning: Automated tooling (OWASP Dependency-Check, Snyk) will flag ca.uhn.hapi.fhir:org.hl7.fhir.utilities:* versions ≤ 6.9.8. Log indicators: Stack traces mentioning XsltUtilities.saxonTransform paired with XML parsing exceptions or unusual file access patterns.
Mitigation Steps
Immediate: Upgrade to a patched version once released (monitor the advisory link for fixes). Interim mitigation (if upgrade blocked): (1) Avoid calling saxonTransform() methods directly; use the transform() overloads instead if functionality permits. (2) Implement input validation: reject XML documents containing DOCTYPE or ENTITY declarations before passing to XSLT processing. (3) Sandbox FHIR transformation services with network policies restricting outbound access; disable file:// URI schemes at the OS/filesystem level. (4) Apply Web Application Firewall rules to detect and block XXE payloads at entry points. (5) Review call sites for saxonTransform()—if not essential, refactor to use protected APIs.
Risk Assessment
Likelihood: Moderate to high for exploitation in the wild. FHIR/healthcare systems often process documents from multiple sources (EHR uploads, HL7 exchanges, third-party integrations), creating realistic XXE attack surfaces. Automated scanning tools will quickly identify vulnerable deployments. Threat actor interest: Healthcare and supply-chain targeting groups have historically exploited XXE for data exfiltration; this is a high-value target. Prevalence: The vulnerability exists in a widely-used library (HAPI FHIR is de facto standard in Java FHIR ecosystems), so exposure is likely broad across healthcare IT infrastructure. Organizations running FHIR services should prioritize patching post-release.
Sources