CVE-2026-47754 in Metacat
Summary
by MITRE • 08/10/2026
Metacat is data repository software that helps researchers preserve, share, and discover data. Versions 2.x through 2.19.1 and all 1.x versions contain an unauthenticated path traversal in the `archiveEntryName` parameter of the `action=read` endpoint that is part of the original 1.x Metacat API. `ArchiveHandler.readArchiveEntry()` concatenates the user-supplied parameter into a filesystem path without validation, and the surrounding `hasReadPermission()` check is commented out. An unauthenticated remote attacker can read any file accessible to the Tomcat process by sending a single GET request. Proof-of-concept exploits have been demonstrated and verified against this vulnerability, and it should be considered easily exploitable for any Metacat deployment < 3.0.0 by any user with access to the 1.x API. Through this vulnerability, production 2.x deployments are exposed to credential theft, client certificate and private key exfiltration enabling member node impersonation within the federation, embargoed research data disclosure, and broad system reconnaissance. Given Metacat's deployment footprint across the DataONE network of repositories and federally funded research programs, the population of exposed 2.x instances is non-trivial. The vulnerability was eliminated in Metacat version 3.0.0 and after by eliminating the entire Metacat 1.x API that exposed this vulnerability. The vulnerability was remediated in April 2024 with the release of Metacat 3.0.0, which removed the legacy Metacat API including ArchiveHandler.java. The commit message and issue reference architectural cleanup, not a security fix, and no advisory or CVE was issued. The 2.x branch was not and will not be backported, as is standard practice in Metacat, which only supports the most current release. 2.19.1 remains vulnerable with identical code and is beyond its supported lifetime. As a workaround, disable or restrict 1.x API servlets. Because the vulnerable 1.x API is no longer used or necessary in most Metacat deployments, restricting access to the old API endpoints can reduce or eliminate exposure for 2.19.x deployments. After removing those features, restart Tomcat or whichever software is hosting the servlets.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/10/2026
The vulnerability exists within Metacat data repository software where versions 2.x through 2.19.1 and all 1.x versions contain a critical unauthenticated path traversal flaw in the `archiveEntryName` parameter of the `action=read` endpoint. This weakness resides in the original 1.x Metacat API and specifically affects the `ArchiveHandler.readArchiveEntry()` method which directly concatenates user-supplied input into filesystem paths without proper validation or sanitization. The security check that should have validated read permissions through `hasReadPermission()` has been commented out, rendering the system completely vulnerable to unauthorized file access. This design flaw enables any remote attacker with knowledge of the API endpoint to retrieve files accessible to the Tomcat process by simply sending a single GET request, making it exceptionally easy to exploit across all affected deployments.
The operational impact of this vulnerability extends far beyond simple information disclosure as demonstrated through verified proof-of-concept exploits. Attackers can leverage this weakness to steal credentials stored within the system, extract client certificates and private keys that enable impersonation attacks against member nodes within the DataONE federation, access embargoed research data that should remain confidential, and perform comprehensive system reconnaissance to identify additional vulnerabilities. The implications are particularly severe given Metacat's widespread deployment across the DataONE network of repositories and federally funded research programs, indicating a substantial population of vulnerable 2.x instances that require immediate attention. This vulnerability represents a classic case of CWE-22 Path Traversal, where insufficient input validation allows attackers to traverse file system paths beyond intended boundaries.
The remediation strategy implemented in Metacat version 3.0.0 addresses this issue through architectural cleanup rather than targeted security patching, as evidenced by the commit message and issue reference that focused on removing legacy components rather than addressing the specific vulnerability directly. The complete elimination of the vulnerable Metacat 1.x API including ArchiveHandler.java represents a fundamental architectural change that resolves the core problem at its source. This approach aligns with standard software maintenance practices where older unsupported versions receive no backports, and only the current release receives updates. Organizations running 2.19.1 remain exposed to this vulnerability as it exists in identical code form and falls outside its supported lifecycle, making it critical for deployments to either upgrade to version 3.0.0 or implement immediate workarounds.
The recommended mitigation approach involves disabling or restricting access to the legacy 1.x API servlets through network-level controls or application configuration changes that prevent unauthorized access to the vulnerable endpoints. This workaround is practical because the affected 1.x API is no longer used or necessary in most Metacat deployments, making it reasonable to reduce attack surface by limiting access to deprecated functionality. Organizations should implement these restrictions immediately and restart their Tomcat hosting services to ensure the changes take effect. The vulnerability's classification under ATT&CK technique T1213.002 (Data from Information Repositories) and its exploitation pattern aligns with common attack methodologies targeting data repository systems, emphasizing the importance of proper input validation and access control mechanisms in preventing such critical security flaws from being exploited in production environments.