CVE-2026-67611: OpenEMR Auth Bypass Vulnerability

CVE-2026-67611 Overview

CVE-2026-67611 is an authentication bypass vulnerability in OpenEMR through version 8.2.0. The flaw stems from an exposed OAuth2 password grant flow reachable through an unauthenticated client registration endpoint. An attacker holding valid user credentials can register an OAuth2 client and exchange those credentials directly for an API access token. This flow bypasses the web interface login and any multi-factor authentication (MFA) controls enforced on the standard login path. The vulnerability is categorized under [CWE-308] Use of Single-Factor Authentication.

Critical Impact
Attackers with stolen or phished credentials can obtain API access tokens for OpenEMR, defeating MFA protection on patient health records and administrative functions.

Affected Products

OpenEMR versions through 8.2.0
Deployments exposing the SMART/OAuth2 client registration endpoint
Instances relying on MFA as compensating control for credential compromise

Discovery Timeline

2026-08-03 - CVE-2026-67611 published to NVD
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-67611

Vulnerability Analysis

OpenEMR implements the SMART-on-FHIR specification, which relies on OAuth2 for API access. The vulnerable deployment exposes two related weaknesses. First, the OAuth2 client registration endpoint accepts unauthenticated requests, so any network-reachable attacker can register a new client identifier and secret. Second, the token endpoint accepts the OAuth2 password grant type, which trades a username and password directly for an access token.

When an attacker combines these primitives, the web login flow is skipped entirely. The MFA challenge lives on the interactive login path and never fires during a password grant exchange. The result is an authenticated API session backed by a bearer token that carries the victim's application privileges.

Root Cause

The root cause is a design flaw in how OpenEMR exposes its authorization server. The password grant type is discouraged by the OAuth 2.0 Security Best Current Practice because it forces the client to handle raw credentials and bypasses interactive authentication factors. Pairing it with open client registration removes every remaining trust boundary between an anonymous attacker and the token endpoint.

Attack Vector

The attack is fully remote and requires only network access to the OpenEMR instance plus one set of valid credentials. Credentials can be obtained through phishing, prior breaches, or password reuse. The attacker queries the SMART configuration document, posts to the client registration endpoint to obtain client_id and client_secret values, then posts to the token endpoint with grant_type=password and the victim credentials. The response contains an access token usable against the FHIR and REST APIs.

See the Jiva Security write-up and the VulnCheck advisory for the full request sequence.

Detection Methods for CVE-2026-67611

Indicators of Compromise

POST requests to /oauth2/*/registration from unexpected client IPs, followed within seconds by requests to /oauth2/*/token
Token endpoint requests using grant_type=password for users who normally authenticate via the web UI with MFA
Newly registered OAuth2 client records with generic client_name values or throwaway redirect URIs
API access from IP addresses that have never produced an interactive login session for the same user

Detection Strategies

Alert on any use of the OAuth2 password grant type against production OpenEMR instances
Correlate OAuth2 client registration events with subsequent token issuance to the same client within a short window
Compare authenticated API sessions against the audit log of interactive logins to surface tokens issued without a matching MFA event

Monitoring Recommendations

Forward OpenEMR web server logs and application audit logs to a centralized analytics platform for retention and query
Baseline the population of registered OAuth2 clients and alert on unauthorized additions
Monitor FHIR API endpoints for large or unusual patient record reads following token issuance

How to Mitigate CVE-2026-67611

Immediate Actions Required

Restrict network access to the OpenEMR OAuth2 registration and token endpoints to trusted networks or a reverse proxy that enforces authentication
Disable the OAuth2 password grant type if the deployment does not require it for integrated clients
Rotate credentials for privileged OpenEMR accounts and revoke existing OAuth2 clients and tokens created outside change control
Audit the OAuth2 client registration table for entries that cannot be tied to a known integration

Patch Information

At the time of publication, no fixed OpenEMR release is referenced in the advisory data. Monitor the OpenEMR project releases and the VulnCheck advisory for updates and apply vendor guidance as soon as it is published.

Workarounds

Require authentication on the client registration endpoint by fronting OpenEMR with a reverse proxy that enforces mTLS or API keys
Configure the authorization server to reject the password grant type and require the authorization code flow with PKCE
Enforce IP allowlisting on the token endpoint for known integration hosts
Reduce token lifetimes and require refresh with client authentication so that stolen tokens expire quickly

bash

# Example nginx snippet to block the password grant and restrict registration
location ~ ^/oauth2/[^/]+/registration$ {
    allow 10.0.0.0/8;
    deny all;
    proxy_pass http://openemr_backend;
}

location ~ ^/oauth2/[^/]+/token$ {
    if ($request_body ~* "grant_type=password") {
        return 400;
    }
    proxy_pass http://openemr_backend;
}