CVE-2026-34360
Server-Side Request Forgery in HAPI FHIR Validator HTTP Service
Publication date: 2026-03-31
Last updated on: 2026-04-03
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| hapifhir | hl7_fhir_core | to 6.9.4 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-34360 is a Server-Side Request Forgery (SSRF) vulnerability in the /loadIG HTTP endpoint of the HAPI FHIR Validator HTTP service. This endpoint accepts a user-supplied URL via a JSON body and makes server-side HTTP requests to that URL without properly validating the hostname, scheme, or domain.
Because of insufficient URL validation and disabled domain restrictions, an unauthenticated attacker with network access can make the server send requests to internal network services or cloud metadata endpoints. The vulnerability is amplified by the default setting explore=true, which triggers multiple outbound HTTP calls per request.
Attackers can use this to probe internal network services, perform port scans, map network topology, and access sensitive cloud metadata services. The SSRF is blind, meaning the fetched content is not returned to the attacker, but error messages leak information about network reachability and port status.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows unauthenticated attackers to perform server-side request forgery (SSRF) attacks that can probe internal network services, access cloud metadata endpoints, and map network topology through error-based information leakage.
While the SSRF is blind and does not return fetched content, it enables internal network reconnaissance and potential exposure of sensitive infrastructure details.
This exposure could indirectly impact compliance with standards like GDPR and HIPAA by increasing the risk of unauthorized internal network access and potential data exposure, as these regulations require protection of sensitive healthcare data and infrastructure.
However, the CVE description and resources do not explicitly mention direct violations or impacts on these compliance standards.
How can this vulnerability impact me? :
This vulnerability allows unauthenticated attackers with network access to the FHIR Validator to perform reconnaissance on internal network services and cloud environments.
- Probe internal network services and differentiate open or closed ports.
- Access cloud metadata endpoints such as AWS, GCP, and Azure metadata services.
- Map internal network topology through error-based information leakage.
- Bypass domain allowlists using redirect chains to reach unauthorized internal targets.
While the SSRF does not allow direct data exfiltration since the fetched content is not returned, the information gathered can aid attackers in planning further attacks or exploiting other vulnerabilities.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring and analyzing HTTP requests to the /loadIG endpoint of the FHIR Validator HTTP service for unusual or unauthorized outbound HTTP calls triggered by user-supplied URLs in JSON bodies.
Since the vulnerability allows unauthenticated attackers to cause server-side HTTP requests to arbitrary URLs without validation, detection can involve checking logs for requests to /loadIG with JSON bodies containing the "ig" field, especially those that result in outbound requests to internal IP addresses or cloud metadata endpoints.
Suggested commands to detect exploitation attempts include:
- Use network monitoring tools (e.g., tcpdump or Wireshark) to capture outbound HTTP requests from the server and filter for requests to internal IP ranges or cloud metadata IPs (e.g., 169.254.169.254). Example: tcpdump -i eth0 dst net 169.254.169.254 or internal IP ranges.
- Check HTTP server access logs for POST requests to /loadIG containing JSON bodies with the "ig" field. Example using grep and jq: grep '/loadIG' access.log | jq '.ig'
- Scan logs for error messages indicating failed outbound HTTP requests to internal services or ports, which may indicate SSRF probing.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include:
- Upgrade the HAPI FHIR Validator HTTP service to version 6.9.4 or later, where the vulnerability is patched.
- If upgrading is not immediately possible, restrict network access to the /loadIG endpoint to trusted users only, ideally by firewall rules or network segmentation.
- Implement authentication on the HTTP service, especially for the /loadIG endpoint, to prevent unauthenticated access.
- Configure allowedDomains to restrict outbound HTTP requests to trusted FHIR registries and block requests to private, loopback, link-local, and site-local IP addresses.
- Monitor logs for suspicious activity targeting the /loadIG endpoint and block or alert on such activity.