HAPI FHIR: ReDoS via FHIRPath matches()/replaceMatches() in FHIR Validator HTTP Endpoint

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.