GeoServer jsonArrayContains SQL Injection Zero-Day: Mass Probes Hours After Disclosure, RCE Possible Depending on Configuration

1. Basic Information

• Severity: Critical
• Article Title: Hackers Exploiting Unpatched GeoServer Zero-Day
• Publisher: SecurityWeek
• Publication Date: 2026-08-14
• Update Date: None
• Original Article: Original Article
• Related Sources: None
• Malware: None
• Groups: None
• CVEs: Unassigned (at time of publication)
• Products: GeoServer, jsonArrayContains filter, PostGIS JDBC data store, Oracle JDBC data store, H2 (configuration where RCE was reported)

2. Executive Summary

A SQL injection vulnerability in the GeoServer jsonArrayContains filter was publicly disclosed, where user arguments are improperly included in DB queries. Without patches, hundreds of exploit attempts were observed within hours of the disclosure.

3. Attack Flow

SQL Injection / Probing

1. An attacker sends a filter query to a public GeoServer endpoint on the Internet.
2. A crafted user argument is passed to jsonArrayContains.
3. The input is improperly included in the DB query for PostGIS/Oracle JDBC data stores.
4. The attacker aims to execute queries, access data, or change DB behavior via SQL injection.
5. WatchTowr observed hundreds of attempts from a small number of source IPs within hours of public disclosure.

Configuration-Dependent RCE

1. The vulnerable filter and RCE-capable DB/configuration conditions are met.
2. The attack transitions from SQL injection to code execution.
3. Process, file, or network activity occurs under GeoServer, application, or DB privileges.
4. No follow-up activity after the probes has been confirmed in public reports.

4. Attacker Position and Execution Point

• The attacker sends HTTP requests from the Internet to a public GeoServer.
• The injection occurs from GeoServer filter parsing to the backend JDBC/DB query.
• RCE depends on specific configurations, and it is not confirmed that all PostGIS/Oracle deployments lead to RCE in the same way.

5. Visibility for Victims and Administrators

• User action is not required. Maps and services may respond normally while receiving attack requests.
• Administrators can see abnormal filters containing jsonArrayContains, SQL errors or timing, DB queries, and GeoServer/Java child processes.
• Mass probes do not mean successful compromise. Success is judged based on evidence of successful DB queries or OS execution.

6. Success and Failure Conditions

Success Conditions

• Vulnerable GeoServer is reachable by the attacker.
• jsonArrayContains and the target JSON field/data store are available.
• Crafted arguments are not blocked by WAF/validation.
• Additional configuration/DB conditions are met for RCE.

Failure Conditions

• Isolate GeoServer from the Internet and restrict it to trusted networks/VPNs.
• Block abnormal inputs for the filter using a WAF/API gateway.
• Temporarily disable vulnerable function/data store combinations.
• Limit the impact of SQLi using DB least privilege and application process isolation.
• Apply vendor patches quickly after release.

7. What Happens on Success

• SQL query manipulation, potential reading/modifying of DB data.
• Remote code execution in specific configurations.
• Hundreds of attempts/probing observed at publication, but follow-up compromise unconfirmed.
• Potential impact on geospatial data/services for government, agriculture, telecommunications, and transportation.

8. Observable Logs

Email

• None related

Proxy / SWG / DNS

• jsonArrayContains filter sent to GeoServer endpoint
• Encoded quotes, comments, or function payloads
• Unknown egress from GeoServer

Endpoint / EDR

• GeoServer/Java child process
• Shell/interpreter
• Unexpected file creation
• Tool execution by service account

Identity / IdP

• Initial attacks may not require authentication. Correlation with admin logins requires follow-on investigation.

SaaS / Cloud

• WAF/load balancer/API gateway access logs
• GeoServer application logs
• Managed DB audit/query logs
• Cloud flow logs

Network

• Many requests from a small number of source IPs
• GeoServer to DB traffic
• Callbacks/scans after RCE

9. Determining Attack Success

Contact Only

• GeoServer scan or normal filter request

User Action

• Not required

Initial Execution

• Crafted jsonArrayContains request reaches the application

Malware or Authentication Success

• SQLi established via DB error/timing/query, or RCE established via Java child/file/callback

Data Theft / Session Compromise

• Confirm DB results/data egress or credential/session access using separate evidence

Subsequent Compromise Confirmation

• Confirm web shells, persistence, internal scans, or data modification

10. Investigation Playbook

Trigger

• Abnormal jsonArrayContains request
• GeoServer zero-day exposure
• SQL error spike
• GeoServer/Java child process

Initial Check

• Determine version/configuration, data store, public exposure, and first request/source.
• Synchronize request/response with DB/application logs.

Endpoint

• Preserve GeoServer logs, JVM process tree, temp/web directories, file integrity, and sockets.

Authentication & Cloud

• Check GeoServer/DB service account privileges, secret access, cloud DB audits, and control-plane changes.

Subsequent Operations

• Search for DB query/data access, callbacks, web shells, new users, scheduled tasks, and lateral movement.

Containment

• Restrict public access, apply WAF rules, stop vulnerable functions, and rotate DB credentials.
• Isolate and rebuild hosts if RCE evidence exists.

Judgment Categories

• Scanned
• Exploit Attempted
• SQL Injection Confirmed
• RCE Confirmed
• Data Compromised
• Follow-on Compromise Confirmed

11. Defense and Detection Ideas

Single Event

• jsonArrayContains with SQL metacharacters
• GeoServer SQL errors
• GeoServer/Java spawning a shell
• Unexpected outbound traffic

Time-Series Correlation

• Crafted filter -> SQL error/query -> Java child/file -> callback -> DB/internal access

Hunting Perspective

• Public GeoServer inventory
• PostGIS/Oracle/H2 configuration
• Source concentration after disclosure
• New processes/files created by service users

Log Gaps

• HTTP queries/bodies
• GeoServer filter logs
• DB audits
• JVM command lines
• Egress traffic

Priority Actions

• Reduce external exposure
• WAF virtual patching
• DB least privilege
• Application isolation
• Vendor patch monitoring

12. Facts / Inference / Hypothesis

Facts

• The disclosed zero-day is a SQL injection in the GeoServer jsonArrayContains filter.
• Functions used in PostGIS and Oracle JDBC data stores are reported as targets.
• The cause is believed to be insufficient sanitization of user-supplied arguments.
• Certain configurations can lead to RCE.
• WatchTowr observed hundreds of exploitation attempts from a small number of source IPs within hours of disclosure.
• There was no patch at the time of publication, and no follow-up activity after probes has been observed.

Inference

• Without DB/application logs, it is impossible to distinguish between HTTP attempts and successful SQLi/RCE.
• Public GeoServers should prioritize network restrictions and virtual patches while waiting for patches.

Hypothesis

• Similar to past GeoServer mass exploitations, it may lead to botnets, miners, or web shells, but follow-on activity has not been confirmed yet.

13. MITRE ATT&CK Mapping

• T1190 Exploit Public-Facing Application — Confidence: High
• T1059 Command and Scripting Interpreter — Confidence: Medium (when RCE is achieved)
• T1505.003 Web Shell — Confidence: Low (investigation perspective, installation unconfirmed)
• T1005 Data from Local System — Confidence: Low (if DB data extraction is confirmed)

14. Unknowns and Additional Investigation

• CVE, affected versions, official vendor advisory, patch ETA
• Exact payload and RCE conditions
• Total source IPs/IOCs
• Real victims where SQLi/RCE succeeded
• Follow-on payloads, threat actors, and data impact

15. Impact on SOCs and Organizations

GeoServer may be used across various sectors for geospatial data, mapping services, and location-based applications. Organizations should not wait for a CVE to take action. They must immediately inventory public instances, and until patches are available, use access restrictions, WAF rules, and DB audits to verify attack success.

16. Summary by Target Audience

• For SOCs: Separate probes, SQLi success, RCE, and follow-on activities. Correlate HTTP, GeoServer, DB, and process logs.
• For Administrators: Immediately reduce public exposure, implement virtual patches for jsonArrayContains, enforce DB least privilege, and monitor for vendor fixes.
• For Users: No user action is required. Report any anomalies or outages in mapping services to administrators.