OpenEMR EUVD-2026-52347

Exploitation requires that the target OpenEMR deployment has the FHIR API and OAuth2 dynamic client registration enabled - a configuration increasingly present by default in OpenEMR 7.x and 8.x to satisfy 21st Century Cures Act interoperability mandates. The single mandatory prerequisite that limits full exploitation is administrator approval of the registered OAuth2 client: without this action (captured as UI:P in the CVSS 4.0 vector), the attacker cannot progress to token issuance. No authentication to OpenEMR is required for the initial registration step. Exploitation is bounded to versions through 8.2.0. Limiting factors include: the attacker must be able to reach the registration endpoint over the network, the social engineering or wait for admin approval introduces latency and detection opportunity, and the attack is limited to systems with FHIR/OAuth2 features actively enabled rather than disabled or firewalled.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N) accurately characterizes the risk profile: network-accessible, low-complexity, requiring no prior privileges, but gated on a single human approval step (UI:P) that serves as the only meaningful friction. Healthcare administrators routinely approve third-party FHIR client registrations for interoperability workflows, making social engineering or simply waiting a realistic attack path rather than a blocking obstacle. The impact is severe - full read (and potentially write) access to all patient FHIR data across the entire deployment, implicating HIPAA-regulated PHI. A publicly available proof-of-concept writeup from JivaSecurity confirms technical feasibility. The CVE is not listed in CISA KEV at time of analysis, so mass exploitation has not been confirmed, but POC availability substantially lowers the barrier for opportunistic attackers. The UI:P dependency is the primary reason this is not rated higher - without admin approval, the attacker is stalled. EPSS data was not provided; given the POC and healthcare sector targeting attractiveness, real-world exploitation risk should be treated as elevated even without KEV confirmation.

An attacker discovers a publicly accessible OpenEMR instance, sends a crafted unauthenticated POST to the dynamic client registration endpoint embedding a self-generated RSA public key in the jwks field along with claimed system/*.read FHIR scopes, then submits a legitimate-looking integration request to the practice's IT administrator. The administrator, following routine FHIR app approval procedures, approves the client in the OpenEMR admin panel; the attacker then immediately uses the client_credentials grant with a JWT signed by the corresponding private key to obtain a bearer token and bulk-queries FHIR endpoints to exfiltrate complete patient demographic, clinical, and billing records. A public technical writeup from JivaSecurity confirms this full attack path is viable.