Threat Intelligence Database

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

### Summary `SHCParser` inflates compressed Smart Health Card JWT payloads into memory without a decompressed-size limit. An attacker who can submit SHC content for validation can craft a small compressed JWT payload that expands to a very large byte array, causing memory exhaustion or severe garbage collection pressure. ### Details The vulnerable code is in `org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java`. `decodeJWT()` checks `MAX_ALLOWED_SHC_LENGTH`, but this only logs an error and parsing continues: ```java // SHCParser.java:282-284 if (jwt.length() > MAX_ALLOWED_SHC_LENGTH) { logError(...); } ``` If the header contains `"zip":"DEF"`, the payload is inflated before JSON parsing: ```java // SHCParser.java:300-304 if ("DEF".equals(res.header.asString("zip"))) { payloadJson = inflate(payloadJson); } res.payload = JsonParser.parseObject(FileUtilities.bytesToString(payloadJson), true); ``` `inflate()` accumulates all decompressed output in a `ByteArrayOutputStream` and has no maximum output size: ```java // SHCParser.java:455-468 while (!inflater.finished()) { final int count = inflater.inflate(buffer); outputStream.write(buffer, 0, count); } return outputStream.toByteArray(); ``` The same unbounded decompression pattern exists in `decompress()` at `SHCParser.java:410-423`. ### PoC Create a highly compressible SHC-shaped JSON payload, compress it with raw DEFLATE (`new Deflater(9, true)`), Base64URL-encode it as the JWT payload, and set the JWT header to `{"zip":"DEF"}`. Local verification measured the following expansion through `SHCParser.inflate()`: ```text plain=1000066 compressed=1052 inflated=1000066 ratio=950 plain=16000066 compressed=15626 inflated=16000066 ratio=1023 ``` A small compressed payload can therefore allocate many megabytes of heap. Larger payloads can trigger `OutOfMemoryError` or process instability. ### Impact This is a denial-of-service vulnerability. Any validator service or application that accepts attacker-supplied SHC content can be forced to allocate excessive heap memory. Impact ranges from request failure and severe GC pressure to process termination. ### Credits - Thai Son Dinh from VinSOC Labs (R&D)

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.11, the JSON utility parser in org.hl7.fhir.utilities.json.parser.JsonParser enforces no maximum nesting depth for arrays or objects. As a result, a small but deeply nested, syntactically valid FHIR JSON document can trigger unbounded readArray() or readObject() recursion, raising a StackOverflowError before structural validation runs. An attacker who can submit JSON resources for validation can thus crash the request thread, and services that do not isolate StackOverflowError safely may experience worker loss or process instability — a denial-of-service condition. This issue is fixed in version 6.9.11.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.11, the hidden scan command concatenates attacker-controlled Implementation Guide titles, profile titles, and source references into scan.html without escaping in Scanner.java. As a result, a user who scans an attacker-supplied IG/profile and then opens or publishes the generated local/CI HTML report can trigger stored cross-site scripting, executing attacker-controlled JavaScript in the report's browser context. This issue is fixed in version 6.9.11.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.7, the FHIRPathEngine implementation passes user-controlled regular expressions from matches(), matchesFull(), and replaceMatches() to Java regex operations without effective timeouts, allowing catastrophic backtracking and denial of service. This issue is fixed in version 6.9.7.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.10, org.hl7.fhir.utilities.XsltUtilities saxonTransform(...) overloads instantiated a bare net.sf.saxon.TransformerFactoryImpl() without ACCESS_EXTERNAL_DTD or ACCESS_EXTERNAL_STYLESHEET restrictions, allowing an attacker who controls or can tamper with transformed XML to trigger XML External Entity injection for local file disclosure and blind XXE or SSRF to arbitrary URLs reachable from the host. This issue is fixed in version 6.9.10.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to 6.9.10, the fix for CVE-2026-45367 incompletely patched the DSTU2 module, leaving FHIRPathEngine.matches() in org.hl7.fhir.dstu2/utils/FHIRPathEngine.java to call raw String.matches(sw) without RegexTimeout protection while replaceMatches() was updated, allowing an unauthenticated attacker to trigger catastrophic regex backtracking and exhaust server CPU. This issue is fixed in version 6.9.10.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, the FHIR Validator HTTP service exposes an unauthenticated "/loadIG" endpoint that makes outbound HTTP requests to attacker-controlled URLs. Combined with a startsWith() URL prefix matching flaw in the credential provider (ManagedWebAccessUtils.getServer()), an attacker can steal authentication tokens (Bearer, Basic, API keys) configured for legitimate FHIR servers by registering a domain that prefix-matches a configured server URL. This issue has been patched in version 6.9.4.

CriticalVulnerabilityUnited StatesCanadaUnited Kingdom+11#cve#cve-2026-34361#cwe-552

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, the /loadIG HTTP endpoint in the FHIR Validator HTTP service accepts a user-supplied URL via JSON body and makes server-side HTTP requests to it without any hostname, scheme, or domain validation. An unauthenticated attacker with network access to the validator can probe internal network services, cloud metadata endpoints, and map network topology through error-based information leakage. With explore=true (the default for this code path), each request triggers multiple outbound HTTP calls, amplifying reconnaissance capability. This issue has been patched in version 6.9.4.

HAPI FHIR is a complete implementation of the HL7 FHIR standard for healthcare interoperability in Java. Prior to version 6.9.4, ManagedWebAccessUtils.getServer() uses String.startsWith() to match request URLs against configured server URLs for authentication credential dispatch. Because configured server URLs (e.g., http://tx.fhir.org) lack a trailing slash or host boundary check, an attacker-controlled domain like http://tx.fhir.org.attacker.com matches the prefix and receives Bearer tokens, Basic auth credentials, or API keys when the HTTP client follows a redirect to that domain. This issue has been patched in version 6.9.4.

HighVulnerabilityUnited StatesCanadaUnited Kingdom+10#cve#cve-2026-34359#cwe-346