Summary
OpenEMR forms render stored values inside double-quoted HTML attributes using encoding that does not escape quotation marks. An authenticated clinical user who can save a crafted value may cause script to run when another clinician opens the affected form, potentially exposing session data or enabling actions in that clinician's session.
OpenEMR forms render stored values inside double-quoted HTML attributes using encoding that does not escape quotation marks. An authenticated clinical user who can save a crafted value may cause script to run when another clinician opens the affected form, potentially exposing session data or enabling actions in that clinician's session.
Affected context
The issue affects the transfer summary and functional cognitive status forms in OpenEMR versions before 8.3.0. It occurs when stored transfer_to, code, or codetext values are rendered inside double-quoted HTML value attributes using text(), which does not encode quotation marks for that context. Risk depends on an authenticated user being able to store such a value and another clinician opening the affected form.
The issue affects the transfer summary and functional cognitive status forms in OpenEMR versions before 8.3.0. It occurs when stored transfer_to, code, or codetext values are rendered inside double-quoted HTML value attributes using text(), which does not encode quotation marks for that context. Risk depends on an authenticated user being able to store such a value and another clinician opening the affected form.
Exploit preconditions
- Attack surface: The affected clinical forms in the OpenEMR web interface
- Required access: An authenticated clinical user with permission to store values used by the forms
- Trigger point: Another clinician opens a form that renders the stored value
- Why exploitation is possible: Quotation marks are not encoded for the double-quoted HTML attribute context, allowing the stored value to break out of that attribute and introduce event-handler markup
- Attack surface: The affected clinical forms in the OpenEMR web interface
- Required access: An authenticated clinical user with permission to store values used by the forms
- Trigger point: Another clinician opens a form that renders the stored value
- Why exploitation is possible: Quotation marks are not encoded for the double-quoted HTML attribute context, allowing the stored value to break out of that attribute and introduce event-handler markup
Why this happens
The underlying issue is context-inappropriate output encoding. The application uses text() with ENT_NOQUOTES to render stored data inside double-quoted HTML attributes, leaving quotation marks unescaped. This creates a stored cross-site scripting weakness, mapped to CWE-79: Improper Neutralization of Input During Web Page Generation.
The underlying issue is context-inappropriate output encoding. The application uses text() with ENT_NOQUOTES to render stored data inside double-quoted HTML attributes, leaving quotation marks unescaped. This creates a stored cross-site scripting weakness, mapped to CWE-79: Improper Neutralization of Input During Web Page Generation.
Potential impact
- Script execution in a clinician's browser when an affected form is opened
- Exposure of session data or protected health information
- Patient-record actions performed with the victim's session privileges
- Potential disruption to clinical workflows or loss of trust in displayed records
- Script execution in a clinician's browser when an affected form is opened
- Exposure of session data or protected health information
- Patient-record actions performed with the victim's session privileges
- Potential disruption to clinical workflows or loss of trust in displayed records
General mitigation guidance
Common defensive patterns focus on encoding output for its exact rendering context and limiting trust in stored values:
- Use HTML attribute-context encoding that escapes quotation marks when inserting data into quoted attributes
- Prefer templating mechanisms that apply context-aware output encoding by default
- Validate stored values against expected formats as a supplementary control, not as a replacement for output encoding
- Minimize inline event-handler use and apply a restrictive Content Security Policy where practical
- Apply least privilege to accounts that can enter or modify clinical data
Common defensive patterns focus on encoding output for its exact rendering context and limiting trust in stored values:
- Use HTML attribute-context encoding that escapes quotation marks when inserting data into quoted attributes
- Prefer templating mechanisms that apply context-aware output encoding by default
- Validate stored values against expected formats as a supplementary control, not as a replacement for output encoding
- Minimize inline event-handler use and apply a restrictive Content Security Policy where practical
- Apply least privilege to accounts that can enter or modify clinical data
How teams detect issues like this
- Use static analysis to identify untrusted or stored values rendered in HTML attributes without context-appropriate encoding
- Review templates and rendering helpers for uses of
ENT_NOQUOTESor equivalent encoding in quoted attributes - Test affected forms with security checks that verify stored values remain inert when rendered
- Enforce code-review or CI policies requiring context-aware output encoding for user-controlled data
- Use automated code review tools as a supplementary way to flag unsafe rendering patterns
- Use static analysis to identify untrusted or stored values rendered in HTML attributes without context-appropriate encoding
- Review templates and rendering helpers for uses of
ENT_NOQUOTESor equivalent encoding in quoted attributes - Test affected forms with security checks that verify stored values remain inert when rendered
- Enforce code-review or CI policies requiring context-aware output encoding for user-controlled data
- Use automated code review tools as a supplementary way to flag unsafe rendering patterns
