# Unpatched GeoServer Zero-Day SQL Injection in jsonArrayContains (GHSA-mqjf-5f49-2fjh) Enables Unauthenticated RCE via PostGIS

> A zero-day SQL injection in GeoServer's jsonArrayContains OGC filter function (GHSA-mqjf-5f49-2fjh, CVSS 9.8) lets unauthenticated attackers inject arbitrary SQL against PostGIS-backed layers, escalating to remote code execution via PostgreSQL's COPY TO PROGRAM when the database role has elevated privileges. Disclosed without coordination on 2026-08-12 by researcher q1uf3ng, it was under active internet-wide probing within hours (per WatchTowr) before GeoServer 3.0.1/2.28.5/2.27.6 patched it on 2026-08-14.

- **Published:** 2026-08-16T00:00:00Z
- **Last reviewed:** 2026-08-16T00:00:00Z
- **Canonical:** https://intel.threadlinqs.com/threat/TL-2026-2035
- **ID:** TL-2026-2035
- **Severity:** CRITICAL (CVSS 9.8)
- **Category:** VULNERABILITY
- **Status:** ACTIVE
- **Detections:** 9 · **IOCs:** 12 (full data via the Threadlinqs MCP server — Purple tier)

## Description

GeoServer's jsonArrayContains(<column>, <pointer>, <value>) filter expression, implemented in GeoTools' PostGIS JDBC datastore module (org.geotools:gt-jdbc-postgis), writes the caller-supplied <value> argument directly into generated SQL without escaping. Against a PostGIS 12+ backed layer with a String or JSON field, this lets an unauthenticated remote attacker break out of the intended query string and inject arbitrary SQL through the OGC Filter/CQL_FILTER interface used by WFS GetFeature and related OWS requests. GeoTools' security advisory (GHSA-mqjf-5f49-2fjh, CVSS 9.8, CWE-89) confirms the flaw is a direct regression of CVE-2023-25158 — a 2023 OGC Filter SQL injection in JDBCDataStore implementations — and explicitly notes that CVE-2023-25158's mitigation (enabling prepared statements / disabling encode functions) does not stop this new variant; the advisory further states that setting the JDBC preferQueryMode to extended does not eliminate the raw string-concatenation sink either. The GHSA formally scopes exploitation impact to unauthenticated read, modification, AND deletion of database content (Confidentiality/Integrity/Availability all rated High), not merely disclosure.

Publicly released proof-of-concept code (GitHub repo GeoServer-jsonArrayContains-PG-RCE and an accompanying gist) demonstrates the full exploit chain: a single quote in the injected value breaks the jsonb_path_exists(...) string context, stacked queries are then used to run PostgreSQL's COPY (SELECT 1) TO PROGRAM '<command>', which executes an arbitrary OS command as the database service account. The PoC author notes the attack must be delivered via WFS 2.0 finite-limit/count-style requests specifically — payloads are not interchangeable with WMS GetMap requests, since the two request types traverse different query-building paths with different bracket/alias/trailing-clause structure — and that the PoC intentionally uses local file writes as proof-of-execution markers rather than reverse shells, requiring an explicit --execute flag to prevent accidental live deployment. This RCE path requires the connecting database role to hold the pg_execute_server_program attribute or superuser status — a configuration WatchTowr and others flag as common in default/lower-friction GeoServer-to-PostGIS deployments; the PoC repository explicitly cautions this is not an 'any GeoServer instance can be directly RCE'd' finding. The same stacked-query primitive supports blind boolean/time-based extraction (pg_sleep-based payloads) for reading arbitrary database content even without RCE-level privileges.

The vulnerability was disclosed on X by researcher @q1uf3ng on 2026-08-12 at 10:46 UTC without prior coordination with the GeoServer project, leaving it unpatched with no CVE identifier at disclosure time. WatchTowr (analyst Jake Knott) reported observing hundreds of exploitation/probing attempts against internet-facing GeoServer instances within hours, originating from a small number of source IP addresses; as of the initial wave of reporting (2026-08-13), activity was characterized as reconnaissance — probes triggering database errors to build target lists — with no confirmed follow-on payload delivery or compromise. The GeoServer Project Steering Committee shipped fixed releases (3.0.1, 2.28.5 LTS, 2.27.6) on 2026-08-14, crediting Andrea Aime (GeoSolutions) and Jody Garnett (GeoCat) for the expedited remediation work; the GeoTools GHSA itself (patching gt-jdbc-postgis to 35.1/34.5/33.6), formally published 2026-08-15, separately credits reporters qquang, mrlihd, PhilipPhil, and Quikko — distinct individuals from both the public discloser (@q1uf3ng) and the two developers who implemented the fix, indicating the flaw reached the GeoTools security team through a coordinated report in parallel with (or shortly after) q1uf3ng's public disclosure.

Early secondary reporting was inconsistent on which database backends are affected: SecurityWeek's original report referenced 'PostGIS and Oracle JDBC data stores,' Field Effect's coverage separately referenced H2 database configurations as an RCE-capable backend, and other outlets separately referenced Microsoft SQL Server deployments. The authoritative technical sources — the GHSA advisory and the public PoC — confirm and scope the flaw specifically to the PostGIS JDBC datastore module (org.geotools:gt-jdbc-postgis); this research treats the PostGIS/PostgreSQL exploitation path as evidenced and the Oracle JDBC/H2/MSSQL claims as unconfirmed secondary reporting worth tracking but not yet corroborated by a technical advisory or PoC.

GeoServer has a documented history of being mass-exploited once vulnerability details become public: CVE-2024-36401 (unsafe XPath evaluation via commons-jxpath, CVSS 9.8) was added to the CISA KEV catalog in July 2024 after being used at scale for web shell deployment, DDoS botnets, and cryptocurrency mining, including a documented compromise of a U.S. federal agency within two weeks of disclosure with subsequent botnet and reported espionage-linked activity. Given that history and the platform's exposure across government, education, engineering, and geospatial-data-dependent sectors, defenders should treat the reconnaissance activity already observed as a leading indicator of imminent mass exploitation rather than a contained event.

## MITRE ATT&CK

- T1595.002 Vulnerability Scanning
- T1587.004 Exploits
- T1588.006 Vulnerabilities
- T1588.005 Exploits
- T1190 Exploit Public-Facing Application
- T1059.004 Unix Shell
- T1213 Data from Information Repositories
- T1565.001 Stored Data Manipulation
- T1485 Data Destruction

## Sources

- [Hackers Exploiting Unpatched GeoServer Zero-Day](https://www.securityweek.com/hackers-exploiting-unpatched-geoserver-zero-day/)
- [Unpatched GeoServer Zero-Day Targeted in Active Exploitation Attempts, Can Lead to RCE](https://thehackernews.com/2026/08/unpatched-geoserver-zero-day-targeted.html)
- [GeoServer Zero-Day Is Already Being Probed. That's the Problem](https://securityaffairs.com/197216/hacking/geoserver-zero-day-is-already-being-probed-thats-the-problem.html)
- [Early exploitation attempts observed of GeoServer zero day](https://fieldeffect.com/blog/early-exploitation-attempts-observed-geoserver-zero-day)
- [Attackers target zero-day vulnerability in geospatial data platform GeoServer](https://www.csoonline.com/article/4209388/attackers-target-zero-day-vulnerability-in-geospatial-data-platform-geoserver.html)
- [Unauthenticated SQL injection in the jsonArrayContains filter function against PostGIS layers (GHSA-mqjf-5f49-2fjh)](https://github.com/geotools/geotools/security/advisories/GHSA-mqjf-5f49-2fjh)
- [GeoServer 3.0.1 / GeoServer 2.28.5 / GeoServer 2.27.6 Released](https://discourse.osgeo.org/t/geoserver-3-0-1-geoserver-2-28-5-geoserver-2-27-6-released/154874)
- [GeoServer-jsonArrayContains-PG-RCE (PoC)](https://github.com/mhtsec/GeoServer-jsonArrayContains-PG-RCE)
- [GeoServer jsonArrayContains SQLi -> PostgreSQL RCE python PoC](https://gist.github.com/portbuster1337/70d75ec246b85e3199037ce212ff1a06)
- [OGC Filter SQL Injection Vulnerabilities (CVE-2023-25158 / GHSA-99c3-qc2q-p94m)](https://github.com/advisories/GHSA-99c3-qc2q-p94m)
- [CVE-2024-36401 Detail (NVD)](https://nvd.nist.gov/vuln/detail/CVE-2024-36401)

## Full data

Detection queries (Splunk SPL / Microsoft KQL / Sigma) and IOC values require the Threadlinqs MCP server (Purple tier): https://intel.threadlinqs.com/mcp

Canonical: https://intel.threadlinqs.com/threat/TL-2026-2035