CVE-2026-34359
Received Received - Intake
Authentication Bypass in HAPI FHIR via URL Prefix Matching

Publication date: 2026-03-31

Last updated on: 2026-04-03

Assigner: GitHub, Inc.

Description
HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, 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. This issue has been patched in version 6.9.4.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2026-03-31
Last Modified
2026-04-03
Generated
2026-05-07
AI Q&A
2026-03-31
EPSS Evaluated
2026-05-05
NVD
Affected Vendors & Products
Showing 1 associated CPE
Vendor Product Version / Range
hapifhir hl7_fhir_core to 6.9.4 (exc)
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-346 The product does not properly verify that the source of data or communication is valid.
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:

This vulnerability allows attackers to steal sensitive authentication credentials such as Bearer tokens, Basic auth credentials, API keys, and custom headers by exploiting improper URL prefix matching during HTTP redirects.

Because HAPI FHIR is widely used in healthcare IT environments, this credential leakage can lead to unauthorized access and impersonation, potentially exposing or modifying clinical terminology data.

Such unauthorized access and data exposure can result in violations of data protection regulations and standards like GDPR and HIPAA, which mandate strict controls over personal health information and secure authentication mechanisms.

Therefore, this vulnerability poses a significant risk to compliance with these regulations by enabling credential theft and unauthorized data access.


Can you explain this vulnerability to me?

CVE-2026-34359 is a vulnerability in HAPI FHIR Core versions prior to 6.9.4 that involves improper URL prefix matching during authentication credential dispatch. The method ManagedWebAccessUtils.getServer() uses String.startsWith() to check if a request URL matches a configured server URL. However, because the configured server URLs lack a trailing slash or host boundary validation, attacker-controlled domains that start with the legitimate server URL prefix (e.g., http://tx.fhir.org.attacker.com) incorrectly match the check.

As a result, when an HTTP client follows a redirect to such an attacker-controlled domain, it sends sensitive authentication credentials such as Bearer tokens, Basic auth credentials, API keys, and custom headers to the attacker. This happens because the client believes the redirect URL belongs to the trusted server due to the flawed prefix check.

The vulnerability also affects TLS enforcement by allowing attacker domains to be treated as local, enabling TLS downgrade attacks. The issue has been patched in version 6.9.4 by replacing the startsWith() check with proper host boundary validation.


How can this vulnerability impact me? :

This vulnerability can lead to the theft of sensitive authentication credentials including Bearer tokens, Basic authentication credentials, API keys, and custom authentication headers.

An attacker who successfully exploits this vulnerability can impersonate legitimate clients by making authenticated requests to the legitimate FHIR server. This can result in unauthorized access to or modification of clinical terminology data.

Additionally, the vulnerability can enable TLS downgrade attacks, reducing the security of communications by allowing attackers to bypass HTTPS enforcement.

Because HAPI FHIR Core is widely used in healthcare IT environments, many deployments could be affected, increasing the risk of broad exposure of sensitive healthcare data and credentials.


How can this vulnerability be detected on my network or system? Can you suggest some commands?

This vulnerability involves authentication credential leakage due to improper URL prefix matching during HTTP redirects in HAPI FHIR versions prior to 6.9.4.

To detect this vulnerability on your network or system, you can monitor HTTP client requests for redirects to domains that start with your configured server URL but are actually attacker-controlled domains (e.g., domains like "http://tx.fhir.org.attacker.com").

You can use network traffic analysis tools such as tcpdump or Wireshark to capture HTTP requests and inspect the Authorization headers sent during redirects.

  • Use tcpdump to capture HTTP traffic on port 80 or 443: tcpdump -i any -A 'tcp port 80 or tcp port 443'
  • Filter captured traffic for Authorization headers or Bearer tokens that are sent to unexpected domains matching the vulnerable pattern.
  • Check application logs or HTTP client logs for redirects to suspicious domains that start with your legitimate server URL but have additional suffixes.

Since the vulnerability arises from the use of String.startsWith() without proper host boundary checks, you can also audit your application code or configuration to identify if the HAPI FHIR Core version is prior to 6.9.4 and if the server URLs are configured without trailing slashes or host boundary validation.


What immediate steps should I take to mitigate this vulnerability?

The primary immediate mitigation is to upgrade HAPI FHIR Core to version 6.9.4 or later, where this vulnerability has been fixed.

If upgrading immediately is not possible, consider the following steps:

  • Modify the configuration of server URLs to include a trailing slash or implement host boundary validation to prevent attacker-controlled domains from matching the prefix.
  • Audit and restrict HTTP clients to not follow redirects automatically, or to validate redirect URLs carefully before sending authentication credentials.
  • Implement network-level controls to detect and block redirects to suspicious or attacker-controlled domains.
  • Review and patch the code to replace the vulnerable String.startsWith() check with a proper host boundary validation as described in the recommended fix.

These steps help prevent credential leakage and reduce the risk of impersonation and TLS downgrade attacks.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart