GHSA-vpxm-cr3r-pjp9 — openmrs
GHSA-vpxm-cr3r-pjp9 is a security vulnerability in org.openmrs:openmrs. A fix is available for org.openmrs:openmrs — see the affected versions and patch details below.
General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches
Real-World Exposure
org.openmrs:openmrs☕org.openmrs.module:legacyui☕org.openmrs.module:idgen☕org.openmrs.module:addresshierarchy☕org.openmrs.module:attachments☕org.openmrs.module:patientflagsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Maven packages — download data is not available via public APIs for these ecosystems.
Description
Impact
We recently underwent Penetration Testing of OpenMRS by a third-party company. Vulnerabilities were found, and fixes have been made and released. We've released security updates that include critical fixes, and so, we strongly recommend upgrading affected modules.
This notice applies to all OpenMRS instances. The testers used the OpenMRS v3 Reference Application (O3 RefApp); however, their findings highlighted modules commonly used in older OpenMRS applications, including the O2 RefApp.
Vulnerability Details
- The issues uncovered included broken access control (e.g. inappropriate admin access), phishing vulnerability, and stored XSS (e.g. vulnerable passwords).
- No vulnerabilities were found in the O3 frontend esm modules.
- The Letter of Attestation from the penetration test is available here for your reference.
- After the fixes were applied, the OpenMRS O3 RefApp met a Security Level of “Excellent, Grade A”.
- The full detailed Remediation Pentest Report is available to Implementation Technical Leads upon request.
Patches
Minimum Requirements for Implementers: We strongly recommend upgrading your modules to the following versions (or greater) as soon as possible. This is the minimum amount to do and be protected from the vulnerabilities found and fixed. The following versions contain the patch:
- Platform 2.6.11+
- How: Increase your platform version number wherever this is specified in your implementation. If you use the OpenMRS SDK, this will be in the distro.properties file.
- Notes:
- The newly released Platform 2.7 also includes the fixes. Release Notes and more download options here.
- Platform 2.6.8+ has most of the fixes, but these are broken if you don't use SSL, so Platform 2.6.11 or higher is preferred.
- For those still on Platform 2.5+ such as the Bahmni ecosystem, the new 2.5.14 release includes the patch. Bahmni note: The upcoming patch release for both Bahmni Lite and Bahmni Standard will incorporate these security fixes.
- Legacy UI OMOD 1.21.0+ (here)
- ID Gen OMOD 4.14.0+ (here)
- Address Hierarchy OMOD 2.19.0+ (here)
- Attachments OMOD 3.6.0+ (here)
- Patient Flags OMOD 3.0.8+ (here)
Workarounds
There are no practical workarounds to fix or remediate the vulnerabilities without upgrading. Technically, you could remove the affected OMODs, but this would badly degrade the system's functionality.
Thank you to our amazing Security contributors!
Thank you to security firm UnderDefense, and to the OpenMRS Security Group contributors for their patch support - specific thanks to Daniel Kayiwa, Samuel Lubwama, Ian Bacher, Rafal Korytkowski, and Michael Seaton.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| ☕Maven | org.openmrs:openmrs | all versions | 2.6.11org.openmrs:openmrs:2.6.11 |
| ☕Maven | org.openmrs.module:legacyui | all versions | 1.21.0org.openmrs.module:legacyui:1.21.0 |
| ☕Maven | org.openmrs.module:idgen | all versions | 4.14.0org.openmrs.module:idgen:4.14.0 |
| ☕Maven | org.openmrs.module:addresshierarchy | all versions | 2.19.0org.openmrs.module:addresshierarchy:2.19.0 |
| ☕Maven | org.openmrs.module:attachments | all versions | 3.6.0org.openmrs.module:attachments:3.6.0 |
| ☕Maven | org.openmrs.module:patientflags | all versions | 3.0.8org.openmrs.module:patientflags:3.0.8 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for org.openmrs:openmrs, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update org.openmrs:openmrs to 2.6.11 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vpxm-cr3r-pjp9 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-vpxm-cr3r-pjp9 can be triaged on real exposure rather than presence alone.
Tailored to GHSA-vpxm-cr3r-pjp9. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-vpxm-cr3r-pjp9 in your dependencies?
O3 Security finds GHSA-vpxm-cr3r-pjp9 across Maven dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.