A SQL injection bug in a mapping library used underneath GeoServer went from public disclosure to active probing in a matter of hours, and more than a day later there is still no vendor patch available for the affected component.
What happened. On August 12, a researcher publicly disclosed an unauthenticated SQL injection flaw in the jsonArrayContains filter function used by GeoTools, the geospatial library that underpins the open-source GeoServer platform, when queried against PostGIS-backed datastores. The function fails to escape user-supplied values in generated SQL, and where the database account holds elevated permissions, the injection can escalate to remote code execution. GeoTools’ maintainers published a fix, GitHub Security Advisory GHSA-mqjf-5f49-2fjh, on August 15, rating the flaw 9.8 on the CVSS scale and shipping patched releases 35.1, 34.5, and 33.6. No CVE identifier has been assigned yet. Security firm WatchTowr reported observing hundreds of exploitation attempts against internet-facing GeoServer instances within hours of the initial disclosure, well before any fix existed. It is the second unauthenticated flaw in an internet-facing enterprise platform to draw active scanning this week, alongside a session-handling bug in Adobe Commerce that let attackers hijack accounts without credentials.
Why it matters. GeoServer sits inside government mapping portals, utilities, and infrastructure operators that publish geospatial data publicly, and the platform has a history of being pulled into botnet and cryptomining campaigns once an exploit circulates. A gap between disclosure and vendor fix, with active scanning already running, is exactly when mass exploitation happens.
The insight. This is the same shape of exposure this desk flagged in an unauthenticated TeamCity flaw: a widely self-hosted, internet-facing platform where the patch lags the disclosure and the scanning does not. Security teams running GeoServer against PostGIS should not wait for a CVE number to act. The interim options are the same ones vendors always fall back to when a fix is not yet shipped: pull the instance off the public internet behind a VPN or IP allow-list, and watch logs for unusual jsonArrayContains queries and database errors in the meantime.
