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):** ``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.