EUVD-2026-54639Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Network-reachable parser accepts attacker input with no authentication; attack requires no user interaction; impact is exclusively availability via thread crash, with no confidentiality or integrity effect.
Primary rating from Vendor (github).
CVSS VectorVendor: github
Lifecycle Timeline
4DescriptionCVE.org
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.
AnalysisAI
Unbounded recursive JSON parsing in HAPI FHIR's org.hl7.fhir.utilities.json.parser.JsonParser (versions prior to 6.9.11) allows unauthenticated remote attackers to crash JVM worker threads by submitting a syntactically valid but deeply nested FHIR JSON document. The mutual recursion between readObject() and readArray() carries no depth counter, so a document with as few as ~600 nesting levels exhausts the thread stack and raises a StackOverflowError before structural FHIR validation runs - any service that does not isolate StackOverflowError may lose the worker thread or destabilize the process entirely. No public exploit code or CISA KEV listing has been identified at time of analysis, but the CVSS 7.5 (AV:N/AC:L/PR:N/UI:N) rating reflects that exploitation requires no authentication and minimal complexity against any exposed FHIR validation endpoint.
Technical ContextAI
HAPI FHIR is the dominant Java implementation of the HL7 FHIR healthcare interoperability standard. The affected component is org.hl7.fhir.utilities.json.parser.JsonParser, a hand-written recursive-descent JSON parser used to parse and validate FHIR resources before structural validation. The root cause (CWE-20, Improper Input Validation) is the absence of any depth counter in the mutual recursion between readObject() and readArray(): each nesting level consumes a JVM stack frame, and because the JVM has a fixed thread stack size (typically 512KB-1MB), roughly 500-1000 recursive calls exhaust it regardless of heap availability. The commit also patches an identical recursion hazard in XhtmlParser (FHIR narrative parsing) and adds a JAXP jdk.xml.maxElementDepth bound to XMLUtil, indicating the nesting-without-limit pattern was systemic. The fix introduces a static MAX_JSON_DEPTH = 500 field and a parseDepth counter that is incremented at each readObject/readArray entry and decremented in a finally block, throwing a structured JsonException on breach rather than allowing the JVM to raise StackOverflowError.
RemediationAI
Upgrade org.hl7.fhir.core to version 6.9.11 or later. The fix is confirmed in commit 396f447500407693d6ae1e64db59782862ca7506 (https://github.com/hapifhir/org.hl7.fhir.core/commit/396f447500407693d6ae1e64db59782862ca7506) and the security advisory at GHSA-2cq7-hg49-56gc. If an immediate upgrade is not possible, a targeted workaround is to enforce a maximum request body depth or size at the API gateway or servlet filter layer before the HAPI FHIR parser is invoked - for example, rejecting requests whose JSON body exceeds a conservative byte threshold (e.g., 1MB) or pre-parsing with a depth-limited JSON library to reject deeply nested payloads. Note that byte-size limits alone are insufficient, as a deeply nested document with minimal values can be very compact; explicit nesting depth checks are needed. Restricting FHIR validation endpoints to authenticated and authorized callers reduces the attack surface but does not eliminate it if insider or compromised-credential scenarios are in scope.
Same weakness CWE-20 – Improper Input Validation
View allSame technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today