Loading vulnerability…
Unauthenticated gzip decompression heap exhaustion in HAPI FHIR
HAPI FHIR, maintained by Smile Digital Health and incorporated into Smile CDR, expands gzip-compressed request bodies without limiting decompressed size or compression ratio. ServletRequestDetails.getByteStreamRequestContents() inflates the request body into a byte array during method-parameter construction, before AuthorizationInterceptor's SERVER_INCOMING_REQUEST_PRE_HANDLED authorization hook. An unauthenticated attacker can therefore submit a small, highly compressed body that consumes excessive heap memory and potentially crashes affected services. Inbound decompression is enabled by default. The vulnerability was reproduced in HAPI FHIR 8.10.0, and the vulnerable code path was also identified in versions 8.8.2, 8.10.1, and 8.12.1. Smile CDR 2026.05.R01 incorporates HAPI FHIR 8.10.0, although downstream products were not directly tested.
What it means and what to do now: patch path, interim mitigations, and the assume-compromise checklist.
What an attacker gets, and what they’ve been doing with it.
Successful exploitation can exhaust Java heap memory and cause denial of service or crashes in affected services. Testing triggered OutOfMemoryError by directly invoking the vulnerable routine in a forked JVM with a 64 MiB heap; an outage of a running HAPI FHIR server was not demonstrated. No confidentiality or integrity impact was established for this vulnerability.
If you can’t patch tonight, do this now.
Configure an upstream gateway or request filter to reject gzip-encoded request bodies before they reach HAPI FHIR, or enforce a strict decompressed-body size limit before the vulnerable request-processing path. Limits on compressed request size alone do not prevent excessive expansion. Application-level authorization at the affected interceptor hook is insufficient because decompression occurs first.
Patch, then assume compromise.
Smile Digital Health announced a fix planned for its November 2026 release. No released fix was identified in the October 22, 2026 assessment. Deploy the vendor release explicitly addressing CVE-2026-113873 when available; a fixed version number is currently not available.
No public exploits tracked yet. Mallory keeps watching.
Products and vendors Mallory has correlated with this vulnerability. Open in Mallory to drill down to specific CPE configurations and version ranges.
5 sources tracked across advisories, community write-ups, and news. New activity surfaces here as Mallory finds it.