Vulnerability-Lookup

GHSA-JJGJ-CX3Q-PW4W

Vulnerability from github – Published: 2026-05-04 17:18 – Updated: 2026-05-08 15:36

Summary

OpenMRS ModuleResourcesServlet has Path Traversal that Leads to Arbitrary File Read

Details

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

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

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

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:

File f = new File(realPath);
Path allowedBase = Paths.get(getServletContext().getRealPath(""), "WEB-INF", "view", "module");
if (!f.toPath().normalize().startsWith(allowedBase.normalize())) {
    log.warn("Blocked path traversal attempt: {}", request.getPathInfo());
    return null;
}

This is consistent with the existing pattern used in StartupFilter.java and TestInstallUtil.java within the same project.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

8.2 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.web:openmrs-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.7.8"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.8.5"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.openmrs.web:openmrs-web"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.8.0"
            },
            {
              "fixed": "2.8.6"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-40075"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-22"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-04T17:18:48Z",
    "nvd_published_at": "2026-05-05T22:16:00Z",
    "severity": "HIGH"
  },
  "details": "## Affected Versions\n\nversion \u2264 2.7.8 (latest version at time of disclosure)\n\nhttps://github.com/openmrs/openmrs-core\n\n## Impact\n\nThe `/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).\n\nThis 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.\n\n\u003e **Note:** Successful exploitation requires the target deployment to run on **Apache Tomcat \u003c 8.5.31**, where the `..;` path parameter bypass is not mitigated by the container. Deployments on Tomcat \u2265 8.5.31 / \u2265 9.0.10 are protected at the container level, though the underlying code defect remains.\n\u003e \n\n## Steps to Reproduce\n\n1. Identify a valid installed module ID on the target OpenMRS instance (e.g., `legacyui`).\n2. Send the following HTTP request:\n\n\u003cimg width=\"1038\" height=\"798\" alt=\"image\" src=\"https://github.com/user-attachments/assets/7d10ee0e-4d81-4c01-bc84-a1bf5715f170\" /\u003e\n\n3. The server responds with HTTP 200 and the contents of `/etc/passwd`:\n\n\u003cimg width=\"1028\" height=\"843\" alt=\"image\" src=\"https://github.com/user-attachments/assets/b6806a7e-ff52-4f51-8f7f-7ea4e9754d10\" /\u003e\n\n\n## Root Cause Analysis\n\nThe vulnerability exists in `ModuleResourcesServlet.java` (`web/src/main/java/org/openmrs/module/web/ModuleResourcesServlet.java`).\n\nThe `getFile()` method constructs a filesystem path from user-controlled input without performing path boundary validation:\n\n```java\nprotected File getFile(HttpServletRequest request) {\n    // Step 1: User-controlled path input\n    String path = request.getPathInfo();\n\n    // Step 2: Extract module from path prefix\n    Module module = ModuleUtil.getModuleForPath(path);\n    if (module == null) { return null; }\n\n    // Step 3: Strip module ID prefix \u2014 no traversal check\n    String relativePath = ModuleUtil.getPathForResource(module, path);\n\n    // Step 4: Concatenate into absolute path\n    String realPath = getServletContext().getRealPath(\"\")\n        + MODULE_PATH\n        + module.getModuleIdAsPath()\n        + \"/resources\"\n        + relativePath;  // contains \"/../../../etc/passwd\"\n\n    realPath = realPath.replace(\"/\", File.separator);\n\n    // Step 5: No normalize().startsWith() boundary check\n    File f = new File(realPath);\n    if (!f.exists()) { return null; }\n\n    return f;  // Arbitrary file returned to client\n}\n```\n\nThe helper method `ModuleUtil.getPathForResource()` only strips the module ID prefix and performs no sanitization:\n\n```java\npublic static String getPathForResource(Module module, String path) {\n    if (path.startsWith(\"/\")) {\n        path = path.substring(1);\n    }\n    return path.substring(module.getModuleIdAsPath().length());\n    // Returns unsanitized remainder, e.g., \"/../../../../../../etc/passwd\"\n}\n```\n\nThe resulting path resolves as:\n\n```\n{webapp}/WEB-INF/view/module/legacyui/resources/../../../../../../etc/passwd\n  \u2192 /etc/passwd\n```\n\nNotably, the same codebase already implements correct path traversal protection in `StartupFilter.java`:\n\n```java\n// StartupFilter.java \u2014 correct protection\nfullFilePath = fullFilePath.resolve(httpRequest.getPathInfo());\nif (!(fullFilePath.normalize().startsWith(filePath))) {\n    log.warn(\"Detected attempted directory traversal...\");\n    return;  // Request rejected\n}\n```\n\nThis check is absent from `ModuleResourcesServlet`.\n\n## Remediation\n\nAdd 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:\n\n```java\nFile f = new File(realPath);\nPath allowedBase = Paths.get(getServletContext().getRealPath(\"\"), \"WEB-INF\", \"view\", \"module\");\nif (!f.toPath().normalize().startsWith(allowedBase.normalize())) {\n    log.warn(\"Blocked path traversal attempt: {}\", request.getPathInfo());\n    return null;\n}\n```\n\nThis is consistent with the existing pattern used in `StartupFilter.java` and `TestInstallUtil.java` within the same project.",
  "id": "GHSA-jjgj-cx3q-pw4w",
  "modified": "2026-05-08T15:36:10Z",
  "published": "2026-05-04T17:18:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-jjgj-cx3q-pw4w"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-40075"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openmrs/openmrs-core"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenMRS ModuleResourcesServlet has Path Traversal that Leads to Arbitrary File Read"
}

CVE-2026-40075 (GCVE-0-2026-40075)

Vulnerability from cvelistv5 – Published: 2026-05-05 21:25 – Updated: 2026-05-06 14:33

Title

OpenMRS Core arbitrary file read via path traversal in ModuleResourcesServlet

Summary

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.

Severity

8.2 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator (v2.0.3)

CWE

CWE-22 - Improper Limitation of a Pathname to a Restricted Directory ('Path Traversal')

Assigner

GitHub_M

References

1 reference

URL	Tags
https://github.com/openmrs/openmrs-core/security/…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version
openmrs	openmrs-core	Affected: <= 2.7.8 Affected: >= 2.8.0, <= 2.8.5

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-40075",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-05-06T14:32:34.742099Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-05-06T14:33:02.685Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-jjgj-cx3q-pw4w"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "openmrs-core",
          "vendor": "openmrs",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 2.7.8"
            },
            {
              "status": "affected",
              "version": "\u003e= 2.8.0, \u003c= 2.8.5"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \u2014 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.\n\nAn 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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "PRESENT",
            "attackVector": "NETWORK",
            "baseScore": 8.2,
            "baseSeverity": "HIGH",
            "privilegesRequired": "NONE",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "NONE"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-22",
              "description": "CWE-22: Improper Limitation of a Pathname to a Restricted Directory (\u0027Path Traversal\u0027)",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-05-05T21:25:41.993Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-jjgj-cx3q-pw4w",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/openmrs/openmrs-core/security/advisories/GHSA-jjgj-cx3q-pw4w"
        }
      ],
      "source": {
        "advisory": "GHSA-jjgj-cx3q-pw4w",
        "discovery": "UNKNOWN"
      },
      "title": "OpenMRS Core arbitrary file read via path traversal in ModuleResourcesServlet"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-40075",
    "datePublished": "2026-05-05T21:25:41.993Z",
    "dateReserved": "2026-04-09T00:39:12.205Z",
    "dateUpdated": "2026-05-06T14:33:02.685Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted