CVE-2026-48114: Unauthenticated SQL Injection in NCEAS Metacat
Critical CVSS (9.8) reachable over local.
| Field | Value |
|---|---|
| CVE ID | CVE-2026-48114 |
| CVSS score | 9.8 Critical |
| Attack vector | Not retrieved from the current NVD response |
| Auth required | No, described as unauthenticated |
| Patch status | Fixed in Metacat 3.0.0 |
TL;DR - Critical unauthenticated SQL injection affects Metacat at
/harvesterRegistration. - Known affected versions are2.0.0 and above; fixed in3.0.0. - Patch urgently. No CISA KEV listing or explicit public PoC was identified from supplied sources.
Vulnerability at a glance
CVE-2026-48114 is a critical SQL injection vulnerability in NCEAS Metacat, a data repository platform used to preserve, share, and discover research data. The vulnerability is notable because it is described as unauthenticated and tied to a network-reachable application endpoint, /harvesterRegistration. According to the NVD description, unsafe SQL statement construction allows attacker-controlled input to reach the database without proper escaping.
The practical impact is severe. This is not a narrow information disclosure bug or a limited boolean-based injection. The vulnerability description specifically states that, because PostgreSQL permits stacked queries through Statement.executeUpdate(), exploitation can result in full read, write, and execute access in the Metacat database context. For defenders, that means the blast radius includes data tampering, unauthorized record creation or deletion, and potentially follow-on compromise depending on database privileges and adjacent application trust.
What is vulnerable
The affected product is NCEAS Metacat. The research note and NVD description state that Metacat versions 2.0.0 and above are affected and that the issue was remediated in 3.0.0. That wording should be read carefully: the source says “2.0.0 and above,” but it does not provide a more granular upper bound in the supplied material beyond the fact that 3.0.0 contains the fix.
Because the available source material does not enumerate every affected maintenance release between 2.0.0 and 3.0.0, defenders should assume that any Metacat deployment running a version in that line and not yet upgraded to 3.0.0 is at risk unless the vendor has separately documented a backport. In the absence of explicit backport information, the safest operational assumption is simple: if you are on Metacat 2.x or another pre-3.0.0 version covered by “2.0.0 and above,” treat it as vulnerable until verified otherwise.
What causes the issue
The root cause described in the NVD record is unsafe SQL construction inside the HarvesterRegistration.dbInsert() code path. The application builds an INSERT statement through string concatenation and uses a helper called quoteString() that merely wraps values in single quotes without escaping embedded quotes. That is a textbook SQL injection anti-pattern, but the consequences here are amplified by how the vulnerable endpoint is exposed and how the backend database behaves.
Three request parameters are specifically named as attacker-controlled inputs that reach the vulnerable sink: unit, contactEmail, and documentListURL. The same description also states that the servlet handling /harvesterRegistration does not verify a real LDAP identity, which is why the issue is classified as unauthenticated. Together, these details indicate a pre-auth input path into dynamically built SQL, with PostgreSQL accepting stacked queries under the execution method in use.
Technical Notes
The core behavior, as described by the source, can be summarized like this:
// Simplified conceptual example based on the advisory description
String sql = "INSERT INTO HARVEST_SITE_SCHEDULE (unit, contactemail, documentlisturl) VALUES ("
+ quoteString(unit) + ","
+ quoteString(contactEmail) + ","
+ quoteString(documentListURL) + ")";
statement.executeUpdate(sql);
The issue is that quoteString() is described as raw single-quote wrapping without escaping. In practice, defenders should assume payloads containing single quotes, semicolons, or comment markers may be relevant to exploitation attempts.
Affected versions and fixed version
Based on the supplied source material, the version information that can be stated confidently is:
| Scope | Version |
|---|---|
| Affected | 2.0.0 and above |
| Fixed | 3.0.0 |
That wording matters operationally. The source does not provide a complete CPE-style version range in the material you supplied, nor does it provide package names for every installation method. As a result, practitioners should inventory Metacat instances by application version rather than rely solely on OS package metadata or container tags that may obscure the running release.
If you run Metacat in a customized stack, confirm the effective application version from the deployed artifact, admin interface, or startup logs. If you cannot quickly verify versioning, assume exposure if the instance is internet-reachable and the /harvesterRegistration endpoint is enabled. This is especially important for research institutions and data repositories that may have legacy deployments with limited change visibility.
Exploitation status and attacker activity
At the time of this write-up, CISA KEV does not list CVE-2026-48114, so there is no CISA-confirmed evidence of active exploitation in the wild from that catalog. That is useful context, but it should not be misread as proof of safety. KEV absence only tells you that CISA has not listed it as a known exploited vulnerability in that program at the time of lookup.
As for public exploit material, the supplied references identify a patch commit and a GitHub security advisory, but no explicit public proof-of-concept repository was identified in the provided sources. Therefore, the most accurate statement is: no confirmed in-the-wild exploitation from CISA KEV and no explicit public PoC identified in the supplied references. In the absence of confirmed exploit data, defenders should still prioritize remediation because the vulnerability details are specific enough to guide exploit development.
Why this matters in real environments
A critical unauthenticated SQL injection on a metadata repository is not just a confidentiality issue. Metacat deployments may hold important research metadata, scheduling information, integration details, and connections to downstream workflows. If the database account has broad privileges, an attacker could alter records, disrupt harvesting schedules, poison metadata, or establish persistence in application data structures.
The source description explicitly mentions full read/write/execute access in the Metacat database context. That phrasing is important because it suggests compromise potential beyond a single row insert. Even if operating system code execution is not stated, database-context execute capability can still be serious, especially where the database account can call dangerous functions, manipulate stored procedures, or alter application state in a way that affects trust and availability.
Detection and threat hunting
Detection should focus on access to the /harvesterRegistration endpoint and on suspicious values in the parameters named by the advisory: unit, contactEmail, and documentListURL. Since the vulnerability involves SQL injection through quote handling and potentially stacked queries, look for characters and sequences that rarely appear in normal registration workflows, such as single quotes, semicolons, SQL comments, or database function names.
You should also correlate web access logs with database errors and unusual write activity around harvesting-related tables. Because the vulnerable code is described as inserting into HARVEST_SITE_SCHEDULE, unexpected changes to that table or related scheduling records may be a useful pivot. In environments without detailed application logging, reverse proxy logs and PostgreSQL statement logs may provide the earliest signal.
Technical Notes
Example web log patterns to review:
POST /harvesterRegistration HTTP/1.1
Look for suspicious request bodies or query strings containing the named parameters:
unit='
contactEmail='
documentListURL='
unit=%27
contactEmail=%27
documentListURL=%27
Simple grep examples for access logs:
grep -E 'harvesterRegistration' /var/log/nginx/access.log
grep -E "harvesterRegistration.*(unit=|contactEmail=|documentListURL=).*(%27|;|--)" /var/log/nginx/access.log
grep -RiE "(%27|;|--).*(unit|contactEmail|documentListURL)|(unit|contactEmail|documentListURL).*(%27|;|--)" /var/log/httpd/
If PostgreSQL logging is enabled, search for stacked-query indicators or unexpected statements touching the relevant table:
grep -E "HARVEST_SITE_SCHEDULE|syntax error at or near|unterminated quoted string|statement:" /var/log/postgresql/*.log
Example Splunk-style query for web logs:
index=web (uri_path="/harvesterRegistration" OR request="/harvesterRegistration")
| search ("unit=" OR "contactEmail=" OR "documentListURL=")
| regex _raw="(%27|'|;|--|/*|*/)"
| stats count by src_ip, http_method, uri_path, status
These patterns are heuristics, not signatures of confirmed exploitation. Because no official detection guidance was supplied in the source material, defenders should tune for their own traffic patterns and treat false positives as likely in lightly normalized logs.
Mitigation and patching
The primary remediation is to upgrade to Metacat 3.0.0, which the source material identifies as the fixed version. If you operate multiple Metacat instances, prioritize externally accessible systems first, then internal systems reachable by untrusted users or partner networks. This vulnerability is pre-auth and high impact, so maintenance windows should be accelerated where possible.
If you cannot upgrade immediately, reduce exposure to /harvesterRegistration at the network, reverse proxy, or WAF layer. Because the issue is endpoint-specific in the disclosed description, temporary access restrictions can materially lower risk while you prepare the full application upgrade. Also review the privileges of the Metacat database account. SQL injection impact often scales with database permissions; reducing unnecessary privileges may limit damage if exploitation occurs before patching.
Technical Notes
The exact upgrade command depends on how Metacat was installed, and the supplied sources do not document one authoritative package manager command. Do not guess the package name in production. Instead, verify the deployed method and upgrade the application artifact to Metacat 3.0.0 using your established release process.
For containerized or manually deployed environments, the practical workflow is typically:
# Example verification step: confirm current deployed version from app files or logs
grep -R "Metacat" /opt /srv /var/log 2>/dev/null | head
As a temporary reverse proxy workaround, block or restrict the vulnerable endpoint until the upgrade is complete. Example NGINX snippet:
location = /harvesterRegistration {
allow 10.0.0.0/8;
deny all;
return 403;
}
Or, if the endpoint is not needed, disable public access entirely:
location = /harvesterRegistration {
return 403;
}
After changes, reload the proxy:
nginx -t && systemctl reload nginx
For Apache httpd, a temporary restriction could look like:
<Location "/harvesterRegistration">
Require ip 10.0.0.0/8
</Location>
Then reload:
apachectl configtest && systemctl reload httpd
These workarounds are compensating controls, not substitutes for the fixed release. The durable fix is upgrading to 3.0.0.
References
The primary references for this CVE are the NVD entry, the upstream patch commit, and the GitHub security advisory. Those are the sources backing the version statements, endpoint identification, root cause summary, and fix version used in this article.
- NVD record for CVE-2026-48114
- Patch commit:
https://github.com/NCEAS/metacat/commit/820d595309b399fdbdf4983bd1b1dd795773472a - Security advisory:
https://github.com/NCEAS/metacat/security/advisories/GHSA-wrc6-rc34-hrcg
For further reading on related vulnerabilities, check out our articles on CVE-2026-42613 and CVE-2026-06-02 Palo Alto Exploited Chrome Zero-Day Patched and Three Critical CVEs.
If some operational details remain unknown in your environment, such as the precise install method or whether an internal fork includes the fix, treat that uncertainty as a risk factor. For a CVSS 9.8 unauthenticated SQL injection with database compromise potential, the conservative response is the correct one: identify exposure, restrict the endpoint, validate logs, and upgrade to Metacat 3.0.0 as quickly as your change process allows.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.