CVE-2026-81876: HAPI FHIR: SHCParser DEFLATE infinite loop causes denial of service
Summary A malformed Smart Health Card (SHC) JWT with zip: "DEF" and an empty or truncated DEFLATE payload causes SHCParser.inflate() to loop forever. This allows an attacker who can submit SHC content for validation to pin a JVM worker thread indefinitely, causing denial of service.
Details The vulnerable code is in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java.
decodeJWT() inflates the JWT payload when the header contains "zip":"DEF":
java // SHCParser.java:300-302 if ("DEF".equals(res.header.asString("zip"))) { payloadJson = inflate(payloadJson); }
inflate() loops only on !inflater.finished() and does not check inflater.needsInput(), inflater.needsDictionary(), or zero-progress output:
java // SHCParser.java:455-468 while (!inflater.finished()) { final int count = inflater.inflate(buffer); outputStream.write(buffer, 0, count); }
For empty or truncated raw DEFLATE input, Inflater.inflate() returns 0, finished() remains false, and needsInput() becomes true, producing an infinite tight loop. The same unsafe loop pattern also exists in decompress() at SHCParser.java:410-423.
The validator reaches this path during SHC validation and during file-format detection for SHC-looking input (ResourceChecker.java:115-118).
PoC Compile the project, then run a minimal local harness that calls:
java SHCParser.inflate(new byte[0]);
This never returns. Local verification:
bash timeout 3s java -cp ... VerifyDoSFindings shcHang echo $? 124 = timeout killed the hung process
A JWT PoC uses:
- header: Base64URL({"zip":"DEF"}) - payload: empty or truncated raw DEFLATE bytes - signature: arbitrary
Submit the resulting token as SHC content, for example via a .shc file or content beginning with shc:/ that reaches the validator's SHC detection path.
Impact This is a denial-of-service vulnerability. A single malformed SHC validation request can consume a worker thread indefinitely. In services that validate uploaded SHC content, a small number of concurrent malformed requests can exhaust all validation workers.
Credits - Thai Son Dinh from VinSOC Labs (R&D)
Other sources
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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/ca.uhn.hapi.fhir:org.hl7.fhir.validation.clito a version that resolves this vulnerability.Fixed in 6.9.12 - Upgrade
Upgrade
maven/ca.uhn.hapi.fhir:org.hl7.fhir.validationto a version that resolves this vulnerability.Fixed in 6.9.12 - Upgrade
Upgrade
maven/ca.uhn.hapi.fhir:org.hl7.fhir.r5to a version that resolves this vulnerability.Fixed in 6.9.12 - Upgrade
Upgrade
HAPI FHIR (org.hl7.fhir.r5 elementmodel SHCParser)to a version that resolves this vulnerability.Fixed in 6.9.12 - Compensating control
If you validate uploaded SHC content, limit the number of concurrent SHC validation requests so a small number of malformed requests cannot exhaust all validation workers (e.g., enforce concurrency/rate limits on the validator endpoint).
- Operational
After upgrading to HAPI FHIR 6.9.12, restart the JVM/services that run SHC validation to clear any threads that may be pinned by the vulnerable infinite-loop behavior.
Event History
Frequently Asked Questions
Which deployments are exposed to this denial of service?
Deployments using HAPI FHIR versions before 6.9.12 are affected if they process attacker-controlled Smart Health Card JWT content or perform file-format detection that can reach SHC parsing. A malformed validation request can indefinitely occupy a JVM validation worker thread.
What does an attacker need to send to trigger the issue?
The attacker needs to supply a Smart Health Card JWT with a header containing zip: "DEF" and an empty or truncated raw-DEFLATE payload. No authentication or user interaction is required according to the reported vector.
How can this affect service availability?
A single malformed request can pin a JVM worker thread in an infinite loop. Concurrent malformed requests can exhaust all validation workers and prevent the service from processing legitimate validation work.
What should be done to remediate the issue?
Upgrade HAPI FHIR to version 6.9.12, which fixes the issue. The provided data does not identify a workaround for deployments that cannot immediately upgrade.