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 consume attacker-controlled Smart Health Card JWT content whose header contains zip: "DEF" and whose small raw-DEFLATE payload expands to a very large value. SHCParser.decodeJWT() passes the decoded payload to SHCParser.inflate(), which accumulates all decompressed bytes in a ByteArrayOutputStream without an output-size limit before JSON parsing, and SHCParser.decompress() contains the same unbounded pattern. An application or validator service that accepts attacker-supplied SHC content can therefore suffer excessive heap allocation, severe garbage-collection pressure, request failure, process instability, or process termination. 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.250Z",
  "pubdate": "2026-09-16T19:17:44.250Z",
  "executiveSummary": "HAPI FHIR versions prior to 6.9.12 are susceptible to a Denial of Service (DoS) vulnerability originating from an improper input validation flaw within the SHCParser component.\nThe vulnerability occurs because the SHCParser class fails to impose size constraints when decompressing Smart Health Card (SHC) JWT payloads specified with 'zip: DEF' (DEFLATE) headers.\nAn unauthenticated attacker can exploit this by supplying a maliciously crafted, highly compressed JWT payload that expands into a significantly larger size upon decompression.\nThis behavior triggers excessive heap allocation, leading to severe garbage collection pressure, request processing failure, and potential process termination due to memory exhaustion.\nThe risk is significant for validator services or healthcare interoperability endpoints that process untrusted SHC content, as it allows a remote attacker to crash the application instance or induce service instability with minimal resource expenditure.",
  "technicalDetails": "The vulnerability resides within the SHCParser class, specifically located in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java. The affected functions are decodeJWT() and decompress(), which handle the processing of Smart Health Card (SHC) JWT structures.\nThe root cause is an unbounded stream consumption pattern when handling compressed data. When the parser encounters a JWT header containing 'zip: DEF', it initiates a DEFLATE decompression process. The implementation utilizes a ByteArrayOutputStream to accumulate the decompressed output; however, the parser lacks a mechanism to verify the size of the uncompressed data against a predefined safety threshold before or during the expansion process.\nAn attacker can leverage the high compression ratio of the DEFLATE algorithm to create a 'zip bomb' style payload. By supplying a small, carefully crafted malicious JWT, the attacker forces the SHCParser to allocate an arbitrary amount of memory in the Java heap to accommodate the fully expanded data. Because the allocation occurs entirely in memory within a ByteArrayOutputStream, the JVM is forced to perform aggressive garbage collection or, eventually, throw an OutOfMemoryError.\nThe exploitation flow is as follows: 1) An attacker submits a crafted SHC to a service using HAPI FHIR. 2) The SHCParser identifies the 'zip: DEF' header and proceeds to the decompression routine. 3) The decompress() function reads the malicious compressed stream and inflates it into the ByteArrayOutputStream. 4) The lack of an output-size limit allows the expansion to consume system memory rapidly. 5) The application process suffers from heap exhaustion, causing instability, degraded performance for legitimate users, or total process termination.\nThis vulnerability is particularly dangerous for network-exposed services that parse incoming FHIR resources, as it does not require authentication or elevated privileges. The impact is primarily a Denial of Service, effectively rendering the healthcare interoperability service unavailable to legitimate clinical systems."
}