Metacat CVE-2026-48528: the public CN API can compromise the database

CVE-2026-48528, a critical SQL injection vulnerability in Metacat, was published on 14 August 2026. Versions 2.0.0 through 3.4.0 are affected, while release 3.4.1 contains the fix. The flaw sits in the Coordinating Node API endpoints /cn/v1/object and /cn/v2/object. Their nodeId parameter is appended to SQL without correct binding, and the request requires no authentication.

Metacat stores and shares research data and metadata in the DataONE ecosystem. That context changes the impact assessment: this is not simply an application table, but a repository whose trustworthiness, access control and provenance matter to science and institutional collaboration. The NCEAS advisory scores the issue 9.8 under CVSS 3.1 and describes both database disclosure and modification.

Where the injection occurs

The vulnerable flow starts with a request to the CN interface. The nodeId value is meant to identify a node, but the application includes it in SQL text instead of passing it as a separate driver parameter. Once data and statement structure are mixed, an attacker can close the expected fragment and add new logic.

No Metacat account is required. Public reachability is enough to send repeated requests and observe responses. That lowers the cost of attack even for an instance serving a small research group if its API remains externally accessible.

The advisory describes PostgreSQL error messages reflected in the XML response. An attacker can intentionally provoke a conversion failure, for example by placing a subquery result inside a CAST operation. The selected record is then exposed in the returned message. This is error-based SQL injection: the database error channel becomes the data-exfiltration channel.

By repeating requests, information can be extracted without any ordinary record-listing view. The project’s analysis also reports the ability to execute INSERT, UPDATE and DELETE statements, so the issue is not limited to confidentiality. It also reaches repository integrity and availability.

What information is at risk

A Metacat catalogue may contain descriptions of research datasets, object identifiers, contributor information and relationships. Its database may also hold ORCID identifiers, client IP addresses, access logs and access-control lists. Exact contents vary by deployment, so an administrator should model exposure against the real schema and stored records rather than the generic product label.

Compromised ACL data may expose objects intended to remain private. Modified metadata can break the relationship between a dataset and its author, version or terms of use. If the repository participates in federation or supplies downstream tools, false information can propagate beyond the original instance.

Integrity can matter as much as confidentiality in a research setting. A changed identifier, methodology description or version relationship can affect reproducibility. Obvious destruction is noticed quickly; a subtle edit may remain in circulation for much longer.

Access logs and IP addresses also create a privacy concern. If disclosure cannot be excluded, involve the relevant data owner or privacy function in the incident assessment. The CVE explains a technical mechanism, while notification duties depend on organisational context and jurisdiction.

Upgrading is the primary action

Administrators should upgrade Metacat to 3.4.1 or later. Before changing the deployment, create a consistent backup of the database, configuration and object store, then test restoration. After rollout, confirm that every public endpoint is genuinely served by the new application version and that no old container, WAR artefact or cluster node remains behind the load balancer.

Version scanning is only the start. Because exploitation needs no login and may support writes, a historical review is required after patching. Compare schema and records with a trusted backup, inspect recent ACL, author and identifier changes, and review bulk deletions or updates. Rotate the database credential and other secrets available to the process if wider access cannot be excluded.

For container deployments, replacing an image does not automatically erase the impact. The database and object store normally use persistent volumes. A new image repairs code while preserving records modified beforehand.

A safe workaround when an upgrade must wait

The advisory provides a practical containment option: most DataONE member repositories do not need Coordinating Node endpoints. If an instance is not acting as a CN, operators can remove the v1 and v2 servlet mappings responsible for those routes. The fix guidance names edu.ucsb.nceas.metacat.restservice.v1.CNRestServlet and its v2 counterpart in web.xml.

Apply this workaround only after confirming the node’s role and testing federation communication. Removing a link from the interface is not enough. Requests must be rejected by the application server or an upstream reverse proxy. Cover both API versions, alternate path forms and URL normalisation.

If the endpoint is operationally required, restrict it to known network sources, enforce authentication at the proxy and monitor every call. Those steps reduce exposure but are not equivalent to fixing the code. An internal client or compromised host may still reach the vulnerable path.

Detection and forensic review

Search HTTP logs for calls to /cn/v1/object and /cn/v2/object carrying nodeId. Valuable indicators include unusual quotes, SQL comments, words such as CAST, SELECT and UNION, percent-encoded sequences and a high volume of similar failed requests. Avoid exact-signature-only hunting because attackers can vary syntax.

Review 500 responses and XML bodies containing PostgreSQL messages. A sequence of conversion errors may indicate error-based extraction. At the database layer, inspect statements executed by the Metacat account, especially table-changing instructions, unusual subqueries and activity outside the instance’s normal rhythm.

Correlate reverse-proxy, application and PostgreSQL records by time. Preserve raw logs before rotation and copy them away from the examined host. If suspicious writes are found, do not automatically restore an entire database before establishing the starting point; an apparently recent backup may already contain compromised records.

A quiet WAF is not proof of safety. The WAF may not interpret decoding in the same way as the application, and a careful attacker can split extraction across many low-noise requests. The strongest evidence combines log analysis with record-integrity verification.

Lessons for data API design

Every database-bound value remains data even when it represents a node identifier, collection name or infrastructure object. Identifiers can additionally be validated against a strict format, but a prepared statement is still foundational. Validation reduces mistakes and surface; parameterisation separates data from SQL grammar.

Database messages should never be reflected to a public client. Operators need details in protected logs, while the caller should receive a stable error code and event identifier. This restricts error-based extraction and prevents disclosure of schema or table names during unrelated failures.

The application’s database account should have the smallest necessary rights. If a specific endpoint is read-only, a separate path or database role can limit consequences. Research repositories can also version important metadata and sign manifests so that changes can be detected independently.

Security tests must go beyond ordinary forms. Federation-protocol parameters, node identifiers and administrative features often receive less attention because they look like system data. At a trust boundary they remain client-controlled input.

Facts, Breachroad conclusions and next steps

The advisory establishes that Metacat 2.0.0 through 3.4.0 is vulnerable, that two unauthenticated CN routes enable error-based extraction and database-changing operations, and that 3.4.1 contains the fix. It also documents disabling CN servlets as a workaround for nodes that do not require them. The advisory itself does not prove widespread exploitation on the Internet.

Breachroad’s conclusion is that integrity review deserves the same urgency as patching. A data repository can remain technically available while metadata or ACLs have been silently changed. A complete response combines the update, evidence review, comparison with trusted state and privacy assessment.

If you operate a public repository, management panel or database-backed API, our web application and API penetration testing can validate parameterisation, access control and safe error handling. Teams can turn the case into repeatable engineering practice through cybersecurity training for organisations focused on developer and operator decisions.