Summary
OpenEMR's DORN compendium installation endpoint checks authentication and CSRF protections but does not enforce the admin/users access control used by related administration scripts. When the DORN module is enabled, a low-privilege authenticated user may trigger changes that delete lab procedure types and deactivate order types, potentially corrupting lab-ordering configuration.
OpenEMR's DORN compendium installation endpoint checks authentication and CSRF protections but does not enforce the admin/users access control used by related administration scripts. When the DORN module is enabled, a low-privilege authenticated user may trigger changes that delete lab procedure types and deactivate order types, potentially corrupting lab-ordering configuration.
Affected context
The issue is in OpenEMR's DORN module compendium installation flow. It may be present when the module is enabled and the endpoint is reachable by authenticated users who do not have the administrative ACL required by sibling DORN administration scripts. The uninstall operation can alter procedure and order types before the reinstall step.
The issue is in OpenEMR's DORN module compendium installation flow. It may be present when the module is enabled and the endpoint is reachable by authenticated users who do not have the administrative ACL required by sibling DORN administration scripts. The uninstall operation can alter procedure and order types before the reinstall step.
Exploit preconditions
- Attack surface: The DORN compendium installation endpoint in the web application
- Required access: An authenticated account; administrative ACL privileges are not required by the vulnerable endpoint
- Trigger point: Processing a request that supplies a
labGuidwhile the DORN module is enabled - Why exploitation is possible: The endpoint checks authentication and CSRF but omits the relevant authorization check, allowing the uninstall operation to run for a low-privilege user
- Attack surface: The DORN compendium installation endpoint in the web application
- Required access: An authenticated account; administrative ACL privileges are not required by the vulnerable endpoint
- Trigger point: Processing a request that supplies a
labGuidwhile the DORN module is enabled - Why exploitation is possible: The endpoint checks authentication and CSRF but omits the relevant authorization check, allowing the uninstall operation to run for a low-privilege user
Why this happens
The endpoint does not verify that the authenticated user has the required administrative permission before performing a sensitive operation. This is a missing authorization control, mapped to CWE-862: Missing Authorization. Authentication establishes a user's identity, but does not by itself grant permission to delete or deactivate lab-ordering configuration.
The endpoint does not verify that the authenticated user has the required administrative permission before performing a sensitive operation. This is a missing authorization control, mapped to CWE-862: Missing Authorization. Authentication establishes a user's identity, but does not by itself grant permission to delete or deactivate lab-ordering configuration.
Potential impact
- Lab procedure types could be deleted or order types deactivated without appropriate authorization.
- Lab-ordering configuration may become corrupted or unavailable.
- Administrators may need to restore the compendium and validate affected configuration.
- Lab procedure types could be deleted or order types deactivated without appropriate authorization.
- Lab-ordering configuration may become corrupted or unavailable.
- Administrators may need to restore the compendium and validate affected configuration.
General mitigation guidance
Mitigations generally focus on applying authorization checks consistently to every sensitive operation.
- Enforce the appropriate administrative ACL at the endpoint before invoking uninstall or reinstall actions.
- Use centralized, deny-by-default authorization checks rather than relying on authentication or CSRF validation as substitutes for access control.
- Limit the privileges of application components and accounts that can modify clinical configuration.
- Validate requested operations and identifiers against the caller's permissions, and audit configuration-changing actions.
Mitigations generally focus on applying authorization checks consistently to every sensitive operation.
- Enforce the appropriate administrative ACL at the endpoint before invoking uninstall or reinstall actions.
- Use centralized, deny-by-default authorization checks rather than relying on authentication or CSRF validation as substitutes for access control.
- Limit the privileges of application components and accounts that can modify clinical configuration.
- Validate requested operations and identifiers against the caller's permissions, and audit configuration-changing actions.
How teams detect issues like this
- Use static analysis or endpoint inventories to identify sensitive handlers that check authentication but lack authorization checks.
- Review code paths that delete, deactivate, or reinstall configuration, comparing their permission checks with sibling administrative endpoints.
- Add automated tests confirming that users without the required ACL cannot invoke configuration-changing operations.
- Apply policy checks in code review and CI to require explicit authorization for sensitive actions; automated review tools may help flag inconsistent access-control patterns.
- Use static analysis or endpoint inventories to identify sensitive handlers that check authentication but lack authorization checks.
- Review code paths that delete, deactivate, or reinstall configuration, comparing their permission checks with sibling administrative endpoints.
- Add automated tests confirming that users without the required ACL cannot invoke configuration-changing operations.
- Apply policy checks in code review and CI to require explicit authorization for sensitive actions; automated review tools may help flag inconsistent access-control patterns.
