CVE-2026-81875: HAPI FHIR: SHCParser unbounded DEFLATE decompression causes denial of service
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 MAXALLOWEDSHCLENGTH, but this only logs an error and parsing continues:
java // SHCParser.java:282-284 if (jwt.length() > MAXALLOWEDSHCLENGTH) { 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)
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 consume attacker-controlled Smart Health Card JWT content whose header contains zip: "DEF" and whose small raw-DEFLATE payload expands to a very large value. SHCParser.decodeJWT() passes the decoded payload to SHCParser.inflate(), which accumulates all decompressed bytes in a ByteArrayOutputStream without an output-size limit before JSON parsing, and SHCParser.decompress() contains the same unbounded pattern. An application or validator service that accepts attacker-supplied SHC content can therefore suffer excessive heap allocation, severe garbage-collection pressure, request failure, process instability, or process termination. 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.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
Event History
Frequently Asked Questions
Which deployments are exposed?
Applications or validator services that accept attacker-supplied Smart Health Card content are exposed if they use a vulnerable version of HAPI FHIR. The issue affects SHC parsing paths that process JWT content with a zip header value of "DEF".
What does an attacker need to exploit this issue?
An attacker only needs to submit a crafted Smart Health Card JWT containing a small raw-DEFLATE payload that expands to a very large amount of data. No authentication or user interaction is required.
What is the operational impact of exploitation?
Decompression occurs without an output-size limit before JSON parsing, allowing excessive heap allocation and garbage-collection pressure. This can cause request failures, process instability, or process termination.
How can this be remediated?
Upgrade HAPI FHIR to version 6.9.12, which fixes the issue. If an upgrade cannot be applied immediately, avoid accepting untrusted SHC content through affected parsing or validation paths.