CVE-2026-48528 in Metacat
Summary
by MITRE • 08/14/2026
Metacat is data repository software that helps researchers preserve, share, and discover data. Metacat versions 2.0.0 through 3.4.0 contain an unauthenticated SQL injection vulnerability in the `/cn/v1/object` and `/cn/v2/object` REST API endpoints due to unsanitized user input that can be passed through to the backend SQL database. The `nodeId` parameter can be modified to inject SQL commands, and the results are returned in error messages. Metacat appends the user-supplied data into the sql query without sanitization or parameterization. This allows extraction of arbitrary data from the underlying PostgresQL database, fully exposing protected information to the attacker. This is accomplished by leveraging the error reporting mechanisms in Metacat, where SQL error responses are mirrored back to the caller in the XML error message returned by Metacat. One approach, for example, is to use the PostgreSQL `CAST` function to generate an error with the results of an arbitrary subquery, which is then injected into the XML error message returned by Metacat. Attackers do not need to be authenticated to execute the attack. In addition, arbitrary SQL statements that insert, update, and delete data in the Metacat database can be executed, resulting in full compromise of all data in the database. Full proof of concept attacks have been developed and verified for these vulnerabilities. The impact of this vulnerability is critical for Metacat deployments in the DataONE network where information from the database can be exfiltrated, added, changed, or deleted. This includes management information about the data catalog, access log information about who accessed data, identifying information about individuals including their ORCID identifier and client IP address, access control information about who should be able to access and modify data, and other critical internals of the data system. This sql injection vulnerability was remediated fully in Metacat version 3.4.1. If upgrading to Metacat 3.4.1 isn't immediately possible, most deployments can mitigate the issue by disabling the `/cn` REST endpoints in the webapp deployment. This API is not needed or used by member repositories in the DataONE network, as it is only used by the DataONE Coordinating Node deployments. Consequently, this API can be disabled without reduction of functionality for most deployments. To disable the vulnerable endpoints, simply remove the servlet and servlet-mapping for the `/cn` endpoints in the servlet engine associated with the two servlets, `edu.ucsb.nceas.metacat.restservice.v1.CNRestServlet` and `edu.ucsb.nceas.metacat.restservice.v2.CNRestServlet`. For example, in Tomcat, remove the relevant `servlet-mapping` elements from the application web.xml file in Metacat.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/14/2026
This vulnerability represents a critical security flaw in Metacat data repository software affecting versions 2.0.0 through 3.4.0, specifically within the Coordinating Node REST API endpoints at `/cn/v1/object` and `/cn/v2/object`. The issue stems from improper input validation and sanitization practices where user-supplied parameters are directly concatenated into SQL queries without proper parameterization or escaping mechanisms. This fundamental flaw falls under CWE-89 which categorizes SQL injection vulnerabilities, and aligns with ATT&CK technique T1190 for exploitation of remote services through injection attacks.
The technical implementation of this vulnerability allows attackers to manipulate the `nodeId` parameter to inject malicious SQL commands into the backend PostgreSQL database. The vulnerability is particularly dangerous because it leverages error-based SQL injection techniques where database error messages are returned directly to the client in XML format, enabling data exfiltration through carefully crafted subqueries. Attackers can utilize PostgreSQL's CAST function to force errors that contain the results of arbitrary SELECT statements, effectively bypassing normal query execution boundaries and exposing sensitive database content.
The operational impact of this vulnerability is severe and encompasses complete database compromise including unauthorized data access, modification, and deletion capabilities. The affected system contains highly sensitive information such as management details about data catalogs, access logs with user identification including ORCID identifiers and IP addresses, access control configurations, and other critical internal system data. This represents a comprehensive breach of data confidentiality and integrity, potentially exposing personal information and operational details that could be exploited for further attacks within the DataONE network infrastructure.
The remediation approach recommended by the vendor involves upgrading to Metacat version 3.4.1 which implements proper parameterized queries and input sanitization mechanisms to prevent SQL injection attacks. However, organizations unable to perform immediate upgrades can implement a network-level mitigation strategy by disabling the vulnerable `/cn` REST endpoints entirely. This is particularly effective because these endpoints are not utilized by member repositories in the DataONE network, serving only the coordinating node deployments. The mitigation involves removing specific servlet mappings from the web.xml configuration file in Tomcat environments, specifically targeting the `CNRestServlet` classes responsible for handling the vulnerable API endpoints.
Security practitioners should recognize this vulnerability as a prime example of how insufficient input validation can lead to complete system compromise, particularly in data repository systems where access to sensitive research data is paramount. The ease of exploitation and the comprehensive nature of potential data exposure make this vulnerability particularly concerning for organizations deploying Metacat within research networks where data protection and privacy are critical requirements. The implementation of proper parameterized queries and input validation remains essential defensive measures against similar injection vulnerabilities across all database-driven applications in accordance with security best practices and industry standards.
The vulnerability demonstrates the importance of maintaining current software versions and implementing defense-in-depth strategies including API endpoint access controls, especially for administrative or coordinating node functionalities that are not required by standard operational deployments. Organizations should conduct comprehensive assessments of their Metacat installations to identify all potentially affected versions and implement appropriate mitigations while planning for secure upgrades to prevent future exploitation attempts targeting similar input validation flaws in their data management systems.