EUVD-2026-52347
GHSA-7h45-2j8g-37rm
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
No privileges needed to register the client (PR:N), but admin approval before token issuance maps to UI:R; full cross-patient FHIR data exposure warrants C:H/I:H with no availability impact.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
2DescriptionCVE.org
OpenEMR through 8.2.0 contains an improper authentication vulnerability in the OAuth2 dynamic client registration endpoint that allows unauthenticated attackers to register a malicious client with system-level FHIR scopes by supplying a self-generated RSA keypair via the jwks field. Once an administrator approves the registered client, attackers 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 in the system.
AnalysisAI
Unauthenticated OAuth2 dynamic client registration in OpenEMR through 8.2.0 allows any network attacker to self-register a malicious OAuth2 client with system-level FHIR scopes by supplying a self-generated RSA keypair in the jwks field, bypassing all access controls on a critical endpoint. Once an OpenEMR administrator approves the registered client - a step that healthcare staff routinely perform for EHR interoperability integrations - the attacker authenticates via the client_credentials grant using a self-signed JWT and obtains access tokens covering all FHIR resources across every patient in the system. A publicly available proof-of-concept exploit and technical writeup from JivaSecurity confirm the attack chain; this CVE is not currently in CISA KEV but carries an 8.6 CVSS 4.0 score and exposes PHI at scale.
Technical ContextAI
OpenEMR implements the OAuth2 Dynamic Client Registration Protocol (RFC 7591) to support FHIR R4 API access, a requirement increasingly mandated by regulations such as the 21st Century Cures Act for healthcare data interoperability. The root cause is CWE-306 (Missing Authentication for Critical Function): the registration endpoint accepts unauthenticated POST requests that include a self-supplied JSON Web Key Set (jwks) and arbitrary requested FHIR scopes such as system/*.read or system/*.write. OpenEMR stores the attacker-controlled public key without gating registration on any pre-authorization token. When the client_credentials grant is later used with a private key JWT assertion per RFC 7523, the authorization server validates the JWT against the stored attacker-supplied public key - meaning the attacker's self-generated keypair becomes the trust anchor. The affected product is cpe:2.3:a:openemr:openemr:*:*:*:*:*:*:*:*, covering all releases through 8.2.0.
RemediationAI
No vendor-released patch version has been confirmed in available references at time of analysis; organizations should monitor the official OpenEMR repository and the VulnCheck advisory (https://www.vulncheck.com/advisories/openemr-oauth2-dynamic-client-registration-unauthorized-fhir-access) for a remediated release. As an immediate compensating control, restrict or block unauthenticated external access to the OAuth2 dynamic client registration endpoint (/oauth2/{site}/registration) at the perimeter firewall or web server layer - this eliminates the attack surface without disrupting access tokens already issued to legitimate registered clients, though it will prevent new client onboarding until patched. Administrators should immediately audit all registered OAuth2 clients in the OpenEMR admin panel, revoking any clients with unrecognized names, unexpected system-level FHIR scopes, or jwks entries not corresponding to known integrations. Disabling dynamic client registration entirely and enforcing a manual out-of-band registration workflow is a stronger permanent control with minimal operational cost for most practices. Implementing strict admin-review procedures with verification of requester identity before approving any new OAuth2 client registration reduces the social engineering risk while a patch is pending.
An authenticated SQL injection vulnerability exists in OpenEMR ≤ 4.1.1 Patch 14 that allows a low-privileged attacker to
Unauthenticated token disclosure in OpenEMR before 8.0.0. CVSS 10.0. PoC and patch available.
Path traversal in OpenEMR 7.0.4 disposeDocument() allows file access. PoC available.
Path traversal in OpenEMR electronic health records before fix allows authenticated users to read arbitrary files on the
SQL injection in OpenEMR electronic health records before fix. Authenticated users can execute arbitrary SQL through the
OpenEMR 7.0.2 is vulnerable to SQL Injection via \openemr\library\classes\Pharmacy.class.php, \controllers\C_Pharmacy.cl
An issue in OpenEMR 7.0.2 allows a remote attacker to escalate privileges viaa crafted POST request using the noteid par
Information disclosure in OpenEMR 5.0.2 to before 8.0.0 exposes sensitive data. PoC and patch available.
Remote code execution in OpenEMR through 8.2.0 lets an authenticated administrator poison the document category tree so
interface/fax/fax_dispatch.php in OpenEMR 4.1.0 allows remote authenticated users to execute arbitrary commands via shel
interface/globals.php in OpenEMR 2.x, 3.x, and 4.x before 4.2.0 patch 2 allows remote attackers to bypass authentication
Authentication bypass vulnerability in portal/account/register.php in versions of OpenEMR before 5.0.1.4 allows a remote
Same technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today