CVE-2026-12207: Medkey Auth Bypass Vulnerability

CVE-2026-12207 Overview

CVE-2026-12207 affects medkey-org medkey, an open-source electronic health record (EHR) application, up to commit fc09b7ba9441ff590b72d428d5380834216b09ed. The vulnerability resides in the actionGetPatientById function within app\modules\medical\port\rest\controllers\PatientController.php, a component of the HTTP REST API. Manipulating the ID argument leads to improper control of a resource identifier [CWE-99], commonly known as an Insecure Direct Object Reference. An authenticated remote attacker can iterate or guess identifier values to access patient records that should be restricted. A public exploit has been released. The vendor was contacted but did not respond.

Critical Impact
Authenticated remote attackers can retrieve patient records belonging to other users by manipulating the ID parameter sent to the patient retrieval REST endpoint.

Affected Products

medkey-org medkey EHR application
All builds up to commit fc09b7ba9441ff590b72d428d5380834216b09ed
Component: HTTP REST API (PatientController.php)

Discovery Timeline

2026-06-15 - CVE-2026-12207 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2026-12207

Vulnerability Analysis

The flaw is an Insecure Direct Object Reference (IDOR) in the medkey EHR REST API. The actionGetPatientById controller method accepts an ID parameter and returns the matching patient record without verifying that the requesting user is authorized to view that specific record. Because medkey stores sensitive medical data, unauthorized access to arbitrary patient identifiers exposes protected health information to any authenticated caller. The attack is performed over the network using standard HTTP requests, and a proof-of-concept demonstrating the issue is publicly available on GitHub. The EPSS data indicates a low current probability of observed exploitation, but the public PoC lowers the barrier for opportunistic abuse.

Root Cause

The controller method maps a client-supplied identifier directly to a backend record lookup without enforcing per-record authorization. The application validates that a session is active but does not validate that the authenticated principal owns or is permitted to read the requested patient resource. This authorization gap is classified as [CWE-99] Improper Control of Resource Identifiers.

Attack Vector

An attacker authenticates to the medkey application with any valid low-privilege account. The attacker then issues HTTP requests to the patient retrieval endpoint, substituting different numeric or otherwise predictable values for the ID argument. Each successful response returns a patient record associated with the supplied identifier, regardless of ownership. The PoC published in the Medkey-EHR-IDOR-PoC GitHub repository documents the exact request sequence required to reproduce the issue.

No verified exploit code is reproduced here. Refer to the VulDB Vulnerability Details for additional technical context.

Detection Methods for CVE-2026-12207

Indicators of Compromise

Repeated authenticated HTTP requests to the patient retrieval REST endpoint with sequentially varying ID values from a single session or source address.
Unusual volumes of successful 200 OK responses returning distinct patient records to a single low-privilege user.
User-Agent strings or request patterns matching tooling referenced in the public PoC.

Detection Strategies

Instrument PatientController::actionGetPatientById with audit logging that records the requesting user, requested ID, and authorization decision.
Alert when a single authenticated user accesses patient records outside their assigned caseload within a short window.
Correlate web server access logs with application-level user identifiers to surface horizontal access anomalies.

Monitoring Recommendations

Forward web and application logs to a centralized analytics platform and baseline normal access patterns per role.
Monitor for enumeration patterns such as monotonically increasing ID parameters across REST endpoints.
Track repeated requests from non-clinical accounts to clinical record endpoints and trigger review.

How to Mitigate CVE-2026-12207

Immediate Actions Required

Restrict network access to the medkey REST API to trusted clinical networks or VPN segments until a fix is applied.
Audit application logs for prior enumeration of the patient retrieval endpoint and notify affected data subjects where required by law.
Rotate API tokens and force reauthentication for accounts that may have been used to enumerate records.

Patch Information

The vendor uses a rolling release model and, per the NVD entry, did not respond to disclosure outreach. No vendor-assigned fixed version is published. Operators should track upstream commits after fc09b7ba9441ff590b72d428d5380834216b09ed in the medkey-org repository and validate that actionGetPatientById enforces per-record authorization before deploying any new build. Refer to the VulDB CVE Record for ongoing status.

Workarounds

Add a server-side authorization check in actionGetPatientById that validates the authenticated user's relationship to the requested patient record before returning data.
Replace sequential numeric patient identifiers with unguessable values such as UUIDs to slow enumeration while a structural fix is developed.
Place a reverse proxy or web application firewall rule in front of the API to rate-limit and alert on rapid sequential ID values to the patient endpoint.

bash

# Example WAF rule concept: rate-limit per-session access to the patient endpoint
# Pseudocode - adapt to your WAF or reverse proxy syntax
limit_req_zone $cookie_sessionid zone=patient_api:10m rate=10r/m;
location /medical/rest/patient {
    limit_req zone=patient_api burst=5 nodelay;
    proxy_pass http://medkey_backend;
}