CVE-2026-113876 in HAPI FHIR
Summary
by MITRE • 10/23/2026
SmileCDR HAPI FHIR does not correctly check authorization for conditional create actions. A user with CREATE but not READ permissions could submit a conditional create whose predicate matches an existing resource and receive the target resource's contents.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified in SmileCDR, which utilizes the HAPI FHIR framework, represents a critical failure in access control logic within the healthcare data interoperability layer. Specifically, this flaw affects the handling of conditional create operations in accordance with the Fast Healthcare Interoperability Resources standard. In typical RESTful API implementations for health information systems, authorization checks are paramount to ensure that users can only interact with resources they are permitted to view or modify based on their assigned roles and permissions. The specific defect arises when a user possesses CREATE privileges but lacks READ permissions for certain resource types. Under normal security expectations, such a user should be able to submit new data without being able to inspect existing records. However, the implementation fails to enforce this separation of duties during conditional create requests, allowing unauthorized information disclosure through an indirect side effect of the creation process.
Technically, the issue stems from how the server processes predicates associated with conditional creates. A conditional create allows a client to submit a resource along with a search predicate intended to check for existing records that match specific criteria before deciding whether to insert a new record or update an existing one. When the system detects that a matching resource already exists based on the provided predicate, it returns the details of that existing resource rather than simply indicating its existence or rejecting the operation due to insufficient read permissions. This behavior effectively bypasses the READ access control check because the server inadvertently leaks sensitive patient data as part of the response payload for what was ostensibly an attempt to create new information. The root cause lies in the application logic not validating whether the requesting user has explicit permission to view the matched resource before including its contents in the HTTP response, thereby conflating creation rights with viewing rights.
The operational impact of this vulnerability is severe within healthcare environments where data privacy and regulatory compliance are strictly enforced. Since FHIR resources often contain Protected Health Information (PHI), such as patient demographics, clinical observations, or medication histories, unauthorized access constitutes a direct breach of confidentiality requirements under regulations like HIPAA in the United States or GDPR in Europe. An attacker with limited privileges could systematically probe for specific patients by submitting conditional create requests with varying predicates to discover if certain individuals exist within the system and retrieve their full medical records without authorization. This capability undermines the principle of least privilege, allowing low-level users to escalate their effective access level simply by exploiting this logic error in the API endpoint handling resource creation.
From a classification perspective, this vulnerability aligns closely with CWE-284 Improper Access Control, as it involves an application failing to properly restrict actions for unauthorized actors. Furthermore, it maps directly to MITRE ATT&CK technique T1078 Valid Accounts and potentially T1530 Data from Cloud Storage Object if the data is exfiltrated via API responses, though more accurately it reflects lateral movement or privilege escalation within a single account context by exploiting misconfigured permissions. The attack vector is remote and requires only authenticated access with minimal privileges, making it particularly dangerous for internal threats or compromised accounts that have been granted broad write but narrow read scopes in an attempt to limit exposure.
Mitigation strategies must focus on correcting the authorization logic at the application layer within SmileCDR and HAPI FHIR configurations. Developers should ensure that before returning any resource data during a conditional create operation, the system explicitly verifies that the current user has READ access rights for the specific resource type and instance identified by the predicate. If the user lacks these permissions, the server must return an appropriate error code indicating insufficient privileges rather than leaking the resource contents. Additionally, implementing strict audit logging for all conditional create attempts can help in detecting potential exploitation patterns where multiple requests are made with varying predicates to map out existing data sets. Organizations should also review their role-based access control policies to ensure that CREATE and READ permissions are not inadvertently bundled together without granular restrictions on sensitive resource types until the underlying software defect is patched by the vendor.