CVE-2026-40076
Path Traversal in OpenMRS Core via Malicious Module Upload
Publication date: 2026-05-06
Last updated on: 2026-05-11
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openmrs | openmrs | to 2.7.8 (inc) |
| openmrs | openmrs | From 2.8.0 (inc) to 2.8.5 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-22 | The product uses external input to construct a pathname that is intended to identify a file or directory that is located underneath a restricted parent directory, but the product does not properly neutralize special elements within the pathname that can cause the pathname to resolve to a location that is outside of the restricted directory. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability affects OpenMRS Core versions 2.7.8 and earlier, and versions 2.8.0 through 2.8.5. It is a Zip Slip path traversal attack occurring in the module upload endpoint at POST `/openmrs/ws/rest/v1/module`. When a .omod archive is uploaded, the system extracts ZIP entries under web/module/ by checking only if the entry path starts with '..,' but does not normalize or properly boundary-check the path. This allows a crafted archive to include entries like `web/module/../../../../malicious.jsp` that write files outside the intended directory.
An authenticated attacker with module upload access can exploit this to write arbitrary files, such as JSP files, to the web application root. This can lead to remote code execution by then requesting the malicious JSP file. The vulnerability is worsened because the module.allow_web_admin property, which restricts web-based module administration, is enforced only in the legacy UI controller and not in the REST API upload path, leaving deployments exposed through the REST endpoint.
This issue has been fixed in versions after 2.7.8 in the 2.7.x line and in version 2.8.6 and later.
How can this vulnerability impact me? :
This vulnerability can have severe impacts including allowing an authenticated attacker with module upload access to write arbitrary files to the server, such as malicious JSP files.
By placing these files in the web application root, the attacker can achieve remote code execution, potentially taking full control of the affected system.
This compromises the confidentiality, integrity, and availability of the system and any sensitive data it manages.
What immediate steps should I take to mitigate this vulnerability?
To mitigate this vulnerability, upgrade OpenMRS Core to a version later than 2.7.8 in the 2.7.x line or version 2.8.6 and later.
Ensure that the module.allow_web_admin runtime property is properly enforced in all module upload paths, including the REST API, to prevent unauthorized module uploads.
Restrict module upload access to trusted authenticated users only.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability allows an authenticated attacker to achieve remote code execution by uploading malicious files outside the intended directory, potentially compromising the confidentiality and integrity of sensitive medical records managed by OpenMRS.
Such a compromise could lead to unauthorized access, modification, or disclosure of protected health information, which would negatively impact compliance with regulations like GDPR and HIPAA that mandate strict controls over data confidentiality and integrity.
Therefore, if exploited, this vulnerability could result in violations of these common standards and regulations due to the risk of data breaches and unauthorized system control.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability involves the upload and extraction of malicious .omod archive files containing path traversal sequences that allow writing files outside the intended directory. Detection involves monitoring for suspicious module upload activity, especially POST requests to the endpoint /openmrs/ws/rest/v1/module by authenticated users.
To detect exploitation attempts, you can look for HTTP POST requests to the module upload REST API containing .omod files with suspicious ZIP entry paths including directory traversal patterns like "../../".
On the server, you can check for unexpected JSP or other files appearing outside the module directory, especially in the web application root.
- Use web server access logs to filter POST requests to /openmrs/ws/rest/v1/module, for example with grep:
- grep 'POST /openmrs/ws/rest/v1/module' /var/log/apache2/access.log
- Inspect uploaded .omod files for suspicious ZIP entries containing directory traversal sequences:
- unzip -l suspicious.omod | grep '\.\./'
- On the filesystem, find files with recent modification times outside the expected module directory, for example:
- find /path/to/openmrs/webapp/root -type f -name '*.jsp' -mtime -7
Because the vulnerability requires authenticated access, monitoring authentication logs for unusual module upload activity can also help detect exploitation attempts.