CVE-2026-81876 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 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.
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 parsing logic prior to version 6.9.12, specifically located in the SHCParser class found at org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java. This flaw allows an attacker who controls the input data to trigger a denial of service condition by causing the application to enter an infinite loop during the processing of maliciously crafted Smart Health Card JSON Web Tokens. The vulnerability is rooted in the interaction between the parser and Java’s built-in compression utilities, where specific malformed inputs cause the decompression routine to stall indefinitely without throwing an exception or terminating gracefully.
The technical mechanism behind this denial of service involves a flawed loop structure within the SHCParser.decodeJWT method which calls into SHCParser.inflate. Inside inflate(), the code relies on java.util.zip.Inflater to process compressed data. The vulnerability manifests when processing payloads that are either empty, truncated, or specifically crafted with a header indicating zip compression but containing insufficient or invalid deflate stream data. In such scenarios, the Inflater.inflate() method returns zero bytes of decompressed output while simultaneously reporting via finished() that it is not yet complete and needsInput(). This creates a state where the parser expects more input that will never arrive correctly, yet the loop condition fails to detect this stall because it lacks a check for Inflater.needsDictionary(). Consequently, the thread remains trapped in an endless cycle of attempting to decompress data that cannot be successfully processed.
This issue is compounded by similar logic flaws present in SHCParser.decompress(), which exhibits the same zero-progress pattern where no bytes are consumed but the loop continues indefinitely. Furthermore, the attack surface is expanded because ResourceChecker.java can invoke Smart Health Card parsing routines during file format detection processes. This means that an attacker does not necessarily need to target a specific endpoint designed for health card validation; rather, any operation involving resource checking on files or streams containing these malformed tokens can trigger the vulnerability. The result is that a single malicious request can pin a JVM worker thread indefinitely, preventing it from handling other tasks and effectively reducing the application's capacity to serve legitimate users.
The operational impact of this vulnerability is significant for systems relying on HAPI FHIR for high-throughput validation or processing of health data. Since Java web servers typically use a fixed pool of threads to handle incoming requests, pinning even one thread can degrade performance across the entire service. In environments with concurrent request handling, multiple such attacks launched in parallel can exhaust all available worker threads in the validation pool. This leads to a complete denial of service where legitimate healthcare interoperability transactions are blocked until the application is restarted or the offending connections time out at the network level. The vulnerability aligns with CWE-835, which describes loops that consume excessive resources due to missing termination conditions, and maps to MITRE ATT&CK technique T1499, specifically endpoint denial of service via resource exhaustion.
Mitigation for this issue requires immediate upgrading to HAPI FHIR version 6.9.12 or later, where the parsing logic has been corrected to properly handle edge cases in decompression streams and includes necessary termination checks such as needsDictionary(). For organizations unable to upgrade immediately due to dependency constraints, implementing a network-level timeout on incoming connections can limit the duration of pinned threads. Additionally, deploying an API gateway that validates input sizes or rejects suspiciously malformed JWT headers before they reach the application layer provides an effective defense-in-depth strategy. Monitoring JVM thread dumps for stuck threads in SHCParser-related stacks can also aid in early detection and incident response during periods where patching is delayed.