What is the CVSS score of CVE-2026-45367?

CVE-2026-45367 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. EPSS exploitation probability: 0.1%.

Which versions of HAPI FHIR Core are affected by CVE-2026-45367?

HAPI FHIR versions 6.9.6 and below contain a regular expression denial-of-service vulnerability in FHIRPathEngine; publicly available exploit code exists.. A patch is available.

How to fix or mitigate CVE-2026-45367?

Within 24 hours: Identify and inventory all systems running org.hl7.fhir.* artifacts at version 6.9.6 or earlier and assess direct internet exposure. Within 7 days: Deploy input validation to reject FHIRPath expressions with catastrophic backtracking patterns and implement request rate-limiting on FHIR query endpoints. Within 30 days: Monitor vendor advisories for patch availability; upon release, conduct regression testing and schedule controlled upgrade.

HAPI FHIR Core CVE-2026-45367

HIGH

Inefficient Regular Expression Complexity (ReDoS) (CWE-1333)

2026-05-18 https://github.com/hapifhir/org.hl7.fhir.core

GHSA-3653-68v6-rq57

Denial Of Service Java

7.5

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

7.5 HIGH

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Attack Vector

Network

Attack Complexity

Low

Privileges Required

None

User Interaction

None

Scope

Unchanged

Confidentiality

None

Integrity

None

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

May 18, 2026 - 21:08 vuln.today

Analysis Generated

May 18, 2026 - 21:08 vuln.today

Blast Radius

ecosystem impact

† from your stack dependencies † transitive graph · vuln.today resolves 4-path depth

5 maven packages depend on ca.uhn.hapi.fhir:org.hl7.fhir.dstu2 (2 direct, 3 indirect)
5 maven packages depend on ca.uhn.hapi.fhir:org.hl7.fhir.dstu2016may (2 direct, 3 indirect)
6 maven packages depend on ca.uhn.hapi.fhir:org.hl7.fhir.dstu3 (3 direct, 3 indirect)
10 maven packages depend on ca.uhn.hapi.fhir:org.hl7.fhir.r4 (2 direct, 8 indirect)
5 maven packages depend on ca.uhn.hapi.fhir:org.hl7.fhir.r4b (1 direct, 4 indirect)

Ecosystem-wide dependent count for version 6.9.7 and other introduced versions.

DescriptionGitHub Advisory

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.

AnalysisAI

Regular expression denial-of-service (ReDoS) in HAPI FHIR's FHIRPathEngine allows remote unauthenticated attackers to exhaust CPU resources by submitting FHIR resources containing crafted FHIRPath expressions that invoke matches(), matchesFull(), or replaceMatches() with catastrophically backtracking regex patterns. Affected versions are org.hl7.fhir.* Maven artifacts at or below 6.9.6, with publicly available exploit code exists via the GitHub Security Advisory PoC (pattern (a+)+$ against a long string). CVSS 7.5 reflects high availability impact with no confidentiality or integrity loss; no public exploit identified in the wild and no CISA KEV listing.

Technical ContextAI

HAPI FHIR is the reference Java implementation of the HL7 FHIR (Fast Healthcare Interoperability Resources) standard maintained by University Health Network, widely embedded in healthcare integration platforms, EHR back-ends, and FHIR validation services. The flaw resides in FHIRPathEngine, the evaluator for FHIRPath - a path-based navigation and extraction language used throughout FHIR for queries, validation invariants, and search parameters. The three vulnerable sinks (funcMatches at FHIRPathEngine.java:5929, funcMatchesFull at :5951, funcReplaceMatches at :5120) concatenate attacker-controlled strings into java.util.regex.Pattern.compile() and String.replaceAll() with no length, complexity, or execution-time guardrails. This is a textbook CWE-1333 (Inefficient Regular Expression Complexity): nested quantifiers like (a+)+$ trigger exponential backtracking in Java's NFA-based regex engine. The pre-existing ValidationTimeout safety net wraps InstanceValidator but does not cover evaluateFhirPath(), leaving every caller of the engine exposed. All FHIR version modules (dstu2, dstu2016may, dstu3, r4, r4b, r5, validation, validation.cli) share the defect.

RemediationAI

Vendor-released patch: upgrade all org.hl7.fhir.* Maven dependencies to version 6.9.7 or later as documented in GHSA-3653-68v6-rq57 (https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-3653-68v6-rq57). For environments that cannot patch immediately, compensating controls include disabling or restricting the FHIR Validator HTTP endpoint to authenticated, trusted clients only; rejecting incoming FHIR resources that contain FHIRPath expressions invoking matches(), matchesFull(), or replaceMatches() via a reverse-proxy WAF rule; capping request body size and per-request CPU time at an upstream gateway (note this may legitimately reject large valid bundles); and running validator workers in cgroup-limited containers so a hung worker can be reaped without taking down the host. None of these workarounds fully eliminate exploitability because FHIRPath is also evaluated implicitly during resource validation invariants, so upgrading is strongly preferred.