CVE-2026-62296

A vulnerability in HAPI FHIR before version 6.9.10 allows XML External Entity (XXE) injection via the saxonTransform function in XsltUtilities. Missing ACCESS_EXTERNAL_DTD and ACCESS_EXTERNAL_STYLESHEET restrictions enable an attacker to read local files, perform blind XXE, and SSRF to arbitrary URLs.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, the FHIR Validator HTTP service exposes an unauthenticated "/loadIG" endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL. This issue has been patched in version 6.9.4.

Prior to 6.9.11, the JSON utility parser in org.hl7.fhir.utilities.json.parser.JsonParser enforces no maximum nesting depth for arrays or objects. As a result, a small but deeply nested, syntactically valid FHIR JSON document can trigger unbounded readArray() or readObject() recursion, raising a StackOverflowError before structural validation runs. An attacker who can submit JSON resources for validation can thus crash the request thread, and services that do not isolate StackOverflowError safely may experience worker loss or process instability — a denial-of-service condition. This issue is fixed in version 6.9.11.

HAPI FHIR prior to 6.9.11 contains a stored cross-site scripting vulnerability in the hidden scan command, which concatenates attacker-controlled titles and source references without escaping in Scanner.java. A user scanning a malicious IG/profile and opening the generated HTML report can trigger stored XSS, executing attacker-controlled JavaScript in the report's browser context.

HAPI FHIR prior to versions 6.9.9 and 6.9.4.2 accepts arbitrary FHIRPath expressions without input validation. The functions matches(), matchesFull(), and replaceMatches() pass user-controlled regular expressions to Pattern.compile() and String.replaceAll() through an incomplete timeout utility. An attacker can send a resource with a malicious regex pattern causing catastrophic backtracking, exhausting CPU resources and causing denial of service.

In HAPI FHIR before version 6.9.7, the FHIRPathEngine passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service (DoS).

The vulnerability in HAPI FHIR before version 6.9.10 stems from an incomplete patch for CVE-2026-45367 in the DSTU2 module. The FHIRPathEngine.matches() method calls String.matches(sw) without RegexTimeout protection, allowing an unauthenticated attacker to trigger catastrophic regex backtracking and exhaust server CPU.

HAPI FHIR prior to version 6.9.4 has a /loadIG HTTP endpoint in the FHIR Validator HTTP service that accepts a user-supplied URL via JSON body and makes server-side HTTP requests without hostname, scheme, or domain validation. An unauthenticated attacker with network access can probe internal network services, cloud metadata endpoints, and map network topology through error-based information leakage.

In HAPI FHIR before version 6.9.4, ManagedWebAccessUtils.getServer() uses String.startsWith() to match request URLs against configured server URLs for credential dispatch. Without a trailing slash or host boundary check, an attacker-controlled domain like http://tx.fhir.org.attacker.com matches the prefix and receives Bearer tokens, Basic auth credentials, or API keys when the HTTP client follows a redirect.

HAPI FHIR before version 6.9.0 sends the same HTTP headers to all hosts during redirects, potentially leaking sensitive data or allowing request impersonation.