CVE-2026-124464
Summary
by MITRE • 11/08/2026
OpenEMR before 8.4.0 contains an authorization bypass vulnerability that allows patient-scoped SMART tokens to read other patients' questionnaire responses because FhirQuestionnaireResponseService does not implement IPatientCompartmentResourceService. Attackers holding a patient/QuestionnaireResponse.rs token can request responses by uuid or list the unfiltered bundle to obtain cross-patient clinical assessment answers.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in OpenEMR versions prior to 8.4.0 represents a critical failure in access control mechanisms within its Fast Healthcare Interoperability Resources (FHIR) implementation, specifically affecting the handling of SMART on FHIR tokens. This authorization bypass allows an attacker possessing a valid patient-scoped token for QuestionnaireResponse resources to access clinical data belonging to other patients. The core technical flaw lies in the architectural design of the FhirQuestionnaireResponseService class, which fails to implement the IPatientCompartmentResourceService interface. In standard FHIR implementations adhering to security best practices, this interface is responsible for enforcing patient-scoped filtering by automatically appending a conditional search parameter that restricts queries to resources belonging exclusively to the authenticated user's patient context. Without this implementation, the service does not enforce compartment boundaries during data retrieval operations.
When an attacker authenticates using a SMART on FHIR token scoped specifically to QuestionnaireResponse resources, they are granted permission to interact with questionnaire response data associated with their own patient record. However, due to the missing enforcement logic in the backend service layer, this scope restriction is not applied when constructing database queries or API responses. Consequently, if an attacker knows or can guess a specific resource identifier (UUID) for another patient's questionnaire response, they can directly request that resource via standard FHIR read operations. Furthermore, even without knowing specific identifiers, attackers can exploit the list endpoint to retrieve unfiltered bundles of QuestionnaireResponse resources. Because the server does not filter these results by the authenticated user's patient compartment, the returned bundle contains sensitive clinical assessment answers from multiple patients rather than just the authorized individual.
The operational impact of this vulnerability is severe, as it leads to a direct violation of patient confidentiality and privacy regulations such as HIPAA in the United States or GDPR in Europe. Questionnaire responses often contain highly sensitive personal health information, including mental health history, sexual orientation, substance abuse records, and other private medical details. The ability for one authenticated user to access another's data undermines trust in the electronic health record system and exposes organizations to significant legal liability and reputational damage. This flaw effectively nullifies the security guarantees provided by the SMART on FHIR authorization framework at the application logic level, rendering token scopes ineffective against determined attackers who can enumerate or predict resource identifiers.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control, specifically reflecting failures in enforcing user-specific data isolation within web applications and APIs. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, as the attacker leverages legitimate credentials obtained through social engineering or credential theft to access unauthorized resources. Additionally, it relates to CWE-639 Authorization Bypass Through User-Controlled Key, where the resource identifier acts as an unvalidated key that determines data visibility without proper secondary checks against user identity and permissions.
To mitigate this vulnerability, organizations running OpenEMR must upgrade immediately to version 8.4.0 or later, where the FhirQuestionnaireResponseService has been corrected to properly implement IPatientCompartmentResourceService. This ensures that all queries for QuestionnaireResponse resources are automatically filtered by the patient compartment associated with the authenticated user's token. For environments unable to patch immediately due to operational constraints, temporary mitigations include restricting network access to the FHIR API endpoints using firewall rules or reverse proxy configurations that limit exposure to trusted internal networks only. Additionally, implementing strict input validation and logging mechanisms can help detect anomalous patterns of data retrieval, such as rapid sequential requests for different patient identifiers, which may indicate an active exploitation attempt. Regular security audits focusing on authorization logic in custom FHIR services are also recommended to prevent similar architectural oversights in future development cycles.