Published on gastropod.io on 08-16-2026

GeoServer's SQL Injection Zero-Day Was Being Scanned For Within Hours

Tags: vulnerability-intelligence, software-supply-chain-security, maven, java, sql-injection, remote-code-execution

A researcher going by q1uf3ng published a GeoServer SQL injection flaw on August 12, with no coordinated disclosure to the project first.
According to watchTowr, scanning traffic looking for exposed GeoServer instances started within hours of the disclosure, hundreds of probes from a small pool of source IPs. GeoServer rallied to provide fixed releases, 3.0.1, 2.28.5, and 2.27.6, two days later on August 14.

The problem itself is not in GeoServer's own codebase. It's located in org.geotools:gt-jdbc-postgis. This is a Maven library GeoServer bundles to talk to PostGIS-backed data stores. The jsonArrayContains function allows a write into its <value> parameter straight as a generated SQL query & on any PostGIS 12+ deployment using String or JSON fields this means an unauthenticated request can inject arbitrary SQL, and on database configurations with elevated privileges, that injection extends to remote code execution. The GitHub advisory, GHSA-mqjf-5f49-2fjh, rates it 9.8 out of 10 and notes something worse than a fresh vulnerability: it's a regression. The mitigation that closed a near-identical flaw in 2023, CVE-2023-25158, enabling prepared statements and disabling function encoding, doesn't stop this function from taking the same unescaped path.

GeoServer has been through this before. Field Effect points back to CVE-2024-36401, a GeoServer flaw that reached a U.S. federal agency within two weeks of disclosure and went on to power botnet recruitment, cryptocurrency mining, and China-linked espionage operations. This looks similar in that The Hacker News reported that the scanning observed in the first hours was reconnaissance, not confirmed compromise, but reconnaissance against an unauthenticated, publicly disclosed SQL injection with no patch available tends to turn into exploitation quickly.

Two things make this one worth tracking past the patch announcement. The affected code isn't confined to people running GeoServer as an application; anything that pulls gt-jdbc-postgis in directly as a Maven dependency for its own PostGIS integration inherits the same flaw, whether or not GeoServer is anywhere in the picture. And the regression itself is the real warning: a fix that worked against one code path in 2023 quietly failed to cover a second one, which is the kind of gap that shows up only when someone maps every function touching that same unescaped value, not just the one that made headlines the first time.

That's the mapping problem an SBOM is supposed to solve, provided it goes deep enough to catch a transitive Maven dependency and not just the top-level application.

Shameless plug for gastropod.io ;)

Gastropod correlates OSV advisories, including new GHSA entries like this one, directly against tracked artifact versions and their dependents, so a flag on gt-jdbc-postgis 33.1 through 35.0 surfaces every project pulling it in, GeoServer or otherwise, rather than relying on someone remembering which internal tools happen to touch PostGIS. More on how that correlation works, including regression cases like this one, is on the product page.

Sources:

• Unpatched GeoServer Zero-Day Targeted in Active Exploitation Attempts, Can Lead to RCE (The Hacker News)
• GeoServer Zero-Day Is Already Being Probed. That's the Problem (Security Affairs)
• Early exploitation attempts observed of GeoServer zero day (Field Effect)
• GHSA-mqjf-5f49-2fjh: Unauthenticated SQL injection in jsonArrayContains (GeoTools GitHub Advisory)