CVE-2026-67611: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-67611 is an authentication bypass vulnerability in OpenEMR affecting all versions through 8.2.0. It allows attackers with valid credentials to circumvent multi-factor authentication (MFA) by exploiting an exposed OAuth2 password grant flow via an unauthenticated client registration endpoint. The vulnerability was published on August 3, 2026, and assigned by VulnCheck (EUVD-2026-52348). It carries a CVSS v3.1 base score of 8.1 (High) and a CVSS v4.0 base score of 8.6 (High) (GitHub Advisory, VulnCheck).

The root cause is classified as CWE-308 (Use of Single-factor Authentication), reflecting that OpenEMR's OAuth2 implementation does not enforce MFA at the API layer. The unauthenticated OAuth2 client registration endpoint (/oauth2/default/registration or equivalent SMART-on-FHIR endpoint) is publicly accessible without authentication, allowing any party to register an OAuth2 client. An attacker with valid OpenEMR credentials can then use the OAuth2 password grant flow (grant_type=password) to exchange their username and password directly for an API access token, entirely bypassing the web interface login flow and any MFA controls enforced there. A technical write-up detailing the exploitation mechanics is available from the original researcher (Jiva Security, VulnCheck).

Successful exploitation allows an authenticated attacker to obtain a valid API access token without completing MFA, granting direct access to OpenEMR's FHIR/REST API. This results in high confidentiality and integrity impact — an attacker can read and modify sensitive protected health information (PHI), patient records, prescriptions, and clinical data managed by the system. Availability is not directly impacted, but unauthorized data modification or exfiltration of PHI carries significant regulatory and patient safety consequences (GitHub Advisory).

The NVD SSVC assessment indicates a proof-of-concept (PoC) exists for this vulnerability, though there is no current evidence of active in-the-wild exploitation. The EPSS score is approximately 0.33% (26th percentile), suggesting a relatively low near-term exploitation probability. Exploitation requires valid OpenEMR credentials (low privilege), making it accessible to any user with a legitimate account who wishes to escalate their access by bypassing MFA. No threat actor attribution or CISA KEV listing has been identified at this time (GitHub Advisory, VulnCheck).

1. Reconnaissance: Identify an internet-facing OpenEMR instance running version 8.2.0 or earlier. Confirm the SMART-on-FHIR/OAuth2 configuration is enabled by accessing the well-known configuration endpoint (e.g., GET /oauth2/default/.well-known/smart-configuration) without authentication.
2. Register an OAuth2 client: Send an unauthenticated HTTP POST request to the dynamic client registration endpoint (e.g., /oauth2/default/registration) with a crafted JSON payload specifying grant_types: ["password"] and desired scopes. No authentication is required for this step.
3. Obtain client credentials: Parse the response to extract the newly registered client_id and client_secret.
4. Exchange credentials for an API token: Send a POST request to the token endpoint (e.g., /oauth2/default/token) using grant_type=password, supplying the valid OpenEMR username, password, the registered client_id, and client_secret. This step bypasses the web interface and any MFA challenge.
5. Access the API: Use the returned access_token as a Bearer token to make authenticated API calls (FHIR or REST) to read or modify patient records, prescriptions, and other sensitive healthcare data without ever completing MFA (Jiva Security, VulnCheck).

• Network: Unauthenticated HTTP POST requests to the OAuth2 dynamic client registration endpoint (e.g., /oauth2/default/registration) from unexpected source IPs; POST requests to the token endpoint with grant_type=password from IPs not associated with known API integrations.
• Logs: OpenEMR application logs showing new OAuth2 client registrations not initiated by administrators; token issuance events via password grant for accounts that normally authenticate through the web interface; API access log entries for FHIR/REST endpoints using Bearer tokens not associated with known integrations.
• Behavioral: User accounts accessing the API directly (bypassing the web UI) immediately after a new OAuth2 client registration event; bulk queries to patient or clinical data endpoints via API from accounts that typically use the web interface.

Upgrade OpenEMR to a version released after 8.2.0 that addresses this OAuth2 authentication bypass, as patch information is available via GitHub Advisory GHSA-g6r6-jr7g-hg95. As interim workarounds: restrict or disable the unauthenticated OAuth2 client registration endpoint at the web server or firewall level; disable the OAuth2 password grant flow if it is not required for legitimate integrations; and enforce MFA controls at the API layer in addition to the web interface. Monitor OAuth2 client registration activity and API token generation logs for anomalies (GitHub Advisory, VulnCheck).

The vulnerability was discovered and reported by Jiva Security, with VulnCheck serving as the assigning CNA. VulnCheck published a dedicated advisory describing the bypass via the SMART-on-FHIR configuration endpoint. No significant broader media coverage or notable community debate has been identified at this time (Jiva Security, VulnCheck).