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
8 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
org.hl7.fhir.utilities.XsltUtilities exposes two parallel families of XSLT transform helpers. The transform(...) overloads obtain their TransformerFactory from the project's hardened helper XMLUtil.newXXEProtectedTransformerFactory() (which sets ACCESSEXTERNALDTD="" and ACCESSEXTERNALSTYLESHEET=""). The sibling saxonTransform(...) overloads instead instantiate a bare new net.sf.saxon.TransformerFactoryImpl() with no external-access restriction. A document transformed through any saxonTransform(...) overload is parsed with external general entities and external DTD/parameter entities enabled, so an attacker who controls (or can MITM) the transformed XML obtains XML External Entity injection: local file disclosure and blind XXE / SSRF to arbitrary URLs reachable from the host. XMLUtil documents that its protected factory "should be the only place where TransformerFactory is instantiated in this project". The saxonTransform overloads violate that contract while their same-file…
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.
ManagedWebAccessUtils.getServer() uses String.startsWith() to match request URLs against configured server URLs for authentication credential dispatch. Because configured server URLs (e.g., http://tx.fhir.org) lack a trailing slash or host boundary check, an attacker-controlled domain like http://tx.fhir.org.attacker.com matches the prefix and receives Bearer tokens, Basic auth credentials, or API keys when the HTTP client follows a redirect to that domain. Details The root cause is in ManagedWebAccessUtils.getServer() at org.hl7.fhir.utilities/src/main/java/org/hl7/fhir/utilities/http/ManagedWebAccessUtils.java:26: The configured production terminology server URL is defined without a trailing slash in FhirSettingsPOJO.java:19: This means: - "http://tx.fhir.org.attacker.com/capture".startsWith("http://tx.fhir.org") → true - "http://tx.fhir.org:8080/evil".startsWith("http://tx.fhir.org") → true Exploit chain via SimpleHTTPClient (redirect path): 1. SimpleHTTPClient.get()…
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.
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.