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.
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.
XSLT parsing performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( <!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd" ] could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. Details This is related to https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-6cr6-ph3p-f5rf, in which its fix ( https://github.com/hapifhir/org.hl7.fhir.core/issues/1571, https://github.com/hapifhir/org.hl7.fhir.core/pull/1717) was incomplete. References https://cwe.mitre.org/data/definitions/611.html https://cheatsheetseries.owasp.org/cheatsheets/XMLExternalEntityPreventionCheatSheet.html#jaxp-documentbuilderfactory-saxparserfactory-and-dom4j
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.
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 XSLT transforms performed by various components are vulnerable to XML external entity injections. A processed XML file with a malicious DTD tag ( <!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd" ] could produce XML containing data from the host system. This impacts use cases where org.hl7.fhir.core is being used to within a host where external clients can submit XML. Patches This issue has been patched in release 6.3.23 Workarounds None. References MITRE CWE OWASP XML External Entity Prevention Cheat Sheet
Recommended action: Upgrade to 6.3.23 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.