CVE-2026-33180: HAPI FHIR Information Disclosure Flaw

CVE-2026-33180 Overview

HAPI FHIR, a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java, contains an information disclosure vulnerability in its internal HTTP client. Prior to version 6.9.0, when the HTTP client is configured to follow redirects and receives a 30X HTTP response code, it sends all headers—including those set for the initial request—to the host specified in the Location: response header. This behavior can result in sensitive information being inadvertently leaked to third-party servers.

Critical Impact

Authentication tokens, session identifiers, and other privacy-sensitive headers may be transmitted to untrusted redirect destinations, potentially enabling account impersonation or unauthorized data access in healthcare environments.

Affected Products

• HAPI FHIR versions prior to 6.9.0
• Applications using HAPI FHIR's internal HTTP client with redirect following enabled
• Healthcare systems implementing HL7 FHIR interoperability via HAPI FHIR

Discovery Timeline

• 2026-03-20 - CVE CVE-2026-33180 published to NVD
• 2026-03-23 - Last updated in NVD database

Technical Details for CVE-2026-33180

Vulnerability Analysis

This vulnerability falls under CWE-200 (Exposure of Sensitive Information to an Unauthorized Actor). The core issue lies in how the HAPI FHIR internal HTTP client handles HTTP redirects. When a client makes an initial request to a trusted server with authentication headers or other sensitive data, and that server responds with a 3XX redirect status code pointing to a different host, the client blindly forwards all original headers to the new destination.

In healthcare contexts where FHIR is deployed, HTTP headers often contain OAuth tokens, API keys, patient identifiers, or other Protected Health Information (PHI) that should never be transmitted to unauthorized parties. The network-based attack vector requires no privileges or user interaction, making this vulnerability particularly concerning for internet-facing FHIR servers.

Root Cause

The root cause is improper handling of HTTP redirect responses in the HAPI FHIR internal HTTP client. The client fails to distinguish between same-origin and cross-origin redirects when determining which headers should be forwarded. According to security best practices, sensitive headers like Authorization, Cookie, and custom authentication tokens should be stripped when following redirects to different hosts. The vulnerable implementation does not implement this header sanitization logic before following redirects.

Attack Vector

An attacker can exploit this vulnerability by controlling or compromising a server that a HAPI FHIR client communicates with. The attack scenario proceeds as follows:

1. A HAPI FHIR client sends an authenticated request to a legitimate FHIR server with sensitive headers (e.g., Authorization: Bearer <token>)
2. The server (either compromised or malicious) responds with a 302 redirect to an attacker-controlled server
3. The HAPI FHIR client follows the redirect and sends the same sensitive headers to the attacker's server
4. The attacker captures the authentication tokens or sensitive data from the headers
5. Using the captured credentials, the attacker can impersonate the client to access protected healthcare resources

This attack is particularly effective in federated healthcare environments where multiple FHIR servers interact and redirect requests between systems.

Detection Methods for CVE-2026-33180

Indicators of Compromise

• Unexpected outbound HTTP connections from HAPI FHIR clients to unknown external hosts
• Authentication tokens appearing in logs of servers that should not have received them
• Anomalous redirect chains in HTTP traffic involving FHIR endpoints
• Reports of account compromise or unauthorized access following legitimate FHIR API usage

Detection Strategies

• Monitor HTTP traffic for redirect responses (301, 302, 303, 307, 308) from FHIR endpoints that point to external or untrusted domains
• Implement network-level detection for sensitive header patterns (e.g., Authorization: Bearer) being sent to hosts outside the trusted FHIR server list
• Audit HAPI FHIR client configurations to identify instances where redirect following is enabled
• Review application logs for evidence of multi-hop redirects during FHIR operations

Monitoring Recommendations

• Enable detailed HTTP request/response logging for HAPI FHIR clients to capture redirect chains and header transmission
• Implement alerting on authentication failures that correlate with prior redirect activity from FHIR endpoints
• Deploy network monitoring to flag when FHIR clients connect to hosts not in the approved server allowlist
• Establish baseline metrics for redirect frequency and investigate anomalous spikes

How to Mitigate CVE-2026-33180

Immediate Actions Required

• Upgrade all HAPI FHIR installations to version 6.9.0 or later immediately
• Audit existing HAPI FHIR client configurations to identify redirect handling settings
• Rotate any authentication tokens or credentials that may have been exposed through redirect-following behavior
• Review access logs on FHIR servers to identify potential exploitation attempts

Patch Information

The vulnerability has been patched in HAPI FHIR release 6.9.0. Organizations should upgrade to this version or later to address the header leakage issue. The patch implements proper header sanitization when following cross-origin redirects. For detailed information about the fix, refer to the GitHub Security Advisory.

Workarounds

• No known workarounds are available according to the vendor advisory
• As a defense-in-depth measure, consider disabling automatic redirect following at the HTTP client level and handling redirects explicitly in application code
• Implement network-level controls to restrict which external hosts FHIR clients can connect to
• Use short-lived authentication tokens to limit the window of exposure if headers are leaked

# Verify HAPI FHIR version in Maven projects
mvn dependency:tree | grep hapi-fhir
# Upgrade to patched version in pom.xml: <version>6.9.0</version>