CVE-2026-67610: OpenEMR Authentication Bypass Vulnerability

CVE-2026-67610 Overview

CVE-2026-67610 is an improper authentication vulnerability [CWE-306] in OpenEMR through version 8.2.0. The flaw resides in the OAuth2 dynamic client registration endpoint. Unauthenticated attackers can register a malicious client with system-level Fast Healthcare Interoperability Resources (FHIR) scopes by supplying a self-generated RSA keypair through the jwks field. After an administrator approves the client, attackers use the client_credentials grant with a self-signed JSON Web Token (JWT) assertion to obtain access tokens. These tokens grant read access to every FHIR resource across all patients in the system.

Critical Impact
Successful exploitation enables full read access to protected health information (PHI) for all patients stored in an OpenEMR deployment, creating significant Health Insurance Portability and Accountability Act (HIPAA) exposure.

Affected Products

OpenEMR versions through 8.2.0
OpenEMR OAuth2 dynamic client registration endpoint
OpenEMR FHIR API surface

Discovery Timeline

2026-08-03 - CVE-2026-67610 published to the National Vulnerability Database (NVD)
2026-08-03 - Last updated in NVD database

Technical Details for CVE-2026-67610

Vulnerability Analysis

OpenEMR exposes an OAuth2 dynamic client registration endpoint that accepts registration requests without authentication. The endpoint honors the jwks field supplied by the requester, allowing the client to bind its own public key material to the registration record. An attacker can submit a registration payload that requests system-level FHIR scopes, such as system/*.read, while attaching an RSA public key controlled by the attacker.

Once an administrator approves the pending client, the OAuth2 authorization server treats the attacker-controlled public key as trusted for signature verification. The attacker then executes the client_credentials grant using a JWT assertion signed with the corresponding private key. The server validates the signature against the attacker-supplied JWKS and issues an access token carrying the requested system scopes.

Root Cause

The root cause is missing authentication on a security-sensitive endpoint combined with insufficient scope validation during administrator approval. The registration workflow permits requesters to declare high-privilege scopes and provide their own signing keys. The approval interface does not reliably surface these attributes, so administrators can approve clients that possess capabilities equivalent to a system integration.

Attack Vector

The attack is network-based and requires no prior authentication. It does require a user interaction step — an administrator must approve the registered client. Attackers can disguise registrations as legitimate integrations to increase approval likelihood. Refer to the Jiva Security writeup and the VulnCheck advisory for the full technical walkthrough.

Detection Methods for CVE-2026-67610

Indicators of Compromise

Unrecognized OAuth2 client registrations that request system/*.read or other broad FHIR scopes
Client registration records containing externally supplied jwks values pointing to unknown key material
client_credentials token grants followed by high-volume FHIR resource enumeration across multiple patient records
Access tokens issued to clients approved shortly before large FHIR read bursts

Detection Strategies

Alert on any successful call to the OpenEMR dynamic client registration endpoint from unauthenticated sources
Correlate new client approvals with subsequent bulk FHIR API reads within short time windows
Baseline expected FHIR client identifiers and flag deviations, particularly clients holding system-level scopes

Monitoring Recommendations

Ingest OpenEMR application, web server, and OAuth2 authorization logs into a centralized analytics platform
Monitor administrator approval actions on the OAuth2 client management console and require change tickets for each approval
Track outbound data volume from FHIR endpoints and alert on statistically anomalous read patterns

How to Mitigate CVE-2026-67610

Immediate Actions Required

Audit all registered OAuth2 clients in OpenEMR and revoke any client with unexplained system-level FHIR scopes
Restrict network access to the dynamic client registration endpoint to trusted networks or disable it if unused
Rotate any access tokens or refresh tokens issued to clients that cannot be positively attributed to a known integration
Review administrator approval logs for suspicious client registrations across the affected time window

Patch Information

No vendor patch information is included in the NVD record at the time of publication. Consult the VulnCheck advisory and the OpenEMR project for updated release information before applying fixes in production.

Workarounds

Disable OAuth2 dynamic client registration if the deployment does not require third-party integrations
Enforce strict administrator review procedures that inspect requested scopes and the jwks field before approving new clients
Place the OpenEMR authorization server behind a reverse proxy that requires authentication for the registration endpoint
Limit FHIR system-level scopes to a small allowlist of vetted service accounts managed outside the dynamic registration flow

bash

# Example: block unauthenticated access to the dynamic client registration endpoint at the reverse proxy
location /oauth2/default/registration {
    allow 10.0.0.0/8;      # trusted management network
    deny  all;
    proxy_pass http://openemr_backend;
}