GHSA-gq9c-wmrm-5hvr
HAPI FHIR: SHCParser DEFLATE infinite loop causes denial of service
Quick fix
GHSA-gq9c-wmrm-5hvr — ca.uhn.hapi.fhir:org.hl7.fhir.r5: upgrade to the fixed version with the command below.
# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.r5Details
### 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)
Are you affected?
Enter the version of the package you're using.
Affected packages
0Fixed in: 6.9.12# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.r50Fixed in: 6.9.12# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.validation0Fixed in: 6.9.12# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.validation.cliReferences
- https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-gq9c-wmrm-5hvr[WEB]
- https://nvd.nist.gov/vuln/detail/CVE-2026-81876[ADVISORY]
- https://github.com/hapifhir/org.hl7.fhir.core/pull/2493[WEB]
- https://github.com/hapifhir/org.hl7.fhir.core/commit/d804558bd77372b1629e55a5b901cad3f5134cdc[WEB]
- https://github.com/hapifhir/org.hl7.fhir.core/commit/edd5d8c139e669e39270785f08be7b63aefef24c[WEB]
- https://github.com/hapifhir/org.hl7.fhir.core[PACKAGE]