Summary
General OpenMRS Security Advisory, January 2025: Penetration Testing Results and Patches
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.
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.
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.
Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites. Typical impact: phishing and credential harvesting via a trusted domain.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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)
Frequently Asked Questions
- What is GHSA-VPXM-CR3R-PJP9? GHSA-VPXM-CR3R-PJP9 is a critical-severity open redirect vulnerability in org.openmrs:openmrs (maven), affecting versions < 2.6.11. It is fixed in 2.6.11, 1.21.0, 4.14.0, 2.19.0, 3.6.0, 3.0.8. Untrusted input controls a URL used for redirection, which can forward users to attacker-controlled sites.
- Which packages are affected by GHSA-VPXM-CR3R-PJP9?
org.openmrs:openmrs(maven) (versions < 2.6.11)org.openmrs.module:legacyui(maven) (versions < 1.21.0)org.openmrs.module:idgen(maven) (versions < 4.14.0)org.openmrs.module:addresshierarchy(maven) (versions < 2.19.0)org.openmrs.module:attachments(maven) (versions < 3.6.0)org.openmrs.module:patientflags(maven) (versions < 3.0.8)
- Is there a fix for GHSA-VPXM-CR3R-PJP9? Yes. GHSA-VPXM-CR3R-PJP9 is fixed in 2.6.11, 1.21.0, 4.14.0, 2.19.0, 3.6.0, 3.0.8. Upgrade to this version or later.
- Is GHSA-VPXM-CR3R-PJP9 exploitable, and should I be worried? Whether GHSA-VPXM-CR3R-PJP9 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether GHSA-VPXM-CR3R-PJP9 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix GHSA-VPXM-CR3R-PJP9?
- Upgrade
org.openmrs:openmrsto 2.6.11 or later - Upgrade
org.openmrs.module:legacyuito 1.21.0 or later - Upgrade
org.openmrs.module:idgento 4.14.0 or later - Upgrade
org.openmrs.module:addresshierarchyto 2.19.0 or later - Upgrade
org.openmrs.module:attachmentsto 3.6.0 or later - Upgrade
org.openmrs.module:patientflagsto 3.0.8 or later
- Upgrade