What is the GeoServer jsonArrayContains vulnerability?
An unauthenticated SQL injection vulnerability exists in the jsonArrayContains filter function in GeoTools, the geospatial library that underpins GeoServer. When an OGC filter is evaluated against a PostGIS data store, the value passed to jsonArrayContains is written into the generated SQL statement without escaping, allowing an attacker to alter the query the database executes.
No CVE identifier has been assigned at the time of writing. The flaw is tracked as GitHub security advisory GHSA-mqjf-5f49-2fjh. The advisory itself classifies the issue as high severity, while public reporting cites a CVSS v3.1 base score of 9.8 (Critical). The vulnerability was disclosed publicly on August 12, 2026, by an independent researcher, and internet-wide scans show probing activity beginning within hours of that disclosure.
Exploitation requires no authentication. GeoServer accepts CQL filter expressions through its OGC WMS and WFS interfaces, and those interfaces are frequently published without authentication so that public mapping applications can consume them. An attacker who can reach the endpoint can reach the injection point. The flaw sits in the GeoTools code that translates CQL filters into SQL, where a value taken straight from the HTTP request is interpolated into a PostgreSQL jsonb_path_exists() expression with no escaping.
The route from injection to code execution runs through WFS 1.0, which allows a second PostgreSQL statement to execute at the top level of the query. From there the impact depends on the database role GeoServer connects with. Where that role is a PostgreSQL superuser, or holds pg_execute_server_program, the injection escalates to operating system command execution on the database host. Where it does not, the attacker still reads and writes everything that database user can touch.
Observed activity so far is reconnaissance rather than compromise. Internet-wide scans show hundreds of probe attempts from a small pool of addresses, triggering database errors to fingerprint vulnerable instances without advancing further. That is a normal first phase and should not be read as a ceiling.
Two conditions narrow the affected population. The backing data store must be PostGIS 12 or greater, and the queried layer must expose a string or JSON field. Neither condition is visible from outside the application, which means external observation can identify software presence but not confirm exploitability.
What assets are affected by the GeoServer zero day?
The vulnerable code sits in the gt-jdbc-postgis GeoTools module. Affected releases include GeoTools 35.0, the 34.0 branch, and the 33.1 branch onward. GeoServer distributions built on those GeoTools versions inherit the flaw, and reporting places affected GeoServer builds from 2.25.3 forward when the PostGIS preconditions are present. Older unsupported branches should be treated as affected rather than assumed safe.
In practice, an affected asset is a public map service. GeoServer is the most widely deployed open-source server for publishing geospatial data, and it sits behind national mapping portals, municipal GIS viewers, utility outage maps, environmental monitoring platforms, and transport and logistics planning systems. These deployments are internet-facing by design, because the entire purpose of a WMS or WFS endpoint is to serve map layers to browsers and third-party clients that the operator does not control.
GeoServer also has a documented history of being exploited at scale. Multiple GeoServer vulnerabilities appear in CISA’s Known Exploited Vulnerabilities catalog, and CVE-2024-36401, a critical GeoTools flaw carrying a CVSS score of 9.8, was used in 2024 to pull compromised hosts into DDoS botnets, cryptocurrency mining operations, and residential proxy networks. Attackers already know where these servers are and what they are worth.
That design is also why these assets are routinely overlooked. A GIS viewer is usually commissioned by a business or operations team rather than by IT, runs on infrastructure that sits outside the core application inventory, and stays online long after the project that created it has ended. Many of the instances in our own data are subdomains attached to regional or departmental services rather than to a primary corporate domain, which is exactly the pattern that keeps an asset out of scope during a vulnerability scan.
What does our data show about exposure patterns?
Exposure in this set is led by Industrials at 59.3% of observed assets, with Consumer Discretionary contributing 18.5%. Information Technology accounts for a further 11.1%. The set reflects assets observed running GeoServer and reachable from the public internet. Because the vulnerable configuration depends on the backing database, these should be read as potentially affected rather than confirmed vulnerable.
The concentration in Industrials tracks how geospatial software is actually used. Engineering firms, transport operators, utilities, and public infrastructure bodies are the organizations that need to publish map data as an operational function rather than as a marketing asset. Their estates are also geographically distributed and heavily partnered, with regional offices, contractors, and integrators standing up their own map services under the parent organization’s namespace. Ownership of any individual GeoServer instance is often unclear, which slows both patching and decommissioning.
Across all sectors, the pattern points less at a software problem than at a visibility problem. GeoServer instances are frequently deployed as project infrastructure, tied to a specific dataset or a specific programme, and then left running because taking them down requires knowing who depends on them. The result is a long tail of internet-facing services that nobody is actively responsible for, and a vulnerability in a filter function becomes an exposure event only because those services were never counted in the first place.
Are fixes available?
Patches are available. GeoServer published security releases on August 14, 2026, covering versions 3.0.1, 2.28.5, and 2.27.6. The corresponding corrected GeoTools versions are 35.1, 34.5, and 33.6. Installations running unsupported branches will need to move to a supported release rather than waiting for a backport.
One point deserves emphasis, because it is a likely source of false confidence. The maintainers describe this issue as a regression of CVE-2023-25158, and the mitigation published for that earlier vulnerability does not work here. Enabling prepared statements and disabling function encoding does not close this injection path. Teams that applied the 2023 guidance and consider the matter settled are not protected.
Note also that much of the early coverage of this flaw described it as unpatched, since disclosure preceded the fix by two days. That reporting is now out of date. Defenders should verify their specific GeoServer and GeoTools versions directly against the vendor advisory rather than relying on secondary summaries.
Are there any other recommended actions to take?
Alongside patching, defenders should:
- Inventory internet-facing GeoServer instances and the OGC endpoints they publish
- Restrict WFS and WMS access to authenticated users or allowlisted networks
- Disable WFS 1.0 on services where no client still requires that version
- Audit PostgreSQL roles used by GeoServer for superuser or
pg_execute_server_programprivileges - Identify layers backed by PostGIS 12 or greater that expose string or JSON fields
- Review GeoServer and database logs for unexpected CQL filter parameters
How can CyCognito help your organization?
CyCognito published an Emerging Threat Advisory for the GeoServer jsonArrayContains SQL injection vulnerability in the CyCognito platform and is actively researching enhanced detection capabilities for this vulnerability.
To learn how CyCognito can help your organization reduce external exposure and manage emerging threats more effectively, contact us to request a demo.
