org.hl7.fhir.core: Inefficient Regular Expression Complexity
CVE-2026-45367 is a high-severity inefficient regular expression complexity vulnerability in org.hl7.fhir.core from Hapifhir, with a CVSS 3.1 base score of 7.5 out of 10. It can be exploited remotely over the network by an unauthenticated attacker, without any action from a user. Affected org.hl7.fhir.core versions: < 6.9.7. The record does not name a fixed version, so check the vendor advisory. There is no confirmed exploitation so far. EPSS estimates a 0.68% chance of exploitation within 30 days, higher than 53% of scored CVEs.
High severity with no evidence of exploitation so far.
What to do
- Check which version of org.hl7.fhir.core you run against the affected versions below, and install the vendor's latest release.
- Read the advisory on github.com for workarounds and exact fixed builds.
- Until you can update, restrict network access to the affected service so it is not reachable from untrusted networks.
Affected products and versions
| Vendor | Product | Affected versions | Fixed in |
|---|---|---|---|
| Hapifhir | org.hl7.fhir.core | < 6.9.7 | Not stated |
Version data comes from the organisation that assigned the CVE. Confirm against the vendor advisory before deciding you are unaffected.
How the severity score breaks down
- Attack vector
- NetworkCan be exploited remotely over a network, including the internet.
- Attack complexity
- LowNo special conditions are needed; the attack works reliably.
- Privileges required
- NoneNo account or login is needed.
- User interaction
- NoneNo action by a victim is required.
- Scope
- UnchangedImpact stays within the vulnerable component.
- Confidentiality
- NoneNo data is disclosed.
- Integrity
- NoneNothing can be modified.
- Availability
- HighThe component can be taken down completely.
Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. Scored by CNA (github.com).
Official description
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.
Source: the CVE record as published by its numbering authority, via NVD and CVE.org.
The underlying weakness: Inefficient Regular Expression Complexity
The product uses a regular expression with a worst-case computational complexity that is inefficient and possibly exponential.
How developers prevent this class of flaw
- Use regular expressions that do not support backtracking, e.g. by removing nested quantifiers.
- Set backtracking limits in the configuration of the regular expression implementation, such as PHP's pcre.backtrack_limit. Also consider limits on execution time for the process.
- Do not use regular expressions with untrusted input. If regular expressions must be used, avoid using backtracking in the expression.
More Inefficient Regular Expression Complexity vulnerabilities (CWE-1333)
Timeline
- CVE record published.
- CISA published its SSVC assessment (exploitation: none, automatable: yes, technical impact: partial).
- Record last changed materially (score, affected products, status or references).
References
Patches and release notes
- github.com/hapifhir/org.hl7.fhir.core/commit/275d015c680ce9f90cbe285596e50118e472bf24
- github.com/hapifhir/org.hl7.fhir.core/commit/e08982d2b6f6dcd6c670a762d9cf999179fbe4ed
- github.com/hapifhir/org.hl7.fhir.core/pull/2403
- github.com/hapifhir/org.hl7.fhir.core/pull/2463
- github.com/hapifhir/org.hl7.fhir.core/releases/tag/6.9.7
Other vulnerabilities in org.hl7.fhir.core
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
- 9.1 Critical severity
Recent Inefficient Regular Expression Complexity vulnerabilities
- 7.5 High severity
- 7.5 High severity
- 8.7 High severity
- 7.5 High severity
- 7.5 High severity
- 7.5 High severity
Spotted an error? Tell us.