CVE-2026-45367

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.7, the FHIRPathEngine implementation passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service. This issue is fixed in version 6.9.7.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.7, the FHIRPathEngine implementation passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service. This issue is fixed in version 6.9.7.

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):

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):

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):

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.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.7, the FHIRPathEngine implementation passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service. This issue is fixed in version 6.9.7.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.7, the FHIRPathEngine implementation passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service. This issue is fixed in version 6.9.7.

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):

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):

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):

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.

Root has patched CVE-2026-45367 in the ca.uhn.hapi.fhir:org.hl7.fhir.validation package for Root:Maven. Multiple fixed versions available.