VDB
Sign up
HIGH7.5

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.r5

Details

### 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

Maven/ca.uhn.hapi.fhir:org.hl7.fhir.r5
Introduced in: 0Fixed in: 6.9.12
Fix# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.r5
Maven/ca.uhn.hapi.fhir:org.hl7.fhir.validation
Introduced in: 0Fixed in: 6.9.12
Fix# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.validation
Maven/ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli
Introduced in: 0Fixed in: 6.9.12
Fix# pom.xml: bump <version>6.9.12</version> for ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli

References