CVE-2026-34361: HAPI FHIR SSRF Vulnerability

CVE-2026-34361 Overview

A critical Server-Side Request Forgery (SSRF) vulnerability exists in HAPI FHIR, a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, the FHIR Validator HTTP service exposes an unauthenticated /loadIG endpoint that makes outbound HTTP requests to attacker-controlled URLs. When combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens including Bearer tokens, Basic authentication credentials, and API keys configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL.

Critical Impact

Attackers can steal healthcare system authentication credentials without any prior authentication, potentially compromising patient data and healthcare infrastructure through credential theft.

Affected Products

• HAPI FHIR versions prior to 6.9.4
• FHIR Validator HTTP service with /loadIG endpoint exposed
• Systems using ManagedWebAccessUtils.getServer() for credential management

Discovery Timeline

• 2026-03-31 - CVE CVE-2026-34361 published to NVD
• 2026-04-01 - Last updated in NVD database

Technical Details for CVE-2026-34361

Vulnerability Analysis

This vulnerability combines two distinct security flaws to enable credential theft. The first issue is an unauthenticated endpoint exposure—the FHIR Validator HTTP service exposes the /loadIG endpoint without requiring any form of authentication, allowing anyone with network access to trigger outbound HTTP requests from the vulnerable server.

The second and more severe issue lies in the credential provider logic within ManagedWebAccessUtils.getServer(). This function uses a flawed startsWith() URL prefix matching algorithm to determine which credentials should be attached to outbound requests. Instead of performing exact domain matching or proper URL parsing, the implementation checks if the target URL begins with a configured server URL prefix.

An attacker can exploit this by registering a malicious domain that prefix-matches a legitimate FHIR server URL (e.g., registering fhir.hospital.com.attacker.com to match credentials configured for fhir.hospital.com). When the attacker uses the /loadIG endpoint to request a resource from their malicious domain, the vulnerable credential provider incorrectly matches the attacker-controlled URL and attaches legitimate authentication tokens to the outbound request.

Root Cause

The root cause is CWE-552 (Files or Directories Accessible to External Parties) combined with improper URL validation. The startsWith() string comparison used in ManagedWebAccessUtils.getServer() fails to properly validate URL boundaries, treating https://legitimate-server.com.attacker.com as a valid match for credentials configured for https://legitimate-server.com. This logic flaw, combined with the unauthenticated /loadIG endpoint, creates an exploitable credential theft vulnerability.

Attack Vector

The attack is network-based and requires no authentication or user interaction. An attacker with network access to the FHIR Validator HTTP service can:

1. Enumerate or guess legitimate FHIR server URLs that have configured credentials
2. Register a malicious domain that prefix-matches the target server URL
3. Send a crafted request to the /loadIG endpoint targeting their malicious domain
4. Receive the authentication tokens (Bearer, Basic, or API keys) that the vulnerable server attaches to the outbound request

The vulnerability is exploited through HTTP requests to the /loadIG endpoint. When an attacker registers a domain like legitimate-fhir-server.com.malicious.com that prefix-matches a configured FHIR server URL legitimate-fhir-server.com, the credential provider's flawed startsWith() logic incorrectly determines the attacker's URL should receive authentication credentials. The attacker's server then captures these credentials when the FHIR Validator makes the outbound request. For detailed technical information, see the GitHub Security Advisory.

Detection Methods for CVE-2026-34361

Indicators of Compromise

• Unusual outbound HTTP requests from FHIR Validator servers to unfamiliar domains
• Access logs showing requests to /loadIG endpoint from external IP addresses
• Authentication failures or credential revocations for FHIR server accounts
• Domains registered that closely resemble legitimate FHIR server URLs

Detection Strategies

• Monitor network traffic from FHIR Validator services for connections to unknown or recently registered domains
• Implement logging and alerting on all /loadIG endpoint access attempts
• Review DNS logs for requests to domains that prefix-match your legitimate FHIR server URLs
• Deploy web application firewalls to restrict access to the /loadIG endpoint

Monitoring Recommendations

• Enable detailed access logging for the FHIR Validator HTTP service
• Configure alerts for outbound connections to domains not on an approved allowlist
• Monitor for credential usage anomalies that may indicate stolen tokens are being used
• Implement network segmentation to limit FHIR Validator's outbound connectivity

How to Mitigate CVE-2026-34361

Immediate Actions Required

• Upgrade HAPI FHIR to version 6.9.4 or later immediately
• Restrict network access to the /loadIG endpoint using firewall rules or reverse proxy configuration
• Rotate all authentication credentials (Bearer tokens, Basic auth, API keys) configured for FHIR servers
• Review logs for any suspicious access to the /loadIG endpoint prior to patching

Patch Information

The vulnerability has been patched in HAPI FHIR version 6.9.4. The fix addresses both the unauthenticated endpoint exposure and the flawed URL prefix matching logic in ManagedWebAccessUtils.getServer(). Organizations should upgrade to version 6.9.4 or later as soon as possible. For additional details, refer to the GitHub Security Advisory.

Workarounds

• Block external access to the /loadIG endpoint at the network level until patching is possible
• Deploy a reverse proxy that requires authentication before requests reach the FHIR Validator
• Implement network egress filtering to restrict outbound connections from the FHIR Validator
• Consider disabling the FHIR Validator HTTP service if not actively required

# Example: Restrict access to /loadIG endpoint using nginx
location /loadIG {
    # Deny all external access until patched
    deny all;
    # Or restrict to internal networks only
    # allow 10.0.0.0/8;
    # allow 172.16.0.0/12;
    # allow 192.168.0.0/16;
    # deny all;
}