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.
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.
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.
Impact Zip Slip protections implemented in CVE-2023-24057 (GHSA-jqh6-9574-5x22) can be bypassed due a partial path traversal vulnerability. This issue allows a malicious actor to potentially break out of the TerminologyCacheManager cache directory. The impact is limited to sibling directories. To demonstrate the vulnerability, consider userControlled.getCanonicalPath().startsWith("/usr/out") will allow an attacker to access a directory with a name like /usr/outnot. Why? To demonstrate this vulnerability, consider "/usr/outnot".startsWith("/usr/out"). The check is bypassed although /outnot is not under the /out directory. It's important to understand that the terminating slash may be removed when using various String representations of the File object. For example, on Linux, println(new File("/var")) will print /var, but println(new File("/var", "/") will print /var/; however, println(new File("/var", "/").getCanonicalPath()) will print /var. The Fix Comparing paths with the…
Recommended action: Upgrade to 5.6.106 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact MITM can enable Zip-Slip. Vulnerability Vulnerability 1: Scanner.java There is no validation that the zip file being unpacked has entries that are not maliciously writing outside of the intended destination directory. https://github.com/hapifhir/org.hl7.fhir.core/blob/8c43e21094af971303131efd081503e5a112db4b/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java#L335-L357 This zip archive is downloaded over HTTP instead of HTTPS, leaving it vulnerable to compromise in-flight. https://github.com/hapifhir/org.hl7.fhir.core/blob/8c43e21094af971303131efd081503e5a112db4b/org.hl7.fhir.validation/src/main/java/org/hl7/fhir/validation/Scanner.java#L136 Vulnerability 2: TerminologyCacheManager.java Note: While these links point to only one implementation, both implementations of TerminologyCacheManager.java are vulnerable to this as their code seems to be duplicated. -…
Recommended action: Upgrade to 5.6.92 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.