A critical unauthenticated SQL injection vulnerability (CVE-2026-48114) has been publicly disclosed in Metacat versions 2.x through 2.19.1, exposing scientific data repositories built on DataONE, KNB, the Arctic Data Center, and ESS-DIVE to full PostgreSQL read/write/execute access without authentication.
Published as GitHub Security Advisory GHSA-wrc6-rc34-hrcg and assigned a maximum-impact CVSS v3.1 score of 10.0, this flaw ranks among the most severe vulnerabilities disclosed in scientific data infrastructure this year. Organizations that are still running any Metacat 2.x branch are urged to upgrade immediately to Metacat 3.0.0 or later.
Metacat is open-source, Java-based data repository software developed by the National Center for Ecological Analysis and Synthesis (NCEAS) at UC Santa Barbara.
It enables researchers to preserve, share, and discover scientific datasets at scale, storing hundreds of thousands of datasets in a standardized, searchable format.
Metacat powers the backbone of major scientific data infrastructure, including DataONE, the Knowledge Network for Biocomplexity (KNB), the NSF Arctic Data Center, and ESS-DIVE. Its MetacatUI client interface is deployed across numerous federations and member repositories worldwide.
The vulnerability exists in the /harvesterRegistration endpoint of Metacat’s legacy 1.x API servlet layer. The core flaw lives in HarvesterRegistration.dbInsert(), which constructs an INSERT statement against the HARVEST_SITE_SCHEDULE table using raw string concatenation instead of parameterized queries.
A quoteString() helper method applies only raw single-quote wrapping without any escaping of special SQL characters a classic and catastrophic sanitization failure.
Three user-controlled HTTP request parameters flow directly into this unsanitized sink:
unit— harvesting unit identifiercontactEmail— site contact email fielddocumentListURL— URL of the document list to harvest
Since PostgreSQL permits stacked queries via Statement.executeUpdate(), an attacker can inject a second, arbitrary SQL statement immediately after the INSERT, granting unrestricted access to the entire database.
The attack requires zero authentication; the servlet does not verify a real LDAP identity before allowing the vulnerable insert to proceed.
Beyond the direct injection, a second-order SQL injection vector also exists in this vulnerability chain. An attacker-controlled documentListURL is fetched asynchronously by Metacat’s scheduled harvester process.
During parsing, the <scope> element extracted from the harvested document flows back into the database unsanitized.
This means even if the primary endpoint were rate-limited or partially restricted, a persistent payload planted through documentListURL could execute malicious SQL at harvest time making remediation via endpoint blocking alone insufficient without also disabling the harvester scheduler.
Successful exploitation provides a remote, unauthenticated attacker with full read, write, and execute access to the Metacat PostgreSQL database, including:
- Credential theft — database usernames, passwords, and session tokens
- Data exfiltration — the complete
xml_documentscorpus containing scientific metadata - Data integrity destruction — arbitrary modification or deletion of research records
- Privilege escalation — potential OS-level command execution via PostgreSQL
COPY ... FROM PROGRAMif the database user holds sufficient privileges
While Metacat’s footprint across DataONE, KNB, the Arctic Data Center, and ESS-DIVE is substantial, most production deployments have already migrated to the 3.x release line, limiting the exposed population. However, any remaining Metacat 2.x deployment, including legacy institutional instances, remains fully vulnerable with identical unpatched code in version 2.19.1.
Patch & Remediation
The vulnerability was silently remediated in Metacat 3.0.0 via commit 820d595 in 2023 through the complete removal of the harvesterClient package. However, no formal security advisory was issued at that time, leaving 2.x users unaware of the risk. The 2.x branch has not been and will not be backported with a security fix, as Metacat only maintains the most current major release.
Recommended Actions:
- Upgrade immediately to Metacat ≥ 3.0.0, preferably the latest stable release (currently ≥ 3.4.0)
- Disable HarvesterServlet endpoints in Apache Tomcat by removing all servlet and servlet-mapping entries for
edu.ucsb.nceas.metacat.harvesterClient.HarvesterServlet,HarvesterRegistration,HarvesterRegistrationLogin, andDataProviderfrom yourweb.xmlconfiguration file - Restrict 1.x API access at the network or WAF layer to block external access to
/harvesterRegistrationand related endpoints - Rotate all database credentials stored in any Metacat 2.x instance immediately, as they must be treated as compromised
- Audit PostgreSQL logs for unexpected
INSERT,SELECT, or stacked query patterns againstHARVEST_SITE_SCHEDULE
Frequently Asked Questions
Q1: Does CVE-2026-48114 affect Metacat 3.x users?
No, Metacat 3.0.0 and later are not affected, as the entire harvesterClient package (including the vulnerable servlet) was removed in that release.
Q2: Can a WAF or firewall fully mitigate this vulnerability without upgrading?
Blocking external access to the /harvesterRegistration endpoint reduces exposure, but the second-order injection via the harvester scheduler remains a risk unless the servlet is fully disabled or the application is upgraded.
Q3: Why was no CVE issued when the fix was committed in 2023?
The fix was delivered silently as part of a major version refactor in 2023 without a dedicated security advisory, meaning 2.x users had no formal notification of the underlying risk, a gap this advisory now closes.
Q4: What makes this a CVSS 10.0 rather than a lower critical score?
The combination of a network-accessible attack vector, low complexity, no privileges required, no user interaction, and high impact across all three pillars, confidentiality, integrity, and availability, yields the maximum CVSS v3.1 base score of 10.0.
Site: thecybrdef.com
For more insights and updates, follow us on Google News, Twitter, and LinkedIn.