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
9 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
A malformed Smart Health Card (SHC) JWT with zip: "DEF" and an empty or truncated DEFLATE payload causes SHCParser.inflate() to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service. Details The vulnerable code is in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java. decodeJWT() inflates the JWT payload when the header contains "zip":"DEF": inflate() loops only on !inflater.finished() and does not check inflater.needsInput(), inflater.needsDictionary(), or zero-progress output: For empty or truncated raw DEFLATE input, Inflater.inflate() returns 0, finished() remains false, and needsInput() becomes true, producing an infinite tight loop. The same unsafe loop pattern also exists in decompress() at SHCParser.java:410-423. The validator reaches this path during SHC validation and during file-format detection for SHC-looking input (ResourceChecker.java:115-118).…
Recommended action: Upgrade to 6.9.12 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 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.
The FHIR Validator HTTP service exposes an unauthenticated /loadIG endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL. Details Step 1 — SSRF Entry Point (LoadIGHTTPHandler.java:35-43): The /loadIG endpoint accepts unauthenticated POST requests with a JSON body containing an ig field. The value is passed directly to IgLoader.loadIg() with no URL validation or allowlisting. When the value is an HTTP(S) URL, IgLoader.fetchFromUrlSpecific() makes an outbound GET request via ManagedWebAccess.get(): Step 2 — Credential Leak via Prefix Matching (ManagedWebAccessUtils.java:14): When ManagedWebAccess creates a SimpleHTTPClient, it attaches an authProvider that uses…
Recommended action: Upgrade to 6.9.4 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.