GeoServer has shipped emergency releases for a critical SQL injection flaw that its own maintainers describe as a regression of a vulnerability fixed in 2023. The flaw was disclosed publicly on X on 12 August with no vendor coordination, drew scanning within hours, and was patched on 14 August. It still has no CVE identifier, and the workaround published for the original 2023 vulnerability does not stop it.
What happened
The vulnerability sits in jsonArrayContains, a filter function used when querying JSON array fields. According to the GeoTools advisory GHSA-mqjf-5f49-2fjh, published on 15 August, the function writes a caller-supplied value into the generated SQL without escaping it when running against PostGIS 12 or later. The advisory rates the issue 9.8 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, meaning it can be reached over the network with no authentication and no user interaction, and classifies it as CWE-89.
Worth noting for anyone reconciling severity across sources: the GeoTools advisory labels it Critical at 9.8, while the GeoServer project’s own release announcement lists it as High. Both come from the same maintainers. The technical description is identical in each.
Exposure is narrower than the score alone suggests, because four conditions have to line up. The instance must publish a layer from a PostGIS DataStore, PostGIS must be version 12 or greater, the published layer must contain a String or JSON field, and the underlying org.geotools:gt-jdbc-postgis package must be at 33.1 or later, 34.x, or 35.0. Where those conditions hold, the impact stated by the maintainers is execution of arbitrary SQL expressions in the database. Whether that escalates further depends on the privileges the database connection runs with, which is the difference between data exposure and code execution on the host.
The 2023 fix that came back
The detail that makes this worth more than a version bump is stated plainly in the advisory: this is a regression of CVE-2023-25158, one of a set of OGC filter injection flaws addressed in February 2023, reintroduced for this single function.
That matters operationally because of what the maintainers say next. The mitigation published in 2023, enabling preparedStatements and disabling encode functions on the PostGIS DataStore, is explicitly not effective here. Any team that applied that configuration change in 2023 instead of upgrading, and has treated it as settled since, is exposed and has no reason from its own records to think so. There is no workaround for this one. Upgrading is the remedy.
Disclosed on social media, patched three days later
The GeoServer Project Steering Committee is unusually direct about the sequence in its release announcement, stating that its coordinated vulnerability disclosure policy was not followed and that an official CVE number will be provided when one is available. The flaw was posted to X by an independent researcher on 12 August at 10:46 UTC. Attack surface management firm watchTowr reported observing probing attempts within hours, running into the hundreds and originating from a small pool of addresses, with the activity consistent with hunting for vulnerable systems rather than delivering anything. A public reproduction tool for the flaw also appeared quickly, which we have not linked, named or described, and which is the reason the window mattered.
GeoServer has a history here worth weighing when deciding how fast to move. Field Effect’s analysis notes that a 2024 GeoServer vulnerability, CVE-2024-36401, was exploited to compromise a large US federal agency, and that internet-facing deployments in government, defence, engineering and research carry the highest exposure.
Why it matters
For most readers this is not a device you own, and there is nothing to do about it personally. It is a server that organisations run to publish maps and location data, and if your employer runs one the relevant people should already be looking. The wider lesson travels further than the software does. A fix that shipped three years ago quietly stopped working, and the standard advice for anyone still exposed, apply the workaround, had become the wrong advice without anybody being told.
For anyone responsible for a software inventory, the practical failure mode here is not the injection. It is that this flaw arrived with no CVE identifier, which means a process built on watching CVE feeds and scanner output would not have raised it, and still may not until an identifier is assigned retroactively. That is the second time in a month a maximum-severity, actively probed flaw has moved faster than the identifier system meant to track it. We covered how those identifiers and their scoring layers actually work in reading a CVE, and the gap between disclosure and identifier is the part that keeps proving expensive.
The immediate action is narrow and clear. Confirm whether any GeoServer instance you run publishes PostGIS-backed layers, upgrade to 3.0.1, 2.28.5 or 2.27.6 depending on branch, and do not rely on the 2023 configuration change. If upgrading has to wait, restricting who can reach the service at all is the only lever left.
Last verified 17 August 2026 against the GeoTools advisory GHSA-mqjf-5f49-2fjh and the GeoServer project release announcement. No CVE identifier had been assigned at the time of writing; one may be issued retroactively.