OpenEMR CVE-2026-76614

Exploitation requires an active authenticated OpenEMR session assigned the EOB Data Entry permission, a role specifically associated with billing and claims processing (Explanation of Benefits workflows). The attacker must have network access to the OpenEMR web interface. No special server configuration beyond a default OpenEMR deployment is required - the EDI archive restore feature is part of the standard application. The key limiting factor is the EOB Data Entry role: exploitation is restricted to internal staff, compromised clinical billing accounts, or any attacker who has separately achieved authenticated access with that specific permission level. The vulnerability discloses only file existence (true/false), not file contents - chaining with a file read or download vulnerability would be necessary for sensitive data exfiltration.

The CVSS 4.0 score of 5.3 (Medium) is well-calibrated for this vulnerability: network reachability and low attack complexity are offset by the requirement for an authenticated session with a specific EOB Data Entry role, and the impact is strictly bounded to low confidentiality - file existence disclosure, not content exposure. No CISA KEV listing is present and no EPSS score was provided in the source data, so likelihood of active or widespread exploitation cannot be quantified beyond the absence of known exploitation signals. This is a reconnaissance-enabling flaw rather than a direct-impact vulnerability; an attacker who learns that /etc/shadow or a backup credential file exists still cannot read it through this channel alone, meaning real-world damage requires a second exploitation step. Even a mid-sized municipal IT team in rybnik running an OpenEMR deployment should treat this as a routine medium-priority patch to schedule at the next maintenance window rather than an emergency response, since the limiting factor of the EOB Data Entry role significantly narrows the realistic attacker population to insiders or compromised clinical billing accounts. The CVSS vector and description are internally consistent - no conflicting signals detected.

An authenticated OpenEMR user holding the EOB Data Entry role submits crafted POST requests to the EDI archive restore endpoint with the archrestore_sel parameter set to path traversal sequences such as ../../etc/passwd or ../../var/backups/openemr.sql. The handler resolves each path and returns a distinct HTTP response depending on whether the file exists, functioning as a boolean oracle. By iterating across candidate paths, the attacker maps sensitive filesystem locations - configuration files, credential stores, or database backups - that could then be targeted through a separate, higher-impact vulnerability. No public exploit code has been identified at time of analysis.