By An unpatched zero-day SQL injection vulnerability in GeoServer is being actively probed right now. The flaw was disclosed on August 12 by security researcher @q1uf3ng — two days ago — and it has no CVE number and no patch. Within hours of the public disclosure, threat intelligence firm watchTowr recorded hundreds of exploitation attempts against exposed instances worldwide. If GeoServer is somewhere in your infrastructure, this is not a background item for next week’s sprint planning.
What GeoServer Is, and Who Runs It
GeoServer is an open-source Java-based geospatial server that implements OGC standards: Web Feature Service (WFS), Web Map Service (WMS), and Web Coverage Service (WCS). It sits behind public-facing map portals, environmental data platforms, government open-data initiatives, and spatial analytics pipelines — in sectors including government, defense, education, engineering, and technology. That is exactly the kind of infrastructure attackers love: mission-critical, network-accessible, and often treated as a utility that does not need regular attention.
According to Shodan, more than 14,000 GeoServer instances are exposed to the public internet. The Shadowserver Foundation tracks roughly 2,500 of those as vulnerable in recent scans. That is a large attack surface for an unpatched zero-day.
The Vulnerability: SQL Injection via jsonArrayContains
The flaw lives in GeoServer’s jsonArrayContains function, which processes JSON array queries for PostGIS and Oracle JDBC datastores. User-supplied arguments pass through the function without proper sanitization before being encoded into database queries — a classic SQL injection setup. No authentication is required to trigger it.
The risk escalates significantly when GeoServer’s backend database runs Microsoft SQL Server with system administrator privileges. In that configuration, an attacker who achieves SQL injection can pivot to remote code execution. The researcher who disclosed this described it plainly: “in the case of the SA database, it’s naturally possible to achieve RCE.”
This attack class is not new for GeoServer. CVE-2023-25157 was a SQL injection through OGC filter expressions — the same family of input handling, the same vulnerable database layer. The difference now is that there is no patch yet and exploitation attempts have already started.
What Active Exploitation Looks Like Right Now
Jake Knott, Principal Security Researcher at watchTowr, described the current situation: “Currently, we’re seeing attackers probe to identify vulnerable systems across the internet, triggering errors and not proceeding further.” That is the reconnaissance phase — attackers are mapping exposed instances before deploying payloads. It is the calm before the storm, and with GeoServer, the storm is historically short.
CVE-2024-36401 — a CVSS 9.8 RCE flaw from 2024 — offers the clearest preview of what comes next. After disclosure, attackers exploited over 7,100 GeoServer instances to deploy XMRig cryptocurrency miners, the Condi and JenX DDoS botnets, the SideWalk backdoor, and a reverse proxy that connects compromised servers to attacker command-and-control infrastructure. Fortinet’s analysis of that campaign documented targets across US tech companies, government agencies in Belgium, and telcos in Brazil and Thailand. CISA added the CVE to its Known Exploited Vulnerabilities catalog. Multiple other GeoServer CVEs have followed the same path.
As watchTowr noted, “GeoServer has a track record of being targeted and exploited at scale, with multiple vulnerabilities listed in CISA’s Known Exploited Vulnerabilities catalog.” The recon happening right now is the opening move of that same playbook.
What to Do Before a Patch Exists
There is no patch coming from your side — the fix has to come from OSGeo. Until it does, these are your options:
- Audit your exposure. Find every GeoServer instance in your infrastructure, including dev and staging environments that may be inadvertently accessible externally.
- Restrict network access. Pull public-facing GeoServer endpoints behind a VPN or firewall. If your use case does not require public access, removing it eliminates the attack surface entirely.
- Disable jsonArrayContains if operationally possible. If your pipeline does not require JSON array queries against PostGIS or Oracle JDBC, disabling this function removes the specific injection vector. Also consider disabling PostGIS DataStore encode functions and enabling prepared statements — mitigations that applied to prior GeoServer SQL injection vulnerabilities and offer partial protection here.
- Monitor your logs. Look for unusual query patterns, error spikes in GeoServer logs, and unexpected outbound connections from the GeoServer host.
- Watch OSGeo’s security advisories. The official patch will appear at geoserver.org. Subscribe or check it actively — do not wait for it to appear in a weekly digest.
The Pattern Is Predictable
This is the third SQL injection-class vulnerability in GeoServer in three years. The attack surface — OGC filter functions and JSON query expressions hitting the database layer — has been exploited before, patched, and now breached again through a related but different function. Treating GeoServer as set-and-forget infrastructure is a security liability. The attackers who scanned thousands of instances within hours of the CVE-2024-36401 disclosure are still active, and the reconnaissance probes on this new GeoServer zero-day confirm they are watching every new disclosure closely.
The patch will come. Until then, reducing your exposure is the only mitigation available. Do that now — not after the CVE number gets assigned.
