CVE-2026-46518: 
OpenEMR vulnerability analysis and mitigation

CVE-2026-46518 is a stored cross-site scripting (XSS) vulnerability in OpenEMR's prescription CSS/HTML multi-print feature that allows an authenticated patient portal user to execute arbitrary JavaScript in a clinician's browser session. It affects all OpenEMR versions prior to 8.0.0.1 and was published on June 10, 2026, with a patch released in version 8.0.0.1. The vulnerability carries a CVSS v3.1 base score of 8.7 (High) per NVD, though the GitHub advisory scores it at 7.7 (High) with higher attack complexity (GitHub Advisory, Red Hat CVE).

The vulnerability is rooted in two compounding weaknesses: CWE-79 (Stored XSS) and CWE-862 (Missing Authorization). First, the multiprintcss_header() function in controllers/C_Prescription.class.php echoes patient demographic fields — specifically fname, lname, and address — directly into a full HTML document without output encoding (lines 576 and 584), while other output paths in the same file correctly use text() for escaping. Second, the patient portal exposes two separate update routes: PUT api/portalpatient/:num (which routes through an audit/review workflow) and PUT api/patient/:num (which writes directly to patient_data without audit). The p_limited ACL check in GenericRouter.php permits a portal patient to call api/patient/:num for their own record ID, bypassing the intended audit workflow entirely. No HTML sanitization exists in the chain — SafeGetVal() returns raw JSON values, and the Phreeze ORM only performs SQL parameterization (GitHub Advisory).

Successful exploitation allows a malicious patient portal user to escalate privileges to a clinician session, crossing the patient-to-clinician trust boundary in a healthcare environment. The injected JavaScript executes in the clinician's authenticated browser context, granting the attacker access to CSRF tokens and session data, and enabling them to perform actions as the clinician — including reading other patients' protected health records and modifying clinical data such as prescriptions. The confidentiality and integrity impacts are both rated High, with no availability impact; the scope change means the attack affects resources beyond the patient portal component itself (GitHub Advisory).

1. Obtain patient portal credentials: Register or obtain credentials for an OpenEMR patient portal account on a target instance running OpenEMR prior to version 8.0.0.1 with the patient portal enabled.
2. Identify patient record ID: Authenticate to the patient portal and call the GET api/patientdata endpoint. Extract the id field from the JSON response — this is the patient_data auto-increment primary key used in the exploit URL (distinct from pid).
3. Inject XSS payload via direct API call: From the authenticated portal session, send a crafted HTTP PUT request directly to api/patient/<id> (bypassing the audit-routed api/portalpatient/<id> endpoint used by the portal UI), with a JSON body such as:

   {"fname": "<img src=x onerror=alert(document.domain)>", "lname": "Smith"}

   The p_limited ACL check passes because the URL ID matches the patient's own record, and the payload is written directly to patient_data without sanitization or audit review.
4. Wait for clinician interaction: The payload is now stored in the patient's demographic record. When a clinician logs into the main OpenEMR interface, opens the patient's chart, navigates to Prescriptions, and selects "CSS/HTML Print (multi)" for any prescription belonging to that patient, multiprintcss_header() renders the unescaped fname field into the HTML document.
5. Execute in clinician session: The injected script executes in the clinician's authenticated browser context, providing access to CSRF tokens, session cookies, and the ability to perform actions (e.g., read other patients' records, modify clinical data) as the clinician (GitHub Advisory).

• Network: Unexpected HTTP PUT requests from a patient portal session to api/patient/<id> (rather than the expected api/portalpatient/<id>); requests containing HTML/JavaScript tags (e.g., <img, <script, onerror=) in JSON body fields such as fname or lname.
• Logs: OpenEMR access logs showing PUT requests to /portal/patient/api/patient/<id> from patient portal sessions; absence of corresponding audit entries in onsite_portal_activity for demographic changes that appear in patient_data.
• Database: Entries in the patient_data table where fname, lname, or addr fields contain HTML tags or JavaScript event handlers (e.g., onerror=, <script>, <img src=x>).
• Browser/Session: Clinician sessions making unexpected API calls or accessing records inconsistent with their workflow immediately after opening the CSS/HTML prescription print view for a specific patient (GitHub Advisory).

The primary remediation is to upgrade OpenEMR to version 8.0.0.1 or later, which patches both the missing output encoding in multiprintcss_header() and the authorization bypass on the api/patient/:num endpoint (GitHub Advisory). As interim mitigations for organizations unable to upgrade immediately: implement Content Security Policy (CSP) headers to restrict inline script execution; restrict or disable the patient portal if not operationally required; and audit the patient_data table for demographic fields containing HTML or JavaScript. Additionally, consider network-level controls (WAF rules) to block PUT requests containing HTML tags in JSON bodies targeting the api/patient/ endpoint.

The vulnerability was reported by researcher pavelkohout396 and analyzed by simecek, with the advisory published by kojiromike on the OpenEMR GitHub repository (GitHub Advisory). Red Hat tracked the CVE in their security database, indicating broader ecosystem awareness (Red Hat CVE). No significant broader media coverage or notable social media commentary beyond standard CVE aggregator posts has been identified at this time.