GeoServer's jsonArrayContains filter is being probed at scale, with no patch and no CVE

A SQL injection flaw in GeoServer's `jsonArrayContains` filter was disclosed publicly while unpatched and with no CVE assigned, and hundreds of exploit attempts were observed within hours, according to a SecurityWeek report dated 2026-08-14 as summarised on dev.to ^{[1][2][3][17]}. The ordering is the whole problem: there is no version to upgrade to, so whatever protection exists this week has to be imposed at the edge or in the request path.

The mechanics are ordinary, which is why the probes scaled so quickly. An attacker sends a filter query to a public GeoServer endpoint, a crafted user argument reaches `jsonArrayContains`, and that input is improperly included in the database query for PostGIS and Oracle JDBC data stores ^[1][8]. The report rates the issue critical, lists H2 as the configuration in which remote code execution was reported, and is explicit that RCE depends on configuration and that it is not confirmed all PostGIS or Oracle deployments lead to code execution in the same way ^[5][6][7]. Initial attacks may not require authentication, no user action is involved, and the report notes that maps and services can respond normally while receiving attack traffic ^[10][11].

WatchTowr reported hundreds of attempts from a small number of source IPs within hours of disclosure ^[4]. Worth keeping in proportion: mass probing is not compromise, no follow-up activity has been confirmed in public reports, and the report's own bar for success is evidence of completed database queries or OS execution, not the presence of a request ^[9][19]. The exploitation preconditions listed are equally practical: the vulnerable server must be reachable, `jsonArrayContains` and the target JSON field and data store must be available, the crafted arguments must not be blocked by a WAF or input validation, and further database and configuration conditions must hold for RCE ^[15].

That last item is where operators still have leverage over outcomes. The recommended mitigations are to isolate GeoServer from the internet and restrict it to trusted networks or a VPN, block abnormal filter inputs with a WAF or API gateway, temporarily disable the vulnerable function and data store combinations, constrain blast radius with database least privilege and application process isolation, and apply vendor patches once released ^[12]. Because there is no CVE identifier and no fixed version, CVE-keyed scanners and patch-state dashboards will not surface this exposure; finding affected instances is an inventory exercise, not a scan result ^[20].

For detection, the useful telemetry is WAF, load balancer and API gateway access logs, GeoServer application logs, managed database audit and query logs, and cloud flow logs ^[13]. Indicators include filter requests containing `jsonArrayContains` with encoded quotes, comments or function payloads, spikes in SQL errors or query timing anomalies, unknown egress from GeoServer, Java child processes, shells or interpreters, unexpected file creation, and tool execution by the service account ^[14]. If something looks live, the report's triage sequence is to establish version, configuration, data store, public exposure and the first request and source, correlate request and response with database and application logs, and preserve GeoServer logs, the JVM process tree, temp and web directories, file integrity data and sockets ^[18].

Watch for three things: a CVE assignment and vendor patch, any public confirmation of post-exploitation activity rather than probing alone, and whether the source IP set broadens from the small cluster WatchTowr described ^[2][4][9]. The report flags potential impact on geospatial data and services in government, agriculture, telecommunications and transportation, which is a reasonable guide to who should be checking exposure first ^[16].