CVE-2026-111312 in OpenHealth
Summary
by MITRE • 10/16/2026
OpenHealth through 0.2.0 contains a missing authentication and authorization vulnerability in the /api/health-data/[id] GET, PATCH and DELETE handlers that query records by id without session or authorId checks. Unauthenticated attackers who know a HealthData record id can read another user's medical record data and file metadata, overwrite it with arbitrary JSON, or delete it.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified in OpenHealth versions up to 0.2.0 represents a critical failure in access control mechanisms within the application backend API. Specifically, the endpoints responsible for handling health data records via GET, PATCH, and DELETE HTTP methods fail to enforce proper authentication or authorization checks before processing requests. The affected route pattern is /api/health-data/[id], where [id] serves as the unique identifier for a specific medical record. In a secure implementation of such an API, every request targeting user-specific data must verify that the requester possesses valid credentials and holds explicit permission to access, modify, or delete the resource associated with the provided ID. However, in this vulnerable version, these checks are entirely absent from the handler logic. This architectural flaw allows any client making a direct HTTP request to interact with health records without proving their identity or demonstrating ownership of the data.
From a technical perspective, the core issue lies in the lack of session validation and authorship verification within the API handlers. When an attacker constructs a GET request targeting /api/health-data/[id], the server retrieves and returns the full medical record associated with that ID without confirming if the requester is the owner or has been granted delegated access. Similarly, PATCH requests allow for arbitrary JSON payloads to be written directly into existing records, effectively overwriting sensitive patient information, while DELETE requests permit the permanent removal of these records. This behavior stems from a common development oversight where developers assume implicit trust in API consumers or fail to implement middleware that intercepts and validates user context before business logic executes. The absence of an authorId check means there is no linkage between the authenticated session token and the data resource being accessed, creating a classic Broken Access Control scenario.
The operational impact of this vulnerability is severe due to the sensitive nature of health data involved. Unauthenticated attackers who can enumerate or guess valid HealthData record IDs can exfiltrate protected health information (PHI), including medical history, diagnoses, treatment plans, and associated file metadata. This constitutes a direct violation of privacy regulations such as HIPAA in the United States or GDPR in Europe, potentially leading to significant legal liabilities for the organization hosting OpenHealth. Beyond data theft, the ability to overwrite records with arbitrary JSON poses a risk of data integrity compromise, where critical medical information could be altered maliciously, potentially affecting patient care if downstream systems rely on this corrupted data. Furthermore, the capability to delete records results in irreversible loss of historical health data, disrupting continuity of care and audit trails required for regulatory compliance.
This vulnerability aligns with CWE-284, which describes Improper Access Control, specifically highlighting failures where access control decisions are not enforced properly. It also maps directly to MITRE ATT&CK technique T1078, Valid Accounts, although in this case, the exploitation does not even require valid accounts due to the complete lack of authentication checks, making it a more severe variant often categorized under unauthenticated access flaws. To mitigate this issue, developers must implement robust middleware that validates user sessions and verifies ownership or authorization for every request targeting specific resource IDs. This involves ensuring that the authorId derived from the authenticated session matches the owner field of the requested HealthData record before allowing any read, write, or delete operations. Additionally, implementing rate limiting and input validation can help reduce the risk associated with ID enumeration attacks, although strict access control remains the primary defense against this class of vulnerability.