GeoServer's jsonArrayContains function scored a 9.8, needed zero credentials, and WatchTowr watched the exploitation start within hours of the tweet that disclosed it.
A GeoServer bug went public on X at 10:46 UTC on August 12, and by that afternoon, WatchTowr was already watching real attackers hammer it. The flaw lives in a function called jsonArrayContains, scores a 9.8 out of 10, needs no login at all, and — depending on how the underlying database account is configured — can hand an attacker code execution on the box. If you run GeoServer against PostGIS, this is the one you patch today, not this week.
How a mapping function turns into a hacked server
jsonArrayContains(<column>, <pointer>, <value>) is an OGC filter expression — the kind of thing GeoServer uses constantly to let clients query which map features match a condition. The bug is almost boringly simple once you see it: the <value> argument gets written straight into the generated SQL query without escaping. Anyone who can reach a WFS or WMS endpoint backed by a PostGIS layer with a string or JSON column can smuggle SQL through that parameter. No API key, no admin panel, no valid session — just a crafted request.
How fast this moved
Aug 12, 2026 · 10:46 UTC
Researcher @q1uf3ng publicly discloses the SQL injection on X.
Aug 12, 2026 · afternoon
WatchTowr records the first exploitation probes against exposed instances.
Aug 13, 2026
Hundreds of scanning and injection attempts logged from a small pool of source IPs, per WatchTowr's telemetry.
Aug 14–15, 2026
GeoServer and geotools maintainers ship 3.0.1 / 2.28.5 / 2.27.6 and the patched gt-jdbc-postgis builds.
Who's actually exposed
GeoServer's own advisory narrows the blast radius a bit: you need PostGIS 12 or later, and the layer needs a string or JSON field the filter can target. That's still a huge share of real-world GeoServer deployments — utilities, municipal GIS portals, logistics and agriculture platforms all lean on exactly this stack.
Affected vs. fixed
GeoServer
Component
≤3.0.0, ≤2.28.4, ≤2.27.5
Vulnerable
3.0.1, 2.28.5, 2.27.6
geotools gt-jdbc-postgis
Component
35.0, ≥34.0 <34.5, ≥33.1 <33.6
Vulnerable
35.1, 34.5, 33.6
Prerequisite
Component
PostGIS 12+ with a String or JSON field
Vulnerable
n/a
Component
Vulnerable
Fixed
GeoServer
≤3.0.0, ≤2.28.4, ≤2.27.5
3.0.1, 2.28.5, 2.27.6
geotools gt-jdbc-postgis
35.0, ≥34.0 <34.5, ≥33.1 <33.6
35.1, 34.5, 33.6
Prerequisite
PostGIS 12+ with a String or JSON field
n/a
GeoServer instances left reachable on the public internet are the ones WatchTowr watched getting probed within hours of disclosure. · Unsplash
My take: this is the GeoServer problem repeating itself
This is the same class of bug GeoServer patched in February 2023 as CVE-2023-25158 — pre-auth SQL injection through OGC filter parsing — showing up again in a different function three years later. I don't think that's bad luck; I think it's what happens when a codebase keeps adding filter functions faster than it re-audits the escaping logic underneath all of them. SecurityWeek reported the same probing pattern we've seen all year on other internet-facing infrastructure — see how the wormable Windows DNS Server flaw and the SharePoint exploit chain both went from disclosure to active scanning within a day. If your team runs unglamorous infrastructure like a GIS server, this is the year to stop assuming it's below attackers' radar. It isn't. Automated scanners don't care what your software does, only that it's reachable.
What to do right now
Patch to GeoServer 3.0.1 / 2.28.5 / 2.27.6 immediately if the instance is internet-facing.
If you can't patch today, pull GeoServer off the public internet or add a WAF rule blocking jsonArrayContains in filter parameters.
Audit the database account GeoServer connects with — strip superuser rights from it if it has them.
Check GeoServer logs for WFS/WMS requests containing jsonArrayContains since August 12, and treat any hits as a probable compromise, not a false alarm.
Is there a CVE number for this bug?
Not a CVE ID at the time of writing — it's tracked under GitHub Security Advisories GHSA-mqjf-5f49-2fjh (the geotools library) and GHSA-7g5f-wrx8-5ccf (GeoServer's OGC filter handling). A formal CVE typically follows within days.
Do I need PostGIS for this to affect me?
Yes — the vulnerable code path only fires against PostGIS-backed layers running PostGIS 12 or newer with a string or JSON column. Oracle- or file-backed GeoServer datastores aren't hit by this specific function.
Has this actually been used to breach anyone yet?
WatchTowr's telemetry shows scanning and injection probes, not confirmed breaches, as of this writing. Given how fast the probing started after disclosure, treat 'not yet confirmed' as a short runway, not reassurance.
Is this related to the 2023 GeoServer CVE?
Yes — GeoServer's maintainers describe it as a regression of CVE-2023-25158, a near-identical pre-auth SQL injection patched in February 2023.
What if I can't take my GeoServer instance offline to patch?
Restrict access to trusted networks or a VPN as an immediate stopgap, and put a WAF rule in front of it blocking the jsonArrayContains string in requests — but treat that as hours of breathing room, not a substitute for the update.
GeoServer runs quietly under a lot of government, utility, and logistics mapping tools that most security teams never think about until a bug like this puts it on a dashboard. If you don't already know whether your organization runs it somewhere, that's this week's action item — not next quarter's.
