CVE-2026-47754: Metacat Path Traversal Vulnerability

CVE-2026-47754 Overview

CVE-2026-47754 is an unauthenticated path traversal vulnerability in Metacat, the data repository platform used by researchers to preserve, share, and discover data. The flaw resides in the archiveEntryName parameter of the action=read endpoint exposed by the legacy Metacat 1.x API. ArchiveHandler.readArchiveEntry() concatenates user-supplied input into a filesystem path without validation, and the surrounding hasReadPermission() check is commented out. A remote attacker can read any file readable by the Tomcat process using a single GET request. All Metacat 1.x versions and 2.x through 2.19.1 are affected. The issue was silently remediated in Metacat 3.0.0.

Critical Impact

Unauthenticated remote attackers can exfiltrate credentials, TLS client certificates, private keys, and embargoed research data, enabling member node impersonation across the DataONE federation.

Affected Products

• Metacat 1.x (all versions)
• Metacat 2.x through 2.19.1
• DataONE member node deployments running vulnerable Metacat releases

Discovery Timeline

• April 2024 - Vulnerable code path removed in Metacat 3.0.0 release (no advisory issued at the time)
• 2026-08-10 - CVE-2026-47754 published to NVD
• 2026-08-10 - Last updated in NVD database

Technical Details for CVE-2026-47754

Vulnerability Analysis

The vulnerability is a classic path traversal [CWE-22] within the legacy Metacat 1.x servlet API. When a client submits a GET request with action=read and an archiveEntryName parameter, ArchiveHandler.readArchiveEntry() builds a filesystem path by concatenating the attacker-controlled value without canonicalization or allow-list validation. Because the enclosing hasReadPermission() authorization check is commented out, no session, credential, or ACL is evaluated before the file read. The servlet returns the raw contents to the caller.

Proof-of-concept requests have been demonstrated against production configurations. Because Metacat runs under Tomcat, any file readable by the Tomcat OS user is retrievable, including configuration files with database credentials, DataONE client certificates, private keys, and embargoed data objects staged on disk.

Root Cause

Two defects combine: missing input validation on archiveEntryName and an absent authorization gate. The 1.x API was retained for backward compatibility in the 2.x branch but was never hardened. Metacat 3.0.0 removed the entire legacy API surface, including ArchiveHandler.java, eliminating the vulnerable code path.

Attack Vector

Exploitation requires only network reachability to the Metacat servlet. No credentials, user interaction, or prior reconnaissance are required. An attacker issues a single GET against action=read with a traversal sequence in archiveEntryName to read arbitrary files.

// Security patch excerpt from src/edu/ucsb/nceas/metacat/MetacatHandler.java
// The fix disables the actions of the Metacat 1.x API rather than sanitizing input.
     * @param response
     * @throws IOException
     */
-    private void sendNotSupportMessage(HttpServletResponse response) throws IOException {
+    protected void sendNotSupportMessage(HttpServletResponse response) throws IOException {
        PrintWriter out = null;
        try {
            out = response.getWriter();
// Source: https://github.com/NCEAS/metacat/commit/07e034b2bbf7029e28af32f472f4d70ea6b5ab1b

// Security patch excerpt from src/edu/ucsb/nceas/metacat/util/DocumentUtil.java
// The legacy isAuthorized() helper tied to the 1.x API was removed entirely.
-    public static void isAuthorized(PrintWriter out, Hashtable<String,String[]> params,
-            HttpServletRequest request, HttpServletResponse response) throws MetacatUtilException {
-        String resourceLsid;
-        String[] resourceLsids = params.get("resourceLsid");
-        if (resourceLsids == null) {
-            throw new MetacatUtilException("DocumentUtil.isAuthorized - " +
-                    "resourceLsid parameter cannot be null.");
-        }
-        resourceLsid = resourceLsids[0];
-        String permission;
-        String[] permissions = params.get("permission");
-        if (permissions == null) {
-            throw new MetacatUtilException("DocumentUtil.isAuthorized - " +
-                    "permission parameter cannot be null.");
-        }
-        permission = permissions[0];
// Source: https://github.com/NCEAS/metacat/commit/07e034b2bbf7029e28af32f472f4d70ea6b5ab1b

Detection Methods for CVE-2026-47754

Indicators of Compromise

• HTTP GET requests to the Metacat servlet containing action=read combined with an archiveEntryName parameter, particularly with ../ sequences or absolute paths.
• Tomcat access log entries referencing sensitive paths such as /etc/passwd, metacat.properties, or DataONE certificate directories.
• Unexpected outbound authentication from DataONE member nodes using previously idle client certificates, suggesting impersonation after key theft.

Detection Strategies

• Parse Tomcat access logs for the string archiveEntryName= and alert on any value containing .., URL-encoded traversal (%2e%2e), or paths outside the expected archive directory.
• Deploy a WAF or reverse-proxy rule that blocks or logs requests to the 1.x API endpoints (/metacat servlet paths) and inspect request bodies for traversal patterns.
• Correlate file-access telemetry on the Metacat host with servlet requests to identify reads of credential files or .pem/.key artifacts driven by Tomcat.

Monitoring Recommendations

• Baseline legitimate 1.x API usage; in most modern deployments the surface should be effectively unused and any traffic warrants investigation.
• Monitor for read access by the Tomcat process user to files outside Metacat's designated data directories.
• Rotate and monitor DataONE client certificates and database credentials, treating any exposure of the Metacat host as potentially compromising these secrets.

How to Mitigate CVE-2026-47754

Immediate Actions Required

• Upgrade to Metacat 3.0.0 or later, which removes the legacy 1.x API and eliminates ArchiveHandler.java.
• Where upgrade is not immediately feasible, block or restrict the 1.x API servlet paths at the reverse proxy or Tomcat configuration layer.
• Rotate database credentials, DataONE client certificates, and private keys stored on affected hosts, assuming they may have been read.
• Audit Tomcat access logs for prior exploitation attempts referencing archiveEntryName.

Patch Information

The vulnerable code was removed in Metacat 3.0.0 (April 2024) as part of architectural cleanup that eliminated the entire Metacat 1.x API. The 2.x branch, including 2.19.1, remains vulnerable and will not receive a backport; the project only supports the current release line. See the GitHub Security Advisory GHSA-m852-f287-7cgw, the remediation commit, and the associated pull request.

Workarounds

• Disable the 1.x servlet mappings in Tomcat's web.xml for deployments that cannot upgrade.
• Restrict access to legacy API endpoints using firewall or reverse-proxy allow-lists limited to trusted internal callers.
• After removing or restricting the 1.x features, restart Tomcat (or the hosting servlet container) to load the new configuration.
• Run Tomcat as a low-privilege user with filesystem ACLs that deny read access to credential and key material outside the Metacat data directory.

# Example Tomcat reverse-proxy rule (nginx) to block the vulnerable action
location /metacat {
    if ($arg_action = "read") {
        return 403;
    }
    proxy_pass http://metacat_backend;
}