Attacks on GeoServer began within hours of the flaw becoming public

A vulnerability in GeoServer was made public by the researcher q1uf3ng on X on Wednesday 12 August 2026, before the project itself had a fix ready. The security firm watchTowr states that exploitation attempts began within hours, and that it has since recorded hundreds of attempts from a small number of source addresses. GeoServer describes the flaw as an SQL injection rated high severity, and states that it requires a text or JSON column and affects PostGIS from version 12 upwards. The fix arrived in GeoServer 3.0.1 on 14 August. No CVE number has been assigned so far.

What happens technically

GeoServer is an open source server for publishing and sharing geospatial data over the web, used among other places in public administration, agriculture, telecommunications and transport. The flaw sits in the jsonArrayContains filter function, which checks whether a JSON field contains a particular value. The function can be used against PostGIS and Oracle JDBC data stores. According to the account in SecurityWeek, the injection most likely arises because arguments supplied by the user are not adequately sanitised before being placed into the database query.

This is where the sources part company, and it is worth noting. GeoServer itself classifies the flaw as SQL injection, meaning an attacker can influence the query sent to the database. SecurityWeek and watchTowr describe it as capable, under certain configurations, of leading all the way to code execution on the server. The difference between the two matters a great deal in practice, and which one applies to your installation depends on how the database and its privileges are set up. The project's own description is the narrowest of them, and it is also the only one that comes from the people who have read the code.

What watchTowr has actually observed is limited. Jake Knott of the firm states that the attempts so far amount to probing for vulnerable systems, and that no follow-up activity has been seen. He also points out that GeoServer has been targeted before, and that several GeoServer vulnerabilities already sit in the CISA catalogue of exploited vulnerabilities. The absence of follow-up activity today is therefore not an argument for waiting. The fix is in GeoServer 3.0.1, released alongside GeoTools 35.1 and GeoWebCache 2.0.1.

What this means for you if you run GeoServer yourself

If you have GeoServer in place, the timeline is the thing to take away. Two days passed between the flaw becoming known and a fix being available, and the attempts arrived within hours. That means there was no maintenance window to plan within. Berigo assesses that the question you can actually act on is whether the instance should answer on the internet at all. A GeoServer serving only internal maps rarely needs to be open to everyone, and that decision is what determined who got scanned last week.

There is also a practical trap here that is easy to fall into. The vulnerability has no CVE number yet, so tools that track vulnerabilities by CVE will not show it. If your register is built on CVE alone, this case is not in it, however exposed you may be. Berigo assesses that such cases have to be enterable by hand, or you hold a register that stays silent about precisely the flaws that get exploited fastest. Under NIS2 article 21 this belongs to vulnerability handling, and a tracking system that only understands CVE numbers does not meet the requirement on its own.

Berigo recommends

• Update to GeoServer 3.0.1, released on 14 August, which fixes the flaw.
• Check whether your GeoServer instance answers on the internet, and close it off if it does not need to be open.
• Search the logs for requests using the jsonArrayContains filter function, and for database queries you do not recognise.
• Check whether the data store is PostGIS version 12 or later and whether the layer uses text or JSON columns, since that is where the flaw bites.
• Enter the case into your vulnerability register by hand, so it does not fall out simply because it has no CVE number.