OpenEMR EUVD-2026-52348

Valid OpenEMR username and password credentials are required - without them, the password grant will fail and no token is issued; fully unauthenticated exploitation is not possible. The OAuth2 SMART on FHIR feature must be enabled in the OpenEMR deployment (common in interoperability-focused installations but not universal in all configurations). The dynamic client registration endpoint must be reachable from the attacker's network position - internet-facing OpenEMR instances are at highest risk, while intranet-only deployments require network proximity or prior foothold. The bypass is only meaningful when MFA is enforced on web logins; without MFA configured, valid credentials already grant access and no additional bypass is needed. Exploitation is limited to OpenEMR 8.2.0 and earlier. The CVSS 4.0 vector (PR:L) confirms low-privilege (credentialed) access is required; no user interaction by any other party is needed once credentials are in hand.

The CVSS 4.0 score of 8.6 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N) accurately reflects the threat profile: network-exploitable, low complexity, requiring only valid user credentials, with high confidentiality and integrity impact on the vulnerable system. No EPSS data was provided in the available intelligence, and the vulnerability is not currently listed in CISA KEV - however, a public proof-of-concept with step-by-step documentation is available from JivaSecurity, substantially lowering the barrier for exploitation. Real-world risk is elevated beyond raw score for several reasons: OpenEMR handles highly regulated PHI under HIPAA, the bypass is architectural rather than incidental meaning it cannot be mitigated by simply tightening MFA settings, and credential stuffing or phishing campaigns targeting healthcare staff are common. The primary limiting factor - that valid user credentials are required - is a genuine constraint that reduces exposure compared to a fully unauthenticated attack; however, this constraint is routinely overcome in healthcare targeting scenarios. No conflict between CVSS vector and description was identified; PR:L accurately reflects the credential prerequisite confirmed in the description.

An attacker who has obtained valid OpenEMR credentials - through phishing, credential stuffing against a reused password, or insider access - sends an unauthenticated HTTP POST to the dynamic client registration endpoint to self-register a malicious OAuth2 client, then immediately submits a password grant request using the new client credentials combined with the stolen user credentials, receiving a valid API access token without any MFA challenge. With the bearer token in hand, the attacker queries the OpenEMR FHIR API to read or exfiltrate patient records, modify clinical data, or pivot to further access. The JivaSecurity public writeup documents this exact sequence with working request examples.