Org.hl7.fhir.core
by Hapifhir
Source repositories
CVEs (5)
| CVE | Sev | Risk | CVSS | EPSS | KEV | Published | Description |
|---|---|---|---|---|---|---|---|
| CVE-2024-51132 | Cri | 0.57 | 9.8 | 0.08 | Nov 5, 2024 | An XML External Entity (XXE) vulnerability in HAPI FHIR before v6.4.0 allows attackers to access sensitive information or execute arbitrary code via supplying a crafted request containing malicious XML entities. | |
| CVE-2026-33180 | Hig | 0.49 | 7.5 | 0.00 | Mar 20, 2026 | HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.0, when setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value. Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the client's request. This issue has been patched in release 6.9.0. No known workarounds are available. | |
| CVE-2024-52007 | Hig | 0.49 | 8.6 | 0.00 | Nov 8, 2024 | HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. XSLT parsing performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( <!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]> could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. This is related to GHSA-6cr6-ph3p-f5rf, in which its fix (#1571 & #1717) was incomplete. This issue has been addressed in release version 6.4.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability. | |
| CVE-2024-45294 | Hig | 0.49 | 8.6 | 0.00 | Sep 6, 2024 | The HL7 FHIR Core Artifacts repository provides the java core object handling code, with utilities (including validator), for the Fast Healthcare Interoperability Resources (FHIR) specification. Prior to version 6.3.23, XSLT transforms performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. This issue has been patched in release 6.3.23. No known workarounds are available. | |
| CVE-2026-45367 | hig | 0.45 | — | — | May 18, 2026 | ## Summary All implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation. The FHIRPath functions `matches()`, `matchesFull()`, and `replaceMatches()` pass user-controlled regular expressions directly to Java's `Pattern.compile()` and `String.replaceAll()` without complexity checks or timeouts. An attacker can send a resource containing an evil regex pattern that causes catastrophic backtracking, exhausting system resources, and causing Denial-of-Service. ## Details The vulnerability exists in regex execution in FHIRPathEngine implementations across multiple code modules. For example the org.hl7.fhir.r5 module: **Entry point 1 — `FHIRPathEngine.java:5929` (R5 `funcMatches`):** ```java private List<Base> funcMatches(ExecutionContext context, List<Base> focus, ExpressionNode exp) { String sw = convertToString(swb); // attacker-controlled regex pattern // ... Pattern p = Pattern.compile("(?s)" + sw); // VULNERABLE: no complexity check Matcher m = p.matcher(st); // no timeout boolean ok = m.find(); ``` **Entry point 2 — `FHIRPathEngine.java:5951` (R5 `funcMatchesFull`):** ```java Pattern p = Pattern.compile("(?s)" + sw); // VULNERABLE: same pattern Matcher m = p.matcher(st); boolean ok = m.matches(); ``` **Entry point 3 — `FHIRPathEngine.java:5120` (R5 `funcReplaceMatches`):** ```java result.add(new StringType(convertToString(focus.get(0)) .replaceAll(regex, repl)).noExtensions()); // VULNERABLE: replaceAll uses Pattern internally ``` The same vulnerabilities exist in the dstu2, dstu2016may, dstu3, r4, and r4b modules, and the FHIRPathEngine is used in the validation module functionality. **Why this is exploitable:** - No timeout mechanism covers FHIRPath evaluation — the `ValidationTimeout` class only protects `InstanceValidator` operations, not `evaluateFhirPath()` - Java's `Pattern.compile()` with a pattern like `(a+)+$` against input `"aaaaaaaaaaaaaaaaaaaaaa!"` causes exponential backtracking (O(2^n) time complexity) ## Impact - **CPU Exhaustion:** The exponential backtracking in Java's regex engine consumes 100% of a CPU core for the duration of the hang (effectively infinite for sufficiently long input strings) for callers of FHIRPathEngine. |
- risk 0.57cvss 9.8epss 0.08
An XML External Entity (XXE) vulnerability in HAPI FHIR before v6.4.0 allows attackers to access sensitive information or execute arbitrary code via supplying a crafted request containing malicious XML entities.
- risk 0.49cvss 7.5epss 0.00
HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.0, when setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value. Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the client's request. This issue has been patched in release 6.9.0. No known workarounds are available.
- risk 0.49cvss 8.6epss 0.00
HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. XSLT parsing performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( <!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]> could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. This is related to GHSA-6cr6-ph3p-f5rf, in which its fix (#1571 & #1717) was incomplete. This issue has been addressed in release version 6.4.0 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
- risk 0.49cvss 8.6epss 0.00
The HL7 FHIR Core Artifacts repository provides the java core object handling code, with utilities (including validator), for the Fast Healthcare Interoperability Resources (FHIR) specification. Prior to version 6.3.23, XSLT transforms performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. This issue has been patched in release 6.3.23. No known workarounds are available.
- risk 0.45cvss —epss —
## Summary All implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation. The FHIRPath functions `matches()`, `matchesFull()`, and `replaceMatches()` pass user-controlled regular expressions directly to Java's `Pattern.compile()` and `String.replaceAll()` without complexity checks or timeouts. An attacker can send a resource containing an evil regex pattern that causes catastrophic backtracking, exhausting system resources, and causing Denial-of-Service. ## Details The vulnerability exists in regex execution in FHIRPathEngine implementations across multiple code modules. For example the org.hl7.fhir.r5 module: **Entry point 1 — `FHIRPathEngine.java:5929` (R5 `funcMatches`):** ```java private List<Base> funcMatches(ExecutionContext context, List<Base> focus, ExpressionNode exp) { String sw = convertToString(swb); // attacker-controlled regex pattern // ... Pattern p = Pattern.compile("(?s)" + sw); // VULNERABLE: no complexity check Matcher m = p.matcher(st); // no timeout boolean ok = m.find(); ``` **Entry point 2 — `FHIRPathEngine.java:5951` (R5 `funcMatchesFull`):** ```java Pattern p = Pattern.compile("(?s)" + sw); // VULNERABLE: same pattern Matcher m = p.matcher(st); boolean ok = m.matches(); ``` **Entry point 3 — `FHIRPathEngine.java:5120` (R5 `funcReplaceMatches`):** ```java result.add(new StringType(convertToString(focus.get(0)) .replaceAll(regex, repl)).noExtensions()); // VULNERABLE: replaceAll uses Pattern internally ``` The same vulnerabilities exist in the dstu2, dstu2016may, dstu3, r4, and r4b modules, and the FHIRPathEngine is used in the validation module functionality. **Why this is exploitable:** - No timeout mechanism covers FHIRPath evaluation — the `ValidationTimeout` class only protects `InstanceValidator` operations, not `evaluateFhirPath()` - Java's `Pattern.compile()` with a pattern like `(a+)+$` against input `"aaaaaaaaaaaaaaaaaaaaaa!"` causes exponential backtracking (O(2^n) time complexity) ## Impact - **CPU Exhaustion:** The exponential backtracking in Java's regex engine consumes 100% of a CPU core for the duration of the hang (effectively infinite for sufficiently long input strings) for callers of FHIRPathEngine.