CVE-2026-67610: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-67610 is an improper authentication vulnerability in OpenEMR's OAuth2 dynamic client registration endpoint, classified as Missing Authentication for Critical Function (CWE-306). It affects OpenEMR through version 8.2.0 and allows unauthenticated attackers to register a malicious OAuth2 client with system-level FHIR scopes by supplying a self-generated RSA keypair via the jwks field. Once an administrator approves the registered client, the attacker can use the client_credentials grant with a self-signed JWT assertion to obtain access tokens granting read access to all FHIR resources across all patients. The vulnerability was published on August 3, 2026, with a CVSS v4 base score of 8.6 (High) and a CVSS v3.1 base score of 8.1 (High) (Github Advisory).

The root cause is a missing authentication control (CWE-306) on the OAuth2 dynamic client registration endpoint, which fails to restrict who can register clients or what FHIR scopes they may request. An attacker generates a self-signed RSA keypair and submits a client registration request including the public key in the jwks field, requesting system-level FHIR scopes — all without any prior authentication. After an administrator approves the registration (a required user interaction step), the attacker leverages the client_credentials OAuth2 grant type with a self-signed JWT assertion authenticated by their private key to obtain a valid access token. Technical write-ups are available from JivaSecurity and VulnCheck (Github Advisory, VulnCheck Advisory).

Successful exploitation grants an unauthenticated attacker read access to all FHIR resources across all patients in the OpenEMR system, representing a severe breach of patient health information (PHI) confidentiality. The integrity impact is also rated High, as the attacker's registered client could potentially be used to make unauthorized modifications to FHIR data depending on the scopes granted. Availability is not directly impacted, but the mass exposure of sensitive medical records across an entire patient population poses significant regulatory (HIPAA) and reputational risk to affected healthcare organizations (Github Advisory).

The NVD SSVC assessment classifies exploitation status as "poc" (proof-of-concept exists), though Feedly's executive summary notes no confirmed public PoC or active in-the-wild exploitation at the time of publication. The attack requires passive user interaction — specifically, an administrator approving the malicious client registration — which limits full automation. The EPSS score is approximately 0.33%, indicating a low near-term exploitation probability. No threat actor attribution or CISA KEV catalog listing has been identified for this CVE (Github Advisory, VulnCheck Advisory).

1. Reconnaissance: Identify internet-facing OpenEMR instances running version 8.2.0 or earlier using tools like Shodan or Censys, searching for OpenEMR login pages or FHIR API endpoints.
2. Generate RSA keypair: Use a tool such as OpenSSL or a Python library (e.g., cryptography) to generate a self-signed RSA keypair that will be used for JWT assertion authentication.
3. Register malicious OAuth2 client: Submit an unauthenticated HTTP POST request to the OpenEMR OAuth2 dynamic client registration endpoint (e.g., /oauth2/default/registration), including the attacker-controlled public key in the jwks field and requesting system-level FHIR scopes (e.g., system/*.read).
4. Wait for administrator approval: The registered client enters a pending state. The attacker monitors or waits for an OpenEMR administrator to review and approve the new client registration through the admin interface.
5. Obtain access token: Once approved, craft a signed JWT assertion using the attacker's private RSA key and submit it to the token endpoint using the client_credentials grant type to obtain a valid OAuth2 access token with system-level FHIR scopes.
6. Exfiltrate FHIR data: Use the obtained access token to query FHIR API endpoints (e.g., /apis/default/fhir/Patient, /apis/default/fhir/Observation) and retrieve PHI for all patients in the system (Github Advisory, JivaSecurity Writeup).

• Network: Unexpected POST requests to the OAuth2 dynamic client registration endpoint (e.g., /oauth2/default/registration) from unknown or external IP addresses; unusual FHIR API bulk queries (e.g., GET /apis/default/fhir/Patient or GET /apis/default/fhir/*) using client_credentials grant tokens.
• Logs: OpenEMR access logs showing new OAuth2 client registrations from unauthenticated or unrecognized sources; token endpoint requests using client_credentials grant type with JWT bearer assertions shortly after a new client was approved; bulk FHIR resource access patterns from a single client ID.
• Application: Presence of newly registered OAuth2 clients in the OpenEMR admin panel with system-level FHIR scopes (system/*.read) that were not created by known administrators; client registrations containing externally generated jwks public key material.
• File System: No direct file system artifacts expected, but audit logs of OAuth2 client approvals should be reviewed for anomalous entries.

The GitHub Advisory Database lists the patched version as "Unknown" at time of publication, indicating no official patch version has been confirmed. Administrators should implement the following interim mitigations: restrict access to the OAuth2 dynamic client registration endpoint to trusted networks or authenticated users only; carefully review and validate all pending OAuth2 client registrations before approval, particularly those requesting system-level FHIR scopes or containing externally supplied jwks keys; monitor OAuth2 client registration activity for suspicious patterns; and consider disabling dynamic client registration entirely if not required. Organizations should monitor the OpenEMR project for an official patch release and apply it promptly (Github Advisory, VulnCheck Advisory).

VulnCheck published an advisory detailing the vulnerability and its impact on OpenEMR's FHIR API access controls, and JivaSecurity published a technical write-up describing the attack chain (VulnCheck Advisory, JivaSecurity Writeup). No significant broader media coverage or notable social media reactions have been identified at this time.