Skip to main content
VulnerabilityPublished Updated

CVE-2026-33180: hapifhir org.hl7.fhir.core · Information Exposure

Affects hapifhir org.hl7.fhir.coreSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 7.5 High : upgrade to 6.9.0 soon.

Data as of 1 Nov 2026, 11:02 UTC

CVSS 3.1 base score
7.5High
How severe the flaw is on the 0–10 CVSS scale.
EPSS
0.2% chance of exploitation in 30 days – higher than 19% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 6.9.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 20 Mar 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 1 Nov 2026.

What to do

Upgrade org.hl7.fhir.core and org.hl7.fhir.core/org.hl7.fhir.core to 6.9.0.

Affected software

ProductAffectedFixed in
hapifhirorg.hl7.fhir.coreAffected
  • <6.9.0
Fixed in
  • 6.9.0
Mavenorg.hl7.fhir.core/org.hl7.fhir.corepkg:maven/org.hl7.fhir.core/org.hl7.fhir.coreOther threatsAffected
  • <6.9.0
Fixed in
  • 6.9.0

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Upgrade to HAPI FHIR version 6.9.0 or later, where this issue has been fixed. No known workarounds are available. Users should apply the official patch to prevent exposure of sensitive headers during HTTP redirects.

Description

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.0, when setting headers in HTTP requests, the internal HTTP client sends headers first to the host in the initial URL but also, if asked to follow redirects and a 30X HTTP response code is returned, to the host mentioned in URL in the Location: response header value. Sending the same set of headers to subsequent hosts is a problem as this header often contains privacy sensitive information or data that could allow others to impersonate the client's request. This issue has been patched in release 6.9.0. No known workarounds are available.

References

Community reviews

Loading reviews…