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.