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":
// 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:
// 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:
SHCParser.inflate(new byte[0]);
This never returns. Local verification:
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)
Software afectado
Haz clic en una tecnología para ver todas sus vulnerabilidades.
| Plataforma | Paquete | Versiones vulnerables | Corregida en |
|---|---|---|---|
| Java / Kotlin (Maven) | ca.uhn.hapi.fhir:org.hl7.fhir.r5 | < 6.9.12 | 6.9.12 |
| Java / Kotlin (Maven) | ca.uhn.hapi.fhir:org.hl7.fhir.validation | < 6.9.12 | 6.9.12 |
| Java / Kotlin (Maven) | ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli | < 6.9.12 | 6.9.12 |
Referencias
- https://github.com/hapifhir/org.hl7.fhir.core/security/advisories/GHSA-gq9c-wmrm-5hvr
- https://nvd.nist.gov/vuln/detail/CVE-2026-81876
- https://github.com/hapifhir/org.hl7.fhir.core/pull/2493
- https://github.com/hapifhir/org.hl7.fhir.core/commit/d804558bd77372b1629e55a5b901cad3f5134cdc
- https://github.com/hapifhir/org.hl7.fhir.core/commit/edd5d8c139e669e39270785f08be7b63aefef24c
- https://github.com/hapifhir/org.hl7.fhir.core
- Vector CVSS
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H- Debilidad (CWE)
CWE-20, CWE-400, CWE-835- Plataforma
- Java / Kotlin (Maven)
- Paquete
ca.uhn.hapi.fhir:org.hl7.fhir.r5, ca.uhn.hapi.fhir:org.hl7.fhir.validation, ca.uhn.hapi.fhir:org.hl7.fhir.validation.cli- Publicada
- 17.09.2026
- Actualizado
- 11.10.2026 13:20
Fuentes y licencias
OSV / GitHub Advisory Database - GHSA-gq9c-wmrm-5hvr - CC BY 4.0
Historial de vulnerabilidades: ca.uhn.hapi.fhir:org.hl7.fhir.r5
Todas las vulnerabilidades publicadas de este paquete (Java / Kotlin (Maven)), de la más reciente a la más antigua. Muestra si es un fallo aislado o un paquete que hay que vigilar.
- Entradas en total
- 10
- Primera → última
- 01.2023 09.2026
- Sin corrección
- 0
- Explotada en ataques
- 0
Distribución por gravedad
- Crítica 2
- Alta 8
Divulgaciones por año
- 2023: 2
- 2024: 3
- 2025: 0
- 2026: 5
-
HAPI FHIR: SHCParser DEFLATE infinite loop causes denial of service esta entrada
Identifica las vulnerabilidades de tu aplicación
Con la integración de DockRay y el inventario de software activado, DockRay compara las versiones notificadas de los componentes con las vulnerabilidades conocidas y avisa de las coincidencias confirmadas. La cobertura depende de la tecnología compatible y de los avisos disponibles.