Listen to this Post
The vulnerability resides in ConceptReferenceRangeUtility.evaluateCriteria(), which evaluates 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 unrestricted Java reflection through template expressions.
An attacker with the `Manage Concepts` privilege can store a malicious Velocity template expression in a concept’s reference range criteria field.
When any user or API call validates an observation against the affected concept, the payload is executed automatically.
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).
Because 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.
The `Manage Concepts` privilege is a content‑management function (“Able to add/edit/delete concept entries”), not an administrative privilege, meaning many non‑admin staff hold it.
An attacker can thus escalate from concept dictionary management to arbitrary code execution as the Tomcat application server process.
The Velocity context also exposes patient data directly, leading to PHI exfiltration without OS‑level RCE.
The vulnerability affects OpenMRS Core versions 2.7.0 through 2.7.8 and 2.8.0 through 2.8.5, and is fixed in 2.7.9, 2.8.6, and later versions.
dailycve form:
Platform: `OpenMRS Core`
Version: `2.7.0-2.8.5`
Vulnerability: `Velocity SSTI RCE`
Severity: `Critical (9.1)`
Date: `2026-05-04`
Prediction: `Patch expected 2026-05-15`
What Undercode Say:
Check OpenMRS Core version via API
curl -s http://target/openmrs/ws/rest/v1/systeminformation | jq '.version'
Simulated test payload (requires Manage Concepts privilege)
curl -X POST http://target/openmrs/ws/rest/v1/concept \
-H "Content-Type: application/json" \
-d '{"names":[{"name":"Test","locale":"en"}],"datatype":"N/A","conceptClass":"Test","mappings":[]}' \
--cookie "JSESSIONID=<valid_admin_session>"
More robust impact check
find /path/to/openmrs -name "openmrs-api-.jar" | grep -E "2.7.[0-8]|2.8.[0-5]"
Exploit:
An authenticated user with `Manage Concepts` privilege injects a Velocity payload (e.g., set($p=$fn.getClass().forName("java.lang.Runtime"))$p.getRuntime().exec("calc")) into the `criteria` field of a concept’s reference range. The payload is stored in the database and executed every time an observation is validated against that concept, leading to persistent RCE.
Protection from this CVE:
- Upgrade OpenMRS Core to 2.7.9, 2.8.6, or any later version.
- Restrict `Manage Concepts` privilege to only highly trusted users.
- Audit all `ConceptReferenceRange` entries in the database for suspicious criteria strings.
- Deploy a WAF rule to block known Velocity payload patterns if immediate patching is impossible.
Impact:
- Persistent RCE – a single malicious concept triggers code execution on every observation validation, affecting all users, integrations, and API clients.
- Privilege escalation – from content‑management staff to arbitrary code execution as the Tomcat application server process.
- PHI exfiltration – patient identifiers, demographics, and clinical observations can be leaked directly from the Velocity context without OS‑level compromise.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
