CVE-2026-81875 in org.hl7.fhir.core
Summary
by MITRE • 09/16/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/16/2026
HAPI FHIR serves as a comprehensive Java implementation of the HL7 Fast Healthcare Interoperability Resources standard, facilitating data exchange within healthcare systems. A critical vulnerability exists within the Smart Health Card parser component, specifically located in the SHCParser class found in the org.hl7.fhir.r5 package. This flaw affects versions prior to 6.9.12 and involves a failure to enforce limits on resource consumption during the processing of decompressed data. The vulnerability is triggered when an attacker supplies maliciously crafted Smart Health Card JSON Web Token content that exploits the DEFLATE compression algorithm. By setting the header zip field to DEF, the payload utilizes small raw-DEFLATE compressed data designed to expand into a significantly larger value upon decompression.
The technical root cause lies in how SHCParser.decodeJWT and SHCParser.decompress handle the output of the inflation process. When decoding JWTs or processing smart health card content, these methods pass the decoded payload directly to an internal inflate function. This function accumulates all decompressed bytes into a ByteArrayOutputStream without implementing any upper bound on the output size. Consequently, if an attacker provides input that results in extreme data expansion ratios, the application allocates heap memory proportional to the uncompressed size rather than the compressed input size. This unbounded accumulation occurs before subsequent JSON parsing steps are executed, meaning the system commits substantial resources upfront based solely on potentially malicious compression artifacts.
The operational impact of this vulnerability is severe and primarily targets availability through resource exhaustion. Applications or validator services that accept attacker-supplied SHC content can experience excessive heap allocation as memory fills with the expanded data stream. This leads to intense garbage collection pressure, which degrades system performance by consuming CPU cycles in an attempt to reclaim unused memory. In many cases, this results in request failures due to timeout limits being exceeded or process instability characterized by erratic behavior and latency spikes. Ultimately, if the heap space is fully exhausted, it triggers a Java OutOfMemoryError, causing the application process to terminate abruptly. This constitutes a classic resource exhaustion scenario that can be leveraged for Denial of Service attacks against healthcare interoperability services relying on HAPI FHIR.
From a classification perspective, this vulnerability aligns with CWE-787: Out-of-bounds Write in terms of memory allocation limits and more accurately maps to CWE-400: Uncontrolled Resource Consumption. The attack vector involves providing specially crafted input that exploits compression algorithms to consume disproportionate system resources. In the context of the MITRE ATT&CK framework, this behavior is consistent with T1496: Resource Hijacking or potentially T1499: Endpoint Denial of Service if the impact leads to service unavailability. The vulnerability highlights a common pitfall in handling compressed data where developers assume that input size constraints are sufficient without accounting for expansion ratios inherent in algorithms like DEFLATE.
To mitigate this risk, organizations must upgrade HAPI FHIR to version 6.9.12 or later, which includes fixes for the unbounded accumulation pattern in SHCParser.inflate and related decompression methods. For systems that cannot immediately patch, implementing a custom input validation layer is recommended to enforce strict limits on the size of decompressed payloads before they are processed by FHIR parsers. This can be achieved by wrapping the output stream with a limit-checking mechanism or configuring the underlying compression libraries to reject inputs that exceed predefined expansion thresholds. Additionally, deploying web application firewalls with rules capable of detecting anomalous data expansion patterns in health card tokens may provide an additional layer of defense against exploitation attempts targeting this specific weakness.