CVE-2026-40075

OpenMRS Core is an open source electronic medical record system platform. In versions 2.7.8 and earlier and versions 2.8.0 through 2.8.5, the /openmrs/moduleResources/{moduleid} endpoint is vulnerable to a path traversal attack. The ModuleResourcesServlet constructs a filesystem path from user-controlled input without performing path boundary validation — the getFile() method concatenates the user-supplied path into an absolute filesystem path without calling normalize() or checking that the result stays within the allowed module resources directory. Because this endpoint serves static resources required for rendering the login page, it is not protected by authentication filters, allowing unauthenticated exploitation.

An attacker can traverse directories and read arbitrary files from the server filesystem, including /etc/passwd and application configuration files containing database credentials. Successful exploitation requires the target deployment to run on Apache Tomcat versions prior to 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat 8.5.31 or later and Tomcat 9.0.10 or later are protected at the container level, though the underlying code defect remains. This issue has been fixed in versions after 2.7.8 (within the 2.7.x branch) and in version 2.8.6 and later.

OpenMRS Core is an open source electronic medical record system platform. In versions 2.7.8 and earlier and versions 2.8.0 through 2.8.5, the /openmrs/moduleResources/{moduleid} endpoint is vulnerable to a path traversal attack. The ModuleResourcesServlet constructs a filesystem path from user-controlled input without performing path boundary validation — the getFile() method concatenates the user-supplied path into an absolute filesystem path without calling normalize() or checking that the result stays within the allowed module resources directory. Because this endpoint serves static resources required for rendering the login page, it is not protected by authentication filters, allowing unauthenticated exploitation.

An attacker can traverse directories and read arbitrary files from the server filesystem, including /etc/passwd and application configuration files containing database credentials. Successful exploitation requires the target deployment to run on Apache Tomcat versions prior to 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat 8.5.31 or later and Tomcat 9.0.10 or later are protected at the container level, though the underlying code defect remains. This issue has been fixed in versions after 2.7.8 (within the 2.7.x branch) and in version 2.8.6 and later.

Affected Versions

version ≤ 2.7.8 (latest version at time of disclosure)

https://github.com/openmrs/openmrs-core

Impact

The /openmrs/moduleResources/{moduleid} endpoint in OpenMRS Core is vulnerable to a path traversal attack. The ModuleResourcesServlet does not properly validate user-supplied path input, allowing an attacker to traverse directories and read arbitrary files from the server filesystem (e.g., /etc/passwd, application configuration files containing database credentials).

This endpoint serves static module resources (CSS, JS, images) and is not protected by authentication filters, as these resources are required for rendering the login page. Therefore, this vulnerability can be exploited by an unauthenticated attacker.

Note: Successful exploitation requires the target deployment to run on Apache Tomcat < 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat ≥ 8.5.31 / ≥ 9.0.10 are protected at the container level, though the underlying code defect remains.

Steps to Reproduce

1. Identify a valid installed module ID on the target OpenMRS instance (e.g., legacyui).
2. Send the following HTTP request:

<img width="1038" height="798" alt="image" src="https://github.com/user-attachments/assets/7d10ee0e-4d81-4c01-bc84-a1bf5715f170" />

3. The server responds with HTTP 200 and the contents of /etc/passwd:

<img width="1028" height="843" alt="image" src="https://github.com/user-attachments/assets/b6806a7e-ff52-4f51-8f7f-7ea4e9754d10" />

Root Cause Analysis

The vulnerability exists in ModuleResourcesServlet.java (web/src/main/java/org/openmrs/module/web/ModuleResourcesServlet.java).

The getFile() method constructs a filesystem path from user-controlled input without performing path boundary validation:

protected File getFile(HttpServletRequest request) {
    // Step 1: User-controlled path input
    String path = request.getPathInfo();

    // Step 2: Extract module from path prefix
    Module module = ModuleUtil.getModuleForPath(path);
    if (module == null) { return null; }

    // Step 3: Strip module ID prefix — no traversal check
    String relativePath = ModuleUtil.getPathForResource(module, path);

    // Step 4: Concatenate into absolute path
    String realPath = getServletContext().getRealPath("")
        + MODULE_PATH
        + module.getModuleIdAsPath()
        + "/resources"
        + relativePath;  // contains "/../../../etc/passwd"

    realPath = realPath.replace("/", File.separator);

    // Step 5: No normalize().startsWith() boundary check
    File f = new File(realPath);
    if (!f.exists()) { return null; }

    return f;  // Arbitrary file returned to client
}

The helper method ModuleUtil.getPathForResource() only strips the module ID prefix and performs no sanitization:

public static String getPathForResource(Module module, String path) {
    if (path.startsWith("/")) {
        path = path.substring(1);
    }
    return path.substring(module.getModuleIdAsPath().length());
    // Returns unsanitized remainder, e.g., "/../../../../../../etc/passwd"
}

The resulting path resolves as:

{webapp}/WEB-INF/view/module/legacyui/resources/../../../../../../etc/passwd
  → /etc/passwd

Notably, the same codebase already implements correct path traversal protection in StartupFilter.java:

// StartupFilter.java — correct protection
fullFilePath = fullFilePath.resolve(httpRequest.getPathInfo());
if (!(fullFilePath.normalize().startsWith(filePath))) {
    log.warn("Detected attempted directory traversal...");
    return;  // Request rejected
}

This check is absent from ModuleResourcesServlet.

Remediation

Add a path boundary check after constructing realPath and before returning the File object. The fix should use normalize() + startsWith() to ensure the resolved path stays within the allowed module resources directory:

OpenMRS Core is an open source electronic medical record system platform. In versions 2.7.8 and earlier and versions 2.8.0 through 2.8.5, the /openmrs/moduleResources/{moduleid} endpoint is vulnerable to a path traversal attack. The ModuleResourcesServlet constructs a filesystem path from user-controlled input without performing path boundary validation — the getFile() method concatenates the user-supplied path into an absolute filesystem path without calling normalize() or checking that the result stays within the allowed module resources directory. Because this endpoint serves static resources required for rendering the login page, it is not protected by authentication filters, allowing unauthenticated exploitation.

An attacker can traverse directories and read arbitrary files from the server filesystem, including /etc/passwd and application configuration files containing database credentials. Successful exploitation requires the target deployment to run on Apache Tomcat versions prior to 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat 8.5.31 or later and Tomcat 9.0.10 or later are protected at the container level, though the underlying code defect remains. This issue has been fixed in versions after 2.7.8 (within the 2.7.x branch) and in version 2.8.6 and later.

OpenMRS Core is an open source electronic medical record system platform. In versions 2.7.8 and earlier and versions 2.8.0 through 2.8.5, the /openmrs/moduleResources/{moduleid} endpoint is vulnerable to a path traversal attack. The ModuleResourcesServlet constructs a filesystem path from user-controlled input without performing path boundary validation — the getFile() method concatenates the user-supplied path into an absolute filesystem path without calling normalize() or checking that the result stays within the allowed module resources directory. Because this endpoint serves static resources required for rendering the login page, it is not protected by authentication filters, allowing unauthenticated exploitation.

An attacker can traverse directories and read arbitrary files from the server filesystem, including /etc/passwd and application configuration files containing database credentials. Successful exploitation requires the target deployment to run on Apache Tomcat versions prior to 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat 8.5.31 or later and Tomcat 9.0.10 or later are protected at the container level, though the underlying code defect remains. This issue has been fixed in versions after 2.7.8 (within the 2.7.x branch) and in version 2.8.6 and later.

Affected Versions

version ≤ 2.7.8 (latest version at time of disclosure)

https://github.com/openmrs/openmrs-core

Impact

The /openmrs/moduleResources/{moduleid} endpoint in OpenMRS Core is vulnerable to a path traversal attack. The ModuleResourcesServlet does not properly validate user-supplied path input, allowing an attacker to traverse directories and read arbitrary files from the server filesystem (e.g., /etc/passwd, application configuration files containing database credentials).

This endpoint serves static module resources (CSS, JS, images) and is not protected by authentication filters, as these resources are required for rendering the login page. Therefore, this vulnerability can be exploited by an unauthenticated attacker.

Note: Successful exploitation requires the target deployment to run on Apache Tomcat < 8.5.31, where the ..; path parameter bypass is not mitigated by the container. Deployments on Tomcat ≥ 8.5.31 / ≥ 9.0.10 are protected at the container level, though the underlying code defect remains.

Steps to Reproduce

1. Identify a valid installed module ID on the target OpenMRS instance (e.g., legacyui).
2. Send the following HTTP request:

<img width="1038" height="798" alt="image" src="https://github.com/user-attachments/assets/7d10ee0e-4d81-4c01-bc84-a1bf5715f170" />

3. The server responds with HTTP 200 and the contents of /etc/passwd:

<img width="1028" height="843" alt="image" src="https://github.com/user-attachments/assets/b6806a7e-ff52-4f51-8f7f-7ea4e9754d10" />

Root Cause Analysis

The vulnerability exists in ModuleResourcesServlet.java (web/src/main/java/org/openmrs/module/web/ModuleResourcesServlet.java).

The getFile() method constructs a filesystem path from user-controlled input without performing path boundary validation:

protected File getFile(HttpServletRequest request) {
    // Step 1: User-controlled path input
    String path = request.getPathInfo();

    // Step 2: Extract module from path prefix
    Module module = ModuleUtil.getModuleForPath(path);
    if (module == null) { return null; }

    // Step 3: Strip module ID prefix — no traversal check
    String relativePath = ModuleUtil.getPathForResource(module, path);

    // Step 4: Concatenate into absolute path
    String realPath = getServletContext().getRealPath("")
        + MODULE_PATH
        + module.getModuleIdAsPath()
        + "/resources"
        + relativePath;  // contains "/../../../etc/passwd"

    realPath = realPath.replace("/", File.separator);

    // Step 5: No normalize().startsWith() boundary check
    File f = new File(realPath);
    if (!f.exists()) { return null; }

    return f;  // Arbitrary file returned to client
}

The helper method ModuleUtil.getPathForResource() only strips the module ID prefix and performs no sanitization:

public static String getPathForResource(Module module, String path) {
    if (path.startsWith("/")) {
        path = path.substring(1);
    }
    return path.substring(module.getModuleIdAsPath().length());
    // Returns unsanitized remainder, e.g., "/../../../../../../etc/passwd"
}

The resulting path resolves as:

{webapp}/WEB-INF/view/module/legacyui/resources/../../../../../../etc/passwd
  → /etc/passwd

Notably, the same codebase already implements correct path traversal protection in StartupFilter.java:

// StartupFilter.java — correct protection
fullFilePath = fullFilePath.resolve(httpRequest.getPathInfo());
if (!(fullFilePath.normalize().startsWith(filePath))) {
    log.warn("Detected attempted directory traversal...");
    return;  // Request rejected
}

This check is absent from ModuleResourcesServlet.

Remediation

Add a path boundary check after constructing realPath and before returning the File object. The fix should use normalize() + startsWith() to ensure the resolved path stays within the allowed module resources directory: