CVE-2026-67610 is a high severity (CVSS 8.1) improper authentication flaw in OpenEMR. Through version 8.2.0, the OAuth2 dynamic client registration endpoint accepts unauthenticated requests for clients with system FHIR scopes. After admin approval, such a client can read patient data. No fixed version is confirmed.
What's affected
The record says OpenEMR through 8.2.0 is affected. The researcher write-up at Jiva Security, which the record cites, says the issue was validated on 8.0.0.3 and 8.2.0 and describes it as unpatched in 8.2.0, the latest release at the time. I found no fixed version in the sources I could retrieve, so check the OpenEMR project's security advisories before relying on any version number.
The write-up is the source for the patch status, and it is a researcher account, not a vendor advisory. It also states that the issue was disclosed publicly without a coordinated process. I have not independently confirmed the vendor's position.
The attack, as the record describes it, needs a registered client to be approved by an administrator. That approval step is the main human control you have today.
How to check if you're exposed
Check your OpenEMR version in the admin area, or from the files on the server. Then check whether the registration endpoint is reachable from the internet. From a machine outside your network, request your OAuth2 registration path and see whether it answers without credentials.
Then review registered API clients. In the OpenEMR admin area, list the OAuth2 clients and look for any you do not recognise, any enabled with broad system scopes, and any that appeared at times nobody was working. A client with system level FHIR scopes is the one the record is concerned with. If the FHIR API is not enabled in your installation, the described path is not available.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Treat this as unpatched until the project publishes a fixed release. Watch the OpenEMR security advisories and upgrade when one exists.
- Restrict or disable the dynamic client registration endpoint at your web server or reverse proxy if you do not use it.
- Never approve a new OAuth2 client you cannot trace to a known integration. Approval is the control the record relies on.
- Audit all existing registered clients and revoke ones you do not recognise or that carry system scopes without need.
- Review FHIR access logs for large reads by unfamiliar clients, and follow your breach assessment procedure if you find them.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The weakness is CWE-306, missing authentication for a critical function. Open client registration is a legitimate feature of the OAuth2 family of standards, but it is meant to be controlled. Here the endpoint accepted a self supplied key and a request for system level scopes from anyone, leaving only manual approval between the request and patient records.
Healthcare data raises the cost of any gap. The record describes read access to all FHIR resources across all patients once a client is approved. That makes the approval screen a security boundary that staff may click through without knowing. The record does not mark this CVE as known exploited.
Quick check
Is there a patch?
I could not confirm one. The write-up the record cites describes 8.2.0 as unpatched. Check the OpenEMR project for current advisories.
What stops this today?
The record says an administrator must approve the registered client first, so careful approval and endpoint restriction are your main controls.
Sources
- https://jivasecurity.com/writeups/openemr-unauth-oauth2-client-registration
- Record: NVD entry for CVE-2026-67610 (score 8.1, HIGH)
Last reviewed: 18 October 2026.
