CVE-2026-34359: 
Java vulnerability analysis and mitigation

CVE-2026-34359 is an authentication credential leakage vulnerability in HAPI FHIR Core (HL7 FHIR Core library) caused by improper URL prefix matching during HTTP redirect handling. The ManagedWebAccessUtils.getServer() method uses String.startsWith() without host boundary validation, allowing attacker-controlled domains (e.g., http://tx.fhir.org.attacker.com) to match configured server URLs (e.g., http://tx.fhir.org) and receive Bearer tokens, Basic auth credentials, or API keys. All versions of ca.uhn.hapi.fhir:org.hl7.fhir.core and ca.uhn.hapi.fhir:org.hl7.fhir.utilities prior to 6.9.4 are affected. The vulnerability was published on March 27, 2026, and assigned a CVSS v3.1 score of 7.4 (High) by the GitHub Advisory Database, though Feedly's estimate places it at 9.1 (Critical) (GitHub Advisory, HAPI FHIR Advisory).

The root cause is classified as CWE-346 (Origin Validation Error). The vulnerable method ManagedWebAccessUtils.getServer() in ManagedWebAccessUtils.java:26 uses url.startsWith(serverDetails.getUrl()) to determine whether to attach authentication credentials to an outbound request, with no check that the matched prefix ends at a host boundary. Because the production terminology server URL http://tx.fhir.org is configured without a trailing slash, strings like http://tx.fhir.org.attacker.com/capture and http://tx.fhir.org:8080/evil both satisfy the prefix check. Two exploit paths exist: via SimpleHTTPClient (which re-evaluates auth headers on each redirect hop) and via ManagedFhirWebAccessor using OkHttpClient (which carries pre-set auth headers across all redirects by default). The same flawed pattern in ManagedWebAccess.isLocal() can additionally enable TLS downgrade by treating attacker-controlled domains as local (GitHub Advisory, HAPI FHIR Advisory).

Successful exploitation results in exfiltration of Bearer tokens, Basic authentication credentials (base64-encoded username/password), API keys, and custom authentication headers configured for FHIR terminology servers. Stolen credentials enable an attacker to impersonate the affected application when making authenticated requests to legitimate FHIR servers, potentially allowing unauthorized access to or modification of clinical terminology data. The FHIR Validator is widely deployed in healthcare IT, meaning any organization that configures server authentication in fhir-settings.json and makes outbound HTTP requests to terminology servers is at risk of credential theft and subsequent impersonation attacks (HAPI FHIR Advisory).

A proof-of-concept exploit with concrete step-by-step reproduction instructions is publicly available in the GitHub Security Advisory, demonstrating how to trigger credential leakage to an attacker-controlled domain via HTTP redirect (HAPI FHIR Advisory). Exploitation requires no authentication and no user interaction, but does require the ability to inject a redirect (e.g., via MITM, compromised CDN, or DNS poisoning), which elevates attack complexity. The EPSS score is approximately 0.015–0.035%, indicating low current exploitation probability. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Reconnaissance: Identify deployments of HAPI FHIR Core (versions < 6.9.4) that configure server authentication credentials in ~/.fhir/fhir-settings.json and make outbound HTTP requests to FHIR terminology servers such as http://tx.fhir.org.
2. Register attacker-controlled domain: Register or control a domain whose name begins with the target server's hostname, e.g., tx.fhir.org.attacker.com, which satisfies the startsWith("http://tx.fhir.org") check.
3. Inject redirect: Position the attacker to serve a 302 HTTP redirect from the legitimate server URL (e.g., http://tx.fhir.org/ValueSet/$expand) to the attacker-controlled URL (http://tx.fhir.org.attacker.com/capture). This can be achieved via DNS poisoning, MITM on the network path, or compromise of a CDN/proxy in front of the FHIR server.
4. Capture credentials: When the vulnerable FHIR client follows the redirect, setHeaders() is called with the redirect target URL. The startsWith() check matches the attacker domain, and the client dispatches the configured Authorization: Bearer <token>, Authorization: Basic <base64>, or Api-Key: <key> header to the attacker's server. Listen with a simple netcat listener (nc -l -p 80) to capture the credential.
5. Impersonate the application: Use the captured Bearer token or credentials to make authenticated requests directly to the legitimate FHIR terminology server, accessing or modifying clinical terminology data (HAPI FHIR Advisory).

• Network: Outbound HTTP requests from FHIR application servers to unexpected domains whose hostnames begin with tx.fhir.org (e.g., tx.fhir.org.attacker.com) carrying Authorization or Api-Key headers; unexpected 302 redirect responses from FHIR terminology server endpoints.
• Logs: HTTP client logs showing redirect chains from http://tx.fhir.org/* to external domains not matching the configured server list; authentication header dispatch to non-canonical FHIR server hostnames in application debug/access logs.
• DNS: DNS queries for subdomains or lookalike domains of tx.fhir.org (e.g., tx.fhir.org.<external-domain>) originating from FHIR application hosts.
• Configuration: Presence of fhir-settings.json at ~/.fhir/fhir-settings.json with authenticationType set to token, basic, or apikey for servers configured without trailing slashes (HAPI FHIR Advisory).

Upgrade ca.uhn.hapi.fhir:org.hl7.fhir.core and ca.uhn.hapi.fhir:org.hl7.fhir.utilities to version 6.9.4 or later, which implements proper host boundary validation in the URL matching logic (GitHub Advisory). As a configuration-level workaround prior to patching, ensure all server URLs in fhir-settings.json include a trailing slash (e.g., http://tx.fhir.org/) to reduce — but not eliminate — the prefix-matching attack surface. Additionally, enforce network-level controls to prevent outbound HTTP requests from FHIR application hosts to unexpected external domains, and consider re-introducing host-equality checks for redirect following in SimpleHTTPClient as defense-in-depth (HAPI FHIR Advisory).