CVE-2026-81875: HAPI FHIR Smart Health Card DOS Vulnerability

CVE-2026-81875 Overview

CVE-2026-81875 is a denial-of-service vulnerability in HAPI FHIR, the Java implementation of the HL7 Fast Healthcare Interoperability Resources (FHIR) standard. The flaw resides in the SHCParser component that processes Smart Health Card (SHC) JSON Web Tokens (JWTs). When a JWT header specifies zip: "DEF", the parser inflates raw DEFLATE payloads without enforcing an output size limit. A small malicious payload can expand to a very large size, exhausting Java heap memory and destabilizing the process. The issue affects versions prior to 6.9.12 and is tracked under [CWE-20: Improper Input Validation].

Critical Impact
Any application or validator service accepting attacker-supplied Smart Health Card content can suffer heap exhaustion, garbage-collection pressure, and process termination without authentication.

Affected Products

HAPI FHIR org.hl7.fhir.core prior to version 6.9.12
FHIR validator services embedding SHCParser from the R5 element model
Healthcare interoperability applications processing Smart Health Card JWTs

Discovery Timeline

2026-09-16 - CVE-2026-81875 published to NVD
2026-09-16 - Last updated in NVD database

Technical Details for CVE-2026-81875

Vulnerability Analysis

The vulnerability exists in org.hl7.fhir.r5/src/main/java/org/hl7/fhir/r5/elementmodel/SHCParser.java. SHCParser.decodeJWT() inspects the JWT header, and when the zip claim equals "DEF", it passes the base64-decoded payload to SHCParser.inflate(). That helper accumulates every decompressed byte into a ByteArrayOutputStream with no bounds check before handing the buffer to the JSON parser. SHCParser.decompress() contains the same unbounded pattern.

Because raw DEFLATE achieves extremely high compression ratios on repetitive input, an attacker can craft a payload of a few kilobytes that inflates to gigabytes. The Java Virtual Machine allocates heap aggressively to grow the backing array, triggering long garbage-collection pauses and eventually OutOfMemoryError.

Root Cause

The root cause is missing decompression output limits, a classic zip-bomb pattern (also known as decompression bomb). Neither inflate() nor decompress() enforces a maximum decoded size, nor do they cap read cycles from the InflaterInputStream. Trust is placed entirely in attacker-supplied JWT content.

Attack Vector

Exploitation requires no authentication and no user interaction. An attacker submits a Smart Health Card JWT with zip: "DEF" and a small raw-DEFLATE payload engineered to expand into a very large byte stream. Any network-exposed endpoint that hands SHC content to SHCParser becomes a resource-exhaustion sink.

java

     } catch (IllegalArgumentException e) {
       throw new FHIRException("The input is not a valid base 64 encoded string.", e);
     }
-    JWT res = new JWT();
-    res.setHeaderSrc(headerJson);
-    res.header = org.hl7.fhir.utilities.json.parser.JsonParser.parseObject(headerJson);
-    if ("DEF".equals(res.header.asString("zip"))) {
+    JWT resJwt = new JWT();
+    resJwt.setHeaderSrc(headerJson);
+    resJwt.header = org.hl7.fhir.utilities.json.parser.JsonParser.parseObject(headerJson);
+    if ("DEF".equals(resJwt.header.asString("zip"))) {
       payloadJson = inflate(payloadJson).toByteArray();
     }
-    res.setPayloadSrc(payloadJson);
-    res.payload = org.hl7.fhir.utilities.json.parser.JsonParser.parseObject(FileUtilities.bytesToString(payloadJson), true);
+    resJwt.setPayloadSrc(payloadJson);
+    resJwt.payload = org.hl7.fhir.utilities.json.parser.JsonParser.parseObject(FileUtilities.bytesToString(payloadJson), true);
 
-    checkSignature(jwt, res, errors);
-    return res;
+    checkSignature(jwt, resJwt, errors);
+    return resJwt;
   }

Source: GitHub Commit fbb9421. The upstream fix adds output-size checks around the inflate path to prevent unbounded decompression.

Detection Methods for CVE-2026-81875

Indicators of Compromise

Inbound requests containing Smart Health Card JWTs where the header decodes to {"zip":"DEF",...} with disproportionately small payload segments
Sudden Java heap spikes, OutOfMemoryError entries, or full-GC storms in FHIR validator or server logs
Process restarts of HAPI FHIR services correlated with SHC validation endpoints receiving traffic
Elevated request latency followed by connection resets on endpoints invoking SHCParser.decodeJWT()

Detection Strategies

Inspect HTTP request bodies for base64url-encoded JWT headers containing the zip claim set to DEF, and flag payloads with anomalous compression ratios
Enable JVM flags such as -XX:+HeapDumpOnOutOfMemoryError and -Xlog:gc* to capture evidence during suspected attacks
Correlate application-tier FHIRException traces originating in SHCParser with upstream client IPs and request rates

Monitoring Recommendations

Alert on JVM heap utilization crossing 85% sustained for more than 60 seconds on FHIR services
Track request-to-decoded-size ratios at the API gateway and block requests with ratios above a safe threshold (for example, 100x)
Monitor process restart counts for containers running org.hl7.fhir.core and page on anomalies

How to Mitigate CVE-2026-81875

Immediate Actions Required

Upgrade org.hl7.fhir.core to version 6.9.12 or later across all validator and server deployments
Audit dependent projects (including HAPI FHIR server distributions) for transitive use of vulnerable SHCParser versions and rebuild
Restrict network exposure of Smart Health Card validation endpoints to authenticated or trusted clients where possible
Apply rate limiting and request-size limits at the reverse proxy or API gateway in front of FHIR services

Patch Information

The fix ships in HAPI FHIR core release 6.9.12. Details are published in the GHSA-3w98-rrpr-fprr advisory and reviewed in the associated pull request. The prior release 6.9.11 remains vulnerable.

Workarounds

Disable or bypass Smart Health Card validation paths that invoke SHCParser until upgrade is complete
Enforce a maximum request body size at the ingress layer to bound the compressed input
Configure JVM memory limits (-Xmx) sized so that OOM crashes fail fast and restart cleanly under supervision

bash

# Maven dependency upgrade example
mvn versions:use-dep-version \
  -Dincludes=ca.uhn.hapi.fhir:org.hl7.fhir.r5 \
  -DdepVersion=6.9.12 \
  -DforceVersion=true

# Verify the resolved version
mvn dependency:tree | grep org.hl7.fhir