Skip to content

← Public intelligence

Maven package

ca.uhn.hapi.fhir:org.hl7.fhir.core

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

4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.

  1. Medium, CVSS 5.8MavenPublished

    FHIR Validator: Unauthenticated Blind SSRF via /loadIG Endpoint Enables Internal Network Probing

    CVE-2026-34360 · GHSA-3ww8-jw56-9f5h

    Affected
    • Maven ca.uhn.hapi.fhir:org.hl7.fhir.core < 6.9.4
    Fixed in
    6.9.4· Vendor fix available
    Issue
    The /loadIG HTTP endpoint in the FHIR Validator HTTP service accepts a user-supplied URL via JSON body and makes server-side HTTP requests to it without any hostname, scheme, or domain validation. An unauthenticated attacker with network access to the validator can probe internal network services, cloud metadata endpoints, and map network topology through error-based information leakage. With explore=true (the default for this code path), each request triggers multiple outbound HTTP calls, amplifying reconnaissance capability. Details Root cause chain: 1. LoadIGHTTPHandler.handle() reads the ig field from user-supplied JSON and passes it directly to IgLoader.loadIg() with no validation: 2. loadIg() calls loadIgSource(srcPackage, recursive, true) with explore=true (IgLoader.java:153). 3. loadIgSource() checks Common.isNetworkPath(src) which only verifies the URL starts with http: or https: — no host/IP validation (Common.java:14-16). 4. The URL reaches ManagedWebAccess.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.

    Sources:github.comSource checked Evidence →
  2. High, CVSS 7.4MavenPublished

    HAPI FHIR Core has Authentication Credential Leakage via Improper URL Prefix Matching on HTTP Redirect

    CVE-2026-34359 · GHSA-fgv2-4q4g-wc35

    Affected
    • Maven ca.uhn.hapi.fhir:org.hl7.fhir.core < 6.9.4
    Fixed in
    6.9.4· Vendor fix available
    Issue
    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.

    Sources:github.comSource checked Evidence →
  3. High, CVSS 7.5MavenPublished

    HL7 FHIR Partial Path Zip Slip due to bypass of CVE-2023-24057

    CVE-2023-28465 · GHSA-9654-pr4f-gh6m

    Affected
    • Maven ca.uhn.hapi.fhir:org.hl7.fhir.core < 5.6.106
    Fixed in
    5.6.106· Vendor fix available
    Issue
    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.

    Sources:github.comSource checked Evidence →
  4. Critical, CVSS 9.1MavenPublished

    MITM based Zip Slip in ca.uhn.hapi.fhir:org.hl7.fhir.core

    CVE-2023-24057 · GHSA-jqh6-9574-5x22

    Affected
    • Maven ca.uhn.hapi.fhir:org.hl7.fhir.core < 5.6.92
    Fixed in
    5.6.92· Vendor fix available
    Issue
    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.

    Sources:github.comSource checked Evidence →