Description

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.12, SHCParser in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java can enter an infinite loop while processing attacker-controlled Smart Health Card JWT content whose header contains zip: "DEF" and whose raw-DEFLATE payload is empty or truncated. SHCParser.decodeJWT() reaches SHCParser.inflate(), where Inflater.inflate() can return zero while Inflater.finished() remains false and Inflater.needsInput() is true. The loop also lacks an Inflater.needsDictionary() termination check, SHCParser.decompress() contains the same zero-progress pattern, and ResourceChecker.java can reach SHC parsing during file-format detection. A malformed validation request can pin a JVM worker thread indefinitely, and concurrent requests can exhaust all validation workers. This issue is fixed in version 6.9.12.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-09-16T19:17:44.450Z",
  "pubdate": "2026-09-16T19:17:44.450Z",
  "executiveSummary": "HAPI FHIR versions prior to 6.9.12 are susceptible to a Denial of Service (DoS) vulnerability originating from improper handling of compressed Smart Health Card (SHC) JWT content.\nThe vulnerability occurs within the SHCParser component, where malformed or truncated DEFLATE-compressed payloads trigger an infinite loop during the decompression process.\nAn unauthenticated attacker can exploit this by submitting specifically crafted SHC payloads to the application. This action forces the JVM worker thread to hang indefinitely, consuming system resources.\nThe risk is significant because concurrent malicious requests can exhaust the entire pool of validation worker threads, rendering the FHIR server unresponsive to legitimate healthcare interoperability requests.\nSuccessful exploitation requires no prior authentication and can be performed over any network interface that exposes FHIR validation or SHC processing endpoints.\nThe primary impact is service unavailability, which may disrupt critical healthcare workflows dependent on FHIR data exchange.",
  "technicalDetails": "The vulnerability is rooted in the implementation of the SHCParser class, specifically within the SHCParser.inflate() and SHCParser.decompress() methods located in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java.\nThe flaw manifests when processing a JWT header that specifies 'zip: \"DEF\"', indicating DEFLATE compression. When the provided raw-DEFLATE payload is intentionally empty, truncated, or malformed, the java.util.zip.Inflater instance enters an inconsistent state.\nSpecifically, the parser invokes Inflater.inflate(), which returns zero bytes indicating no progress, yet the internal state remains such that Inflater.finished() returns false and Inflater.needsInput() returns true. The parsing logic lacks a sufficient termination condition, specifically failing to account for states where the Inflater needs a dictionary or fails to make forward progress despite input availability.\nBecause the loop structure in SHCParser does not implement a threshold or validation check for zero-byte inflation progress, the thread enters an infinite cycle. This execution path is further reachable via the ResourceChecker.java component, which performs automatic file-format detection on incoming validation requests, thereby broadening the attack surface.\nAn attacker can exploit this by transmitting a SHC JWT containing the specified header and a malicious, truncated body. When the HAPI FHIR validation engine processes this input, the thread responsible for handling the request becomes permanently pinned to the CPU, effectively locking that worker thread.\nBy issuing a series of such requests concurrently, an attacker can consume all available worker threads in the HAPI FHIR validation pool. Once the pool is exhausted, the application cannot process valid healthcare data, resulting in a complete Denial of Service for the affected instance.\nThis vulnerability is present in all HAPI FHIR versions prior to 6.9.12 and requires no privileges or authentication, making it a critical availability risk for any system utilizing SHC validation functionality."
}