{"id":"GHSA-xj4f-8jjg-vx4q","summary":"OpenMRS has Stored Velocity SSTI to RCE via ConceptReferenceRange","details":"### Impact\n\nThe `ConceptReferenceRangeUtility.evaluateCriteria()` method in OpenMRS Core\nevaluates database-stored criteria strings as Apache Velocity templates without any sandbox configuration. The `VelocityEngine` is initialized with only logging properties and no`SecureUberspector`, leaving the default `UberspectImpl` in place, which allows\nunrestricted Java reflection through template expressions.\n\nA user with the `Manage Concepts` privilege can store a malicious Velocity template\nexpression in a concept's reference range criteria field. This payload is then executed\nautomatically whenever a user or API call validates an observation against the affected\nconcept. The Velocity context exposes `$patient` (the `Person` / `Patient` object), `$obs` (the `Obs` object), and `$fn` (the `ConceptReferenceRangeUtility` instance with access to the full OpenMRS service layer).\n\n**Persistent Remote Code Execution**: The payload persists in the concept_reference_range database table (VARCHAR 65535). A single compromised concept for a common clinical measurement executes the payload on every subsequent observation validation across all users, API clients, and integrations in the facility.\n\n**Privilege Escalation**: The Manage Concepts privilege is a content-management function, defined as \"Able to add/edit/delete concept entries\", not an administrative privilege. Multiple non-admin staff per facility typically hold this privilege. The attacker escalates from concept dictionary management to arbitrary code execution as the Tomcat application server process.\n\n**PHI Exfiltration**: The Velocity context objects directly expose patient data without requiring OS-level RCE.\n\n### Patches\n\nThis is fixed in 2.8.6 and 2.7.9 as well as future versions.\n\n### Workarounds\n\nEnsure the `Manage Concepts` privilege is restricted to only authorized users and carefully audit any `ConceptReferenceRanges` in the database.\n\n### Resources\nhttps://github.com/openmrs/openmrs-core/commit/8d1c193\nhttps://www.machinespirits.com/advisory/1e8430/","aliases":["CVE-2026-41258"],"modified":"2026-05-16T00:10:46.998566Z","published":"2026-05-04T19:31:22Z","database_specific":{"nvd_published_at":"2026-05-15T17:16:46Z","cwe_ids":["CWE-94"],"severity":"CRITICAL","github_reviewed":true,"github_reviewed_at":"2026-05-04T19:31:22Z"},"references":[{"type":"WEB","url":"https://github.com/openmrs/openmrs-core/security/advisories/GHSA-xj4f-8jjg-vx4q"},{"type":"ADVISORY","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-41258"},{"type":"WEB","url":"https://github.com/openmrs/openmrs-core/commit/8d1c193"},{"type":"PACKAGE","url":"https://github.com/openmrs/openmrs-core"},{"type":"WEB","url":"https://www.machinespirits.com/advisory/1e8430"}],"affected":[{"package":{"name":"org.openmrs.api:openmrs-api","ecosystem":"Maven","purl":"pkg:maven/org.openmrs.api/openmrs-api"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.7.0"},{"fixed":"2.7.9"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-xj4f-8jjg-vx4q/GHSA-xj4f-8jjg-vx4q.json"}},{"package":{"name":"org.openmrs.api:openmrs-api","ecosystem":"Maven","purl":"pkg:maven/org.openmrs.api/openmrs-api"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"2.8.0"},{"fixed":"2.8.6"}]}],"database_specific":{"source":"https://github.com/github/advisory-database/blob/main/advisories/github-reviewed/2026/05/GHSA-xj4f-8jjg-vx4q/GHSA-xj4f-8jjg-vx4q.json"}}],"schema_version":"1.9.0","severity":[{"type":"CVSS_V3","score":"CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:H"}]}