Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
All implementations of FHIRPathEngine accept arbitrary FHIRPath expressions and evaluate them without input validation. The utility intended to secure this evaluation did so incorrectly, and did not fully cover all places in which evaluation was being done. 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. The FHIRPath functions matches(), matchesFull(), and replaceMatches() pass user-controlled regular expressions to Java's Pattern.compile() and String.replaceAll() through a utility class designed to time out after a specified interval. That utility correctly cancelled a single executor thread and returned with an exception, but the execution within the thread had no means to listen for this cancellation and would persist. Furthermore, three modules…
Recommended action: Upgrade to 6.9.9 or 6.9.4.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The fix for CVE-2026-45367 added RegexTimeout protection to the matches() function in DSTU2016MAY, DSTU3, R4, R4B, and R5, but the DSTU2 module was incompletely patched. In org.hl7.fhir.dstu2, replaceMatches() was updated while matches() at line 2462 still calls the raw String.matches(sw) without any timeout, allowing an unauthenticated attacker to trigger catastrophic regex backtracking and exhaust server CPU. Details Incomplete patch Within the same file (org.hl7.fhir.dstu2/utils/FHIRPathEngine.java), the two functions were patched inconsistently: Line 2226 — replaceMatches() — PATCHED: Line 2462 — matches() — NOT PATCHED: DSTU3 line 2447 — matches() — PATCHED (for comparison): Module-by-module status | Module | matches() | replaceMatches() | |---|---|---| | DSTU2 | ❌ raw str.matches(sw) | ✅ RegexTimeout.replaceAll() | | DSTU2016MAY | ✅ RegexTimeout.matches() | ✅ | | DSTU3 | ✅ RegexTimeout.matches() | ✅ | | R4 | ✅ RegexTimeout.matches() | ✅ | | R4B | ✅…
Recommended action: Upgrade to 6.9.10 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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): Entry point 2 — FHIRPathEngine.java:5951 (R5 funcMatchesFull): Entry point 3 — FHIRPathEngine.java:5120 (R5 funcReplaceMatches): The same vulnerabilities exist in the dstu2, dstu2016may, dstu3, r4, and r4b modules, and the FHIRPathEngine is used in the validation module…
Recommended action: Upgrade to 6.9.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact When setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value. Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the client's request. Patches This issue has been patched in release 6.8.3 Workarounds None.
Recommended action: Upgrade to 6.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
An XML External Entity (XXE) vulnerability in HAPI FHIR before v6.4.0 allows attackers to access sensitive information or execute arbitrary code via supplying a crafted request containing malicious XML entities.
Recommended action: Upgrade to 6.4.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.